How to brief a custom webapp when off-the-shelf tools don't quite fit

There comes a point when off-the-shelf software stops doing the job. Not because your team is too demanding, but because your situation genuinely diverges from what most tools are built for. You have specific user flows, unusual integrations, logic that belongs to you. You need a custom web application.

Then the real work begins: how do you brief it? A bespoke web application is not a website with extra features, and it is not a SaaS product you configure. It is software you build from the ground up. The brief you write determines, to a large degree, whether the project succeeds or gets stuck.

At Livewall, we have worked through dozens of these projects, from internal systems for large organisations to public platforms serving thousands of users every day. Here is what we have learned from every brief we have evaluated.

Start with the problem, not the solution

The most common mistake in web application briefs: they describe what needs to be built, not why. Screens get specified, flows get drawn, features get listed. But the question of why this system needs to exist gets skipped.

An agency that only sees the solution cannot assess whether that solution is actually the right one. In a custom build, that is a real problem. If the underlying assumption is wrong, you build the wrong application. On time, on budget, beautifully executed, but wrong.

Write first: what is the concrete problem this system needs to solve? Who experiences that problem, how often, and what does it cost them right now? What is the desired outcome in a year? A good agency, which is what we try to be at Livewall, uses this to assess the proposed solution, sharpen it, or replace it with something better.

Describe your users concretely

Web applications have users. Sometimes those are internal staff, sometimes customers, sometimes both. The brief needs to make clear who those users are and what they expect from the system.

Not at the level of persona sheets with stock photos, but at the level of: how many people use this daily, what is their technical competence, which devices do they use, in what context do they interact with the application? A logistics worker using a system on a tablet in a warehouse has different requirements from a marketer viewing the same data on a laptop in an office.

For Zorg van de Zaak we built a B2B platform where end users ranged widely: from HR managers to employees without a digital background. That range had a direct impact on design decisions, technology choices, and how we handled accessibility. We knew that because the brief made it clear.

For Veilig Thuis something similar applied: a vulnerable target group calls for different design decisions than a commercial platform. If that is not in the brief, the agency has to fill it in themselves. That is a risk.

What the application needs to do: functional versus technical

This is where most briefs go wrong. They describe things either too functionally (a list of features without context) or too technically (a stack specification without a product vision). Both are unhelpful to an agency that wants to do good work.

What works: describing functional requirements from the perspective of user behaviour. Not "there should be a dashboard", but "an administrator needs to see at a glance how many users are active, which content generates the most interaction, and which notifications are outstanding". That gives direction without removing design freedom.

Technical requirements are relevant when they are hard constraints: a mandatory integration with an existing system, a security standard the organisation is committed to, a hosting environment that is non-negotiable. Those are constraints an agency needs to know before they start.

What you can leave out: the exact technology stack (unless you have strong reasons), the precise screen layout (that is design, not brief), and feature lists without prioritisation. An agency that knows what it is doing translates your functional requirements into the best technical choices. That is exactly what web application development means at Livewall.

Integrations: the underestimated part of the brief

Custom web applications rarely stand alone. They connect to existing systems: a CRM, an ERP, a payment platform, an identity provider, a data warehouse. Those connections are technically complex and often time-consuming. When they appear late in the project, they cost not just time but sometimes reshape the entire architecture.

A good brief describes every system the application needs to talk to, including who owns those systems and what is known about available APIs. Not sure if an API is available? Write that down. An honest "we don't know" is more valuable than an assumption that turns out to be expensive.

For Lefboom, a sustainability rewards platform, integrations with external partners were a critical factor. We mapped them early. That made the difference between a smooth project and fighting fires halfway through.

For Dumpert, the streaming architecture required specific technical decisions that had to be clear in early discovery. That kind of complexity does not survive a vague brief.

Scope, MVP, and what you deliberately leave out

One of the most valuable things a brief can contain: an explicit list of what you are not building in the first version. This sounds counterintuitive, but it is essential. Without that list, everything becomes a priority. The project then bogs down in scope discussions halfway through, or delivers something nobody intended.

At Livewall we work with a prototype-first approach. Start small, validate, grow. A good brief fits that model: what is the minimum you need to learn whether the concept works? Which assumption do you want to validate first? That is the scope of your MVP.

Everything else is a backlog, not a day-one requirement. Rapid prototyping only works when the scope of the first version is defensibly small. That takes courage in the brief. State explicitly what you are deferring, and why.

This also applies to functionality that would be "nice to have". Admin panels, export functions, detailed reporting: almost always these can come later. Put them in a second phase. An overfull first phase is one of the leading causes of delay in web application projects.

Budget, timeline, and how to be honest about both

Many briefs are silent on budget. That is understandable, but it helps nobody. An agency without a budget indication cannot make a realistic proposal. They either give you an optimistic quote that overruns later, or a padded estimate that carries unnecessary cost.

You do not need to be precise to the euro. But a range gives direction. "We are thinking somewhere between 80,000 and 120,000 euros for the first version" allows an agency to be honest about what is achievable within that and what is not.

The same applies to timelines. If there is a hard deadline, write it down and explain why. A live date that is fixed because of a trade fair, a contractual obligation, or a seasonal pattern is relevant information. That context helps the agency prioritise.

If you have no hard deadline: that is also valuable information. It creates space for phasing that improves quality. Digital strategy always starts with realism about time and resources.