Web App Brief Template: Describe Your App Without Writing Code

You do not need technical knowledge or a formal requirements specification to get a web app quoted. You need a plain description of what the app should do and for whom: the problem it solves, who uses it, the one workflow at its centre, the data it stores and what is explicitly not included.

Two to five pages is usually enough. How the app gets built is the developer's job. Below is a template you can copy, with short guidance for each section and the data protection questions that come up when you build software for a German or EU market.

Brief, PRD, Lastenheft: what you actually need

Startup guides often talk about a PRD (product requirements document). In Germany, you may hear about a Lastenheft and a Pflichtenheft. The Lastenheft is written by the client and sets out their requirements; the Pflichtenheft is written by the contractor and describes how they will meet them. The German standard DIN 69901-5 defines the Lastenheft as the full set of requirements specified by the client.

For a small, clearly defined app, you need neither a formal PRD nor a Lastenheft to a standard. A good brief does the same job in fewer pages. What matters is the division of roles: you describe the requirements, the developer proposes the solution and confirms the agreed scope in writing.

What a good brief gets you

• Quotes you can compare: if every provider receives the same description, they price the same scope. That matters when one quote is local and one is offshore.
• Realistic prices: roles, data and integrations are the biggest cost drivers. If they are in the brief, nobody has to guess.
• Fewer change requests: what the brief excludes will not be silently expected later.
• A yardstick at handover: success criteria let you check whether the app does what it should.

The template

How to fill in each section

Problem and goal: start with the pain

Describe what goes wrong today, not the features you want. "Client documents arrive in three inboxes and we lose track" tells a developer more than "we need a CRM". The right solution follows from the problem, and sometimes it turns out to be existing software.

Users and roles: who sees what?

A role is a group of users with the same permissions. For each role, note what they can view, create, change and delete. Fewer roles mean a simpler app. If clients only fill in a form and never log in, they are not a role with an account; say so in the brief.

Core workflow and user stories

A user story is one sentence from the user's point of view: "As the office manager, I want to see all open requests sorted by date, so that none are forgotten." The format forces you to name a benefit for every feature. Features without a clear benefit are candidates for a later version.

Data: as little as possible, as much as necessary

List every field to be stored and ask of each one: do we really need this? The GDPR requires personal data to be limited to what is necessary for the purpose (data minimisation, Art. 5(1)(c)). Fewer fields also mean less development work.

Every processing purpose also needs a legal basis, such as performing a contract or consent (Art. 6 GDPR). You do not have to answer that in the brief. Noting the purpose of each kind of data makes it much easier to settle later.

Integrations: check whether an export will do

Note every program the app should exchange data with, and how often. In version one, an export to a spreadsheet that you process yourself is often enough. A live connection to an ERP or inventory system is a separate and much larger project.

Explicitly out of scope

This is the most valuable section of the template. Everything listed here is clearly excluded for everyone involved. Typical candidates: client accounts, native apps in the app stores, a second language, analytics, payments. To decide what belongs in version one, see Web App MVP: features for version one.

Budget and deadline: say them out loud

A budget range does not weaken your negotiating position. It lets the provider propose something that fits instead of pricing the most expensive option. What drives the price is covered in How much does a custom web app cost in Germany?.

Data protection and security: questions for your brief

• Will the app store personal data, and which?
• Does it include particularly sensitive data, such as health information?
• Which service providers will process the data (hosting, email delivery, AI services)? Each one generally needs a data processing agreement under Art. 28 GDPR, known in Germany as an AVV.
• Where should the data be hosted, and does an EU location matter to you or your clients?
• When is data deleted?
• Who may see which data? Broken access control is number one in the OWASP Top 10 (2025), the reference list of the most critical web application security risks.
• Should the app be accessible to people with disabilities? The W3C's WCAG 2.2 is the reference standard.

What does not belong in the brief

• Technology choices: programming language, framework or database. Prescribing them rules out good solutions.
• Finished designs for every screen: sketches and examples help; a complete design up front locks things in too early.
• Unranked wish lists: twenty features of equal priority cannot be sensibly priced.

If you notice while filling it in that users never log in or manage their own data, you may not need a web app at all. Check with Website or Web App.

How Ichii works with your brief

At Ichii, your brief is the starting point for a Zoom call. We then confirm the scope in writing and give you a fixed price for exactly those functions before the project starts. Small, clearly defined web apps start at €1,999 net (plus VAT), one-time; the more roles, integrations or special logic your brief contains, the higher the price. Projects involving ERP connections or many integrations are outside this range. Hosting, third-party services and technical maintenance (from €29 per month) are charged separately.

Your next step

Copy the template and fill in only sections 1 to 5 and 9 first; that usually takes less than an hour. Then cut your user stories down to what version one really needs and send the result with your web app enquiry. We will work through any gaps with you.