Framing a business application often starts before the need is properly expressed. A team knows it is losing time, that a spreadsheet has become unmanageable, that a process depends on too many messages, or that an existing tool no longer fits the way people actually work. But between that discomfort and a buildable scope, there is a piece of work to do.
That work starts with field diagnosis. Not an abstract audit, but a concrete reading of usage, stakeholders, constraints, irritants and workarounds already in place. It prevents a team from building too early and solving the wrong problem. A complex business application is not just an interface: it organises roles, data, statuses, validations, exceptions and responsibilities. If those elements remain unclear, development starts on unstable ground.
The aim of project framing is simple: start from the field and turn a broad need into a first version that is useful, realistic and understandable for the people who will build it, fund it, administer it and use it.
Recognise an unclear need
An unclear need does not mean the project is weak. It often means the project touches a real organisational problem. The first sentences rarely sound like a clean specification.
You are more likely to hear:
- “We need a dashboard.”
- “We want to replace our Excel file.”
- “This process should be automated.”
- “The teams keep entering the same information several times.”
- “We need a portal to centralise requests.”
- “Our current tool no longer matches the way we work.”
These sentences are useful, but they rarely describe the full need. A dashboard request may hide a data reliability problem. An automation request may reveal an undefined workflow. A portal may be requested when the real issue is the distribution of responsibilities between several people or departments.
The first useful move is to slow down slightly. Not to block the project, but to avoid turning an intuition immediately into a list of features.
Good framing tries to answer three questions:
- What concrete problem are we trying to solve?
- Who experiences that problem in practice?
- What first version would already improve the situation?
As long as those answers remain vague, the backlog can become a pile of requests. A pile of requests is not yet a product.
Start with field diagnosis
My own difference is that I do not treat framing as only a functional or technical step. Before discussing modules, stack, screens or estimates, I try to understand the field: how the work is really done, where information circulates, which blockers keep returning, who makes decisions, who experiences the friction, and which habits already compensate for the limits of the current tool.
A field diagnosis can take several forms depending on the project:
- short interviews with the people who will use or administer the tool;
- observation of a real process, even a simple one, from beginning to end;
- review of an existing spreadsheet, form, dashboard or internal tool;
- mapping of stakeholders, responsibilities and friction points;
- collection of concrete situations where the organisation loses time, reliability or clarity.
This diagnosis is not there to produce a decorative report. It helps separate the symptom from the actual problem. When a team asks for “a dashboard”, the diagnosis may show that the real issue is the reliability of statuses. When it asks for “automation”, it may reveal that the business rule is not shared. When it wants “a portal”, it may show that responsibilities between stakeholders are still unclear.
That is often where the quality of the future development is decided. A useful business application does not simply place an interface on top of a poorly understood process. It translates field reality into data, roles, workflows, screens and priorities.
Identify stakeholders before features
A business application rarely serves one person only. Even when a director or manager carries the project, real usage often involves several profiles: daily users, administrators, support, managers, partners, clients, public agents, technicians or field teams.
Framing should therefore start with a simple stakeholder map. For each profile, you need to understand:
- what they do today;
- what takes time;
- what they need to decide or validate;
- which information they depend on;
- which errors happen often;
- what they could lose if the tool changes too quickly;
- what they should be able to do without depending on a developer.
This step avoids a classic trap: designing the application for the person who commissions the project, while day-to-day usage sits elsewhere. This is especially true for multi-stakeholder organisations, public-sector contexts, associations, industrial environments or teams with several validation levels.
For digital tools for local authorities, for instance, one tool may involve agents, elected representatives, partners, residents and administrative managers. Each person sees part of the problem. If framing only includes one point of view, the application may look correct on paper and still be hard to adopt.
This attention to stakeholders belongs to a wider logic: understand the field before drawing the tool. I also discuss this in the article on popular education and web team management, where the quality of a project depends heavily on how field knowledge is collected and turned into decisions.
Describe real situations, not screens
A common mistake is to start with screens: homepage, dashboard, list, form, detail page, admin area. Those screens may eventually exist, but they should not be the starting point.
The most reliable starting point is the real situation.
Examples:
- someone receives an incomplete request and has to chase for missing details;
- a manager must validate a case without knowing whether the documents are up to date;
- a field team records information on paper, then someone else re-enters it in a file;
- a client calls to ask for the status of a request, but nobody knows which status is authoritative;
- an administrator corrects an error directly in a file or database because the tool does not handle the case.
These situations tell you much more than a list of screens. They show breaks, duplicated work, implicit responsibilities, exceptions and the moments when the organisation compensates for the lack of a suitable tool.
From those stories, the field diagnosis becomes design material. You can write usage scenarios:
- who starts the action;
- what information is needed;
- which rule must be respected;
- who approves or rejects;
- which statuses are possible;
- what happens when something is wrong;
- what trace must remain available.
This material is much more useful for full-stack development, because it connects interface, server logic, database structure, access rights and business rules.
Clarify data, roles and workflows
A business application becomes complex as soon as it has to represent a real organisation. The complexity does not only come from the amount of code. It comes from rules, exceptions and changes of state.
Three topics need to be clarified before development.
Data
You need to know which information exists, where it lives today, who creates it, who changes it and which pieces must be reliable. Some data is central. Other data is only useful for tracking or reporting.
In a poorly framed project, everything feels important. In a well-framed project, you can distinguish:
- data required for the process to work;
- useful but secondary data;
- data that can be calculated from other information;
- historical data to keep;
- sensitive data or data with specific access rights.
This distinction avoids building an oversized model in the first version.
Roles
Roles are not only technical profiles. They represent responsibilities. Who can create a request? Who can edit it? Who can validate it? Who can see sensitive information? Who can export? Who can correct an error?
If those answers remain implicit, they will appear later as bugs, contradictory feedback or urgent change requests.
Workflows
The workflow describes the life of a business object: a request, case, intervention, product, booking, order or document. You need to identify possible states, allowed transitions and exceptions.
| Element | Question to ask |
|---|---|
| Initial status | How does the item enter the system? |
| Transition | Who can move it to the next stage? |
| Blocker | What prevents progress? |
| Exception | What happens if information is wrong or missing? |
| History | What must be kept as a trace? |
| Closure | When is the process considered complete? |
These questions look basic. They are decisive. Many projects drift because the real workflow was never made clear.
Prioritise a buildable first version
Framing should not produce a huge specification. It should produce a buildable first version. That distinction matters.
A useful first version is not a weak version. It is a version that solves a central problem without trying to cover every variation from day one.
To define it, you can classify features using four criteria:
- impact on the main problem;
- frequency of use;
- risk if the feature is missing;
- development and maintenance effort.
A highly visible feature is not always a priority. A dashboard, for example, may be less urgent than making the statuses that feed it reliable. An export may be less important than clarifying access rights. Automation may be premature if the business rule still changes every week.
The right first-version scope answers this question: what minimum base will let users work better while creating a clean technical foundation for the next steps?
This logic helps avoid two extremes. The first is trying to build everything immediately. The second is reducing the scope so much that the first version changes nothing in daily work.
Useful framing deliverables
Good framing should leave concrete traces. Not necessarily a long document, but supports clear enough to align stakeholders and guide development.
The most useful deliverables are often:
- a summary of the field diagnosis and the problem to solve;
- a map of stakeholders and responsibilities;
- a list of priority usage situations;
- a first-version scope;
- a simple model of the main data;
- a description of roles and access rights;
- a workflow diagram with statuses and transitions;
- a list of risks, trade-offs and points to confirm;
- acceptance criteria for key features.
These deliverables do not replace discussion. They check that everyone is talking about the same project. They also provide a base for estimating, building, testing and documenting.
In my approach, this framing moment connects my project-coordination background with my work as a developer. The about page explains this double culture: understand stakeholders first, then translate that context into maintainable web software.
Example: replacing a shared spreadsheet with a business tool
Take a common situation. An organisation uses a shared spreadsheet to track requests. The file contains status columns, comments, dates, owners and sometimes colours whose meaning everyone understands, even though it is written nowhere.
The initial request is: “We want an application to replace this file.”
If development starts too quickly, the team may simply reproduce the spreadsheet as a web interface: a list, filters, a form and a few notifications. It would look cleaner, but it would not necessarily be more reliable.
Field diagnosis can reveal something else:
- statuses are not defined in the same way by everyone;
- some people edit the file without telling others;
- the real owner of a request is not always visible;
- comments contain important decisions;
- blocked requests are not separated from pending requests;
- history is unreliable;
- exports are used to produce monthly reporting.
The relevant first version is therefore not just a copy of the table. It may need to focus on five objects: request, status, owner, structured comment and history. The dashboard can come later, once the data is coherent.
The diagnosis has changed the nature of the project. The team is no longer building “a tool to replace Excel”. It is building a tracking system with responsibilities, statuses and traceability.
Common mistakes to avoid
The first mistake is confusing request and need. A request often describes an imagined solution. The need describes the problem to solve. They may be close, but not always.
The second mistake is framing only with decision-makers. Their view is essential, but not sufficient. Daily users know the workarounds, exceptions and irritants the project must absorb. Without field diagnosis, this information often arrives too late, during acceptance testing or after launch.
The third mistake is trying to foresee everything. Good framing does not try to freeze three years of evolution. It sets a clear first base and makes the next decisions easier.
The fourth mistake is discussing technology too early. Technology matters, of course. Symfony, API Platform, Astro, Docker or another stack may be relevant depending on the context. But the technical choice should serve the need, not come before it.
The fifth mistake is forgetting maintenance. A business application is not finished on launch day. It must be able to evolve with internal rules, teams, data and usage.
FAQ
How long does it take to frame a business application?
It depends on the complexity of the project. A first framing phase can fit into a few short workshops for a simple tool. For an application with several roles, workflows and data sources, a more structured phase is often needed. The important point is to create enough clarity to build without multiplying rework.
Do we need a complete specification?
Not always. A heavy specification can give a sense of control without solving the real uncertainties. For many projects, it is better to produce a first-version scope, usage scenarios, priority business rules and acceptance criteria.
Can development start if everything is not clear?
Yes, if the unclear areas are identified and accepted. Uncertainty is not the problem. Pretending it does not exist is the problem. You can start on a stable base while keeping some decisions open.
Who should take part in framing?
At minimum, you need a decision-maker, users close to the field and a technical contact able to translate constraints into design choices. Depending on the project, support, administration, leadership or external partners may also be involved.
What shows that framing is good enough?
Framing is good enough when the team knows which problem it is treating, for which users, with which first version, roles, main data and known risks. It does not need to be perfect. It needs to make progress lucid.
Conclusion
Framing a business application before development does not delay the project. It gives it a stronger base through field diagnosis. Development becomes more accurate when stakeholders, real situations, data, roles and workflows are already visible.
A good first version does not come from a list of isolated features. It comes from a shared understanding of the problem. That is what makes it possible to build a useful, maintainable tool adapted to real usage.
If your project starts from an unclear need, a central spreadsheet or a process that is hard to track, the best first step is not necessarily choosing a stack. It is setting the frame: what the tool should change, for whom, and in which order.