Skip to main content
KPZsProductions

Step by step

How to write a web application brief that gets you an accurate quote

Basic · 60 minutes of work · 2 minute read · Updated October 21, 2026

Pricing an application without a brief is guesswork. The developer has to assume the scope, and every assumption has a price. A good brief replaces guesses with agreements and shortens the path to an honest offer.

1. Start with the problem, not the features

Describe the process that causes trouble today: who does it, how it works now (spreadsheets, email, several tools at once), where you lose time or money. Add what should improve and how you will know it worked, for example a shorter order handling time or an end to retyping data by hand.

2. Define users and roles

List who will use the application (staff, customers, partners) and how their permissions differ. The number of roles and access levels noticeably affects the scope of work.

3. List the features and rank them

Split them into three groups:

  • Must have: without it the application makes no sense.
  • Should have: important, but the first version works without it.
  • Could have: extras for later.

This split lets you plan a first version that can launch quickly and grow the application in stages.

4. Describe data and integrations

Which systems must the application connect to (accounting, CRM, shop, payment gateway, email)? Does existing data need to be migrated, and in what format? Integrations and data migration are a common source of underestimates.

5. State the constraints

  • the expected deadline and the reason for it (season, event, contract),
  • a budget range: it helps match the solution to your means, it is not for “squeezing” the price,
  • legal and security requirements (for example GDPR, sensitive data),
  • preferences about technology or hosting, if you have any.

What affects the price

Mostly: the number and complexity of features, the number of roles, integrations with outside systems, data migration, interface design requirements, and later maintenance and development. A concrete figure comes only from analysing your brief.

Ready? Send us a brief or see how we approach advanced web applications and business tools.

Table of contents

Have this problem? Copy an AI prompt that solves it

Paste it into ChatGPT, Claude or Gemini. The assistant will ask about your situation and walk you through it step by step.

You are an experienced business analyst at a software house. Help me write a web application brief that a developer can use to give an honest quote.

Ask me questions one at a time, in this order:
1. The business problem and how the process works today (who does it, which tools, where we lose time or money).
2. The application's users, their roles and permissions.
3. Features, split into: must have, should have, could have.
4. Integrations with other systems and data to migrate (which systems, in what format).
5. Constraints: deadline and the reason for it, budget range, legal and security requirements (for example GDPR).
6. How we will know the project succeeded.

When we are done, turn the answers into a one-to-two-page brief with those sections. Do not suggest technologies or prices. If I do not know something, record it as an open question instead of guessing.

Frequently asked questions

Services related to this guide

Would you rather have someone do it for you?

Describe what you want to achieve in a brief. We reply with specifics, no sales call.

Send a brief

Newsletter

Subscribe to the newsletter

Concrete lessons from our projects, new case studies and practical tips on web apps and automation. No spam.

By subscribing, you accept the privacy policy.

We use essential cookies to run the site and, with your consent, optional PostHog analytics. Cookie Policy