How to prepare a brief for a custom web application

To prepare a brief for a custom web application, you do not need a 30-page specification. One page is enough to get a meaningful estimate if it covers eight things: your context, the problem and goal, the users, the core workflow, the data and integrations, the constraints, what exists today and how you will decide. Add a few attachments – screenshots, sample files, API documentation – and send the same brief to every company you ask. This article shows what to put on that page, how a software house actually reads it and how to compare the offers that come back, with notes for European companies working with a development partner in Poland.

What a one-page brief is for

A brief is not a contract and not a full requirements document. Its job is narrower: to let a development team understand the problem well enough to give you a realistic range, a list of assumptions and the questions that matter. A detailed specification often comes later, as a result of a short discovery phase.

Writing on one page also forces decisions. If you cannot describe the main workflow in ten steps, the project is probably not yet ready for a fixed price – and that is useful to know before you start collecting offers.

The one page: eight blocks

1. Company and context. What you do, who your customers are, which department owns the project. Two or three sentences.
2. Problem and goal. What does not work today and what should be different after launch. "Orders from distributors arrive by email and are retyped into the ERP; we want distributors to order in a portal and the order to reach the ERP automatically" is far more useful than "we need a modern B2B platform".
3. Users and roles. Who will use the application – internal staff, customers, partners, field teams – and roughly how many of each. Note language versions if users are in several countries.
4. Core workflow. The main process in 5–10 steps from start to finish. One workflow described well is worth more than a list of thirty features.
5. Data and integrations. Which systems the application must talk to (ERP, CRM, accounting, e-commerce, payment, shipping) and whether they have an API. If you do not know, say so.
6. Constraints. Target date and why it matters, budget range, hosting preferences, compliance requirements such as GDPR or industry rules, accessibility, single sign-on.
7. What exists today. An old system to replace or extend, spreadsheets, a prototype, design work. For legacy systems mention the technology if you know it.
8. Decision process. Who decides, when, and what you expect in the reply: a range, a phased proposal, a discovery offer.

If you already have a detailed list of features, keep it – just put it in an attachment rather than on the page.

Attachments that help more than long documents

• Screenshots of the current system or the spreadsheet people use today.
• Sample files: an exported order, a price list, a product data sheet – with personal data removed.
• API documentation or the name and version of the ERP or CRM.
• A simple process sketch, even photographed from a whiteboard.
• Examples of applications or portals you like, and a sentence on why.

Before sending anything containing customer or employee data, sign an NDA and anonymise the samples. Most teams can estimate perfectly well from structure, not real records.

How a software house uses your brief

Knowing what happens on the other side helps you write a better brief. In our case, and in most experienced teams, it goes roughly like this:

1. Read and map. The brief is turned into a list of modules, roles and integrations.
2. Find the unknowns. Integrations without documentation, unclear business rules and data migration are the usual sources of uncertainty.
3. Ask questions. A short call or a list of questions. A vendor who asks nothing either has not read the brief or is pricing the risk silently.
4. Propose an approach. A range for the first version, a phased plan, or a paid discovery phase when the unknowns are too large for an honest estimate.

The output should always include assumptions and exclusions. They are as important as the number.

Comparing offers from several companies

Send the same brief and the same attachments to every vendor, and ask them to answer in a comparable structure:

• scope of the first version, in their own words,
• assumptions and what is explicitly excluded,
• breakdown by module or phase, including testing, project management and deployment,
• team composition and who your day-to-day contact will be,
• pricing model: fixed price for a defined scope or time and materials with an estimate,
• what happens after launch: warranty period, support, hosting, updates,
• who owns the source code and when ownership is transferred.

Then put the answers side by side. Large price differences usually come from different assumptions, not different hourly rates. A very low offer with no questions and no exclusions is a warning sign, as is a fixed price for a scope that you yourself consider unclear.

It is also worth checking how each company handles a project like yours – ask for a comparable case, a short technical description or a call with the people who would do the work. Our portfolio shows the types of projects we take on.

Working with a development partner in Poland

For companies from Germany, Austria, the Nordics, the Benelux or the UK, a few practical points belong in the brief or the first call:

• Language and time zone. Poland is in the Central European time zone, which overlaps fully with most of continental Europe. State the working language for documentation and meetings.
• Contract law and IP. Agree which law governs the contract. Under Polish copyright law, a transfer of rights must name the fields of use (pola eksploatacji), so make sure the IP clause is drafted with that in mind.
• Data protection. If the vendor will access personal data, for example during migration or support, you will need a data processing agreement under Article 28 GDPR.
• Invoicing. B2B services between EU businesses are normally invoiced without Polish VAT under the reverse-charge mechanism; confirm the details with your accountant.

Common mistakes

• Describing the solution ("we need microservices") instead of the problem.
• Listing every possible feature, so nobody knows what the first version is.
• Hiding the budget range – vendors then guess and offers become impossible to compare.
• Sending different information to different vendors.
• Choosing by total price without reading assumptions.

Next step

Write the eight blocks above in one sitting, even roughly, and collect the attachments you already have. If the core workflow or integrations remain unclear, consider a short discovery phase before asking for fixed prices – it is the approach we describe in SaaS MVP development with Laravel, React and Vue, and it applies equally to internal tools. You can read how we run projects on our custom software development page, or simply send us your brief and we will reply with questions, assumptions and a suggested first step.