Software project brief: how to describe a product so it can be priced

A brief is not a specification

It is tempting to put off asking for a price until a technical specification exists. You don’t need one. A brief describes what the product must do and for whom; a specification describes how it will be built, screen by screen and endpoint by endpoint. The specification is usually produced during scoping, together with the team that will build the product, because that team knows which details matter for the price and which don’t.

What a brief has to do is narrower: give enough information that two studios reading it would price the same product. If they would picture two different products, the brief isn’t finished.

There is an opposite trap as well: a specification copied from another project or generated from a template. It looks thorough, but it describes someone else’s product, and studios will price what is written, not what you need.

If your organisation requires a formal specification to a particular standard, as public procurement and some large companies do, say so up front: writing that document is work in its own right, and it gets priced too.

The nine parts of a brief that can be priced

1. The problem and who has it

Two or three sentences. What is broken or missing today, for whom, and what it costs them. “Our managers spend hours every day answering ‘where is my order’ calls, because clients can’t see the status” is more useful than “we need a CRM”.

2. What success looks like

One measurable outcome for the first version: bookings per week, the share of orders placed online, hours saved per manager. It tells the studio what to protect when the scope has to be cut.

3. Users and roles

List every type of person who will use the product and what each one does in it. Don’t forget the invisible ones: the administrator who approves things, the accountant who downloads reports, the support person who answers questions. Roles drive the cost more than screens do.

4. The core flow, step by step

Describe the one path that must work end to end, as a numbered list from the user’s first action to the moment they get value. For example:

1. A client signs up with an email and a one-time code.
2. The client creates an order and attaches documents.
3. A manager reviews the order and sets a price.
4. The client pays by card.
5. The client follows the status until the order is completed.

Then add the most important alternative paths: what happens when a payment fails, when an order is cancelled, when a document is rejected.

5. Features, sorted

Not a wish list — a sorted list. Three columns are enough:

Everything in the first column gets priced. The other two tell the studio how to design the first version so the rest can be added without a rewrite.

6. Platforms

Web, iOS, Android, a Telegram Mini App, an admin panel — and why. “Our clients order from the office and our couriers work from phones” is a reason; “everyone has an app” is not.

7. Integrations and existing systems

Every system the product has to talk to: payment providers, accounting, a CRM, email and SMS services, maps, partners’ APIs. For each one, say what data moves in which direction, and attach the documentation if you have it. Mention the data that already exists and has to be moved into the new product.

8. Constraints

• The deadline, and what drives it: a season, an investor meeting, a contract.
• A budget range. Naming it is not a negotiating mistake; it lets the studio propose a scope that fits instead of a price you will have to refuse.
• Rules: personal data, payments, industry regulations, languages, accessibility.
• Volumes: how many users, orders or records you expect in the first year.

9. Examples and references

Products you like or compete with, and what exactly you like about them: “the booking calendar in X”, “the onboarding in Y”. Links, screenshots and a screen recording of your current spreadsheet process are all useful. If the product replaces an existing process, the best reference is that process itself: the spreadsheet, the form, the email thread with a client. Show how it works today, and the studio will see what has to be automated.

A template you can copy

1. Problem: who has it, what it costs them today
2. Success: one measurable outcome for version one
3. Roles: every type of user, including admins
4. Core flow: numbered steps from first action to value,
   plus what happens when things go wrong
5. Features: must have / should have soon / later
6. Platforms: web, iOS, Android, Mini App, and why
7. Integrations: systems, direction of data, documentation,
   plus existing data to migrate
8. Constraints: deadline, budget range, rules, volumes
9. References: products and screens you like, and why

A filled-in example

Say a company that rents out construction equipment wants clients to book online. Its brief could fit on one page:

1. Problem. Managers take bookings by phone and in a spreadsheet. The same machine sometimes gets booked twice, and clients can’t see what is available.
2. Success. Half of all bookings placed online within three months of launch.
3. Roles. Client, manager, warehouse worker, administrator.
4. Core flow. The client picks equipment and dates, sees the price and availability, and prepays by card; the manager confirms; the warehouse marks the handover and the return. If the payment fails, the booking is not held; if the manager rejects it, the client gets a full refund.
5. Features. At launch: catalogue, availability calendar, booking, card payment, statuses. Soon: email reminders and a report on how often each machine is rented. Later: a separate app for the warehouse.
6. Platforms. Web for clients and managers; warehouse workers use phones, so their part of the product must work well on a phone.
7. Integrations. The accounting system (the list of machines and invoices) and a card payment provider; about 300 items to import from the spreadsheet.
8. Constraints. Launch before the spring season, a budget range, client personal data, up to 50 bookings a day in season.
9. References. The date picker of a hotel booking site they like, and the current spreadsheet, attached.

Two studios reading this would picture the same product. Neither would have to guess who the warehouse worker is or what happens when a card is declined.

Weak lines and priceable lines

Each weak line can hide a day of work or a month of it. Each priceable line can be estimated, built and checked.

Gaps that make estimates go wrong

• Hidden roles. The admin, the accountant, the partner who “just needs to see a few things”.
• “Simple” integrations with no documentation and no test access.
• Unstated volumes. A catalogue of 200 products and one of 200,000 are different projects.
• Existing data. Years of spreadsheets that have to be imported and cleaned.
• Legal requirements that surface in week five: consent, where data is stored, invoices in a specific format.
• What already exists. A brand, a design, a backend, a domain, an app store account — or none of these.

Does more detail make it more expensive?

Usually the opposite. Studios price unknowns as risk. A vague line gets a generous estimate, because the studio has to cover the expensive interpretation; a precise line gets an estimate for exactly what you described. Detail also cuts down the team’s questions before the contract, which brings the start date closer.

The fair exception is detail about things that don’t matter for the first version. Spend your effort on the core flow, the roles and the integrations, not on button colours. If you are unsure whether a detail belongs in the brief, ask yourself whether it changes the amount of work. If it does, write it down.

Write it with acceptance in mind

A good brief already contains the answer to the question that ends every module: is this done? If the core flow is written as steps and every feature has a sentence describing what it must do, the same sentences later become acceptance criteria. That is what keeps reviews short and disputes rare. More in how to accept software.

Three mistakes that waste the brief

• Sending different versions to different studios. Then the quotes can’t be compared. Send the same text to everyone and answer questions in writing, to everyone.
• Describing the solution instead of the problem. “We need microservices and a mobile app” closes doors a studio might have opened for less money. Describe the problem and let the vendors propose.
• Leaving out what you already have. An existing backend, a brand book or a working spreadsheet process can save weeks, but only if the studio knows about them.

Test the brief before you send it

Give it to a colleague who knows nothing about the project and ask them to retell the core flow in their own words: who does what, in which order, and what the product does in return. If they stumble, a studio will too. Then read it once as a competitor would: is it clear what the product is for and who pays? If both tests pass, send it.

What happens to the brief next

The brief is the input to the first stage of the project, not a document that sits in a folder. During scoping it becomes a list of modules with hours and a price; the contract fixes that list; and the sentences you wrote about the core flow come back as the acceptance criteria for each module. The whole sequence, from the first description to launch and support, is in the software development process, stage by stage.

What to send to EVA-X

You don’t need a technical specification or any particular format. Describe the product in your own words, paste a link to a competitor, attach a PDF, a Word file or an image, or record a voice message, and the estimate turns it into modules with hours, a timeline and a price in about 15 seconds. Then our team reads the brief and the estimate, asks about the gaps — in your cabinet or on a call — and confirms the scope and the price before any contract. A brief built on the nine parts above simply makes that conversation shorter. For what comes next, see fixed price vs time and materials and how much an MVP costs. More on how we work: custom software development.