Before you ask for an app quote, make the idea buildable

01

Start with the user problem, not the app category

An idea such as ‘a marketplace’, ‘an AI assistant’ or ‘a dashboard’ describes a product shape, not the problem it must solve. A buildable brief names the first user, the situation that triggers their need, what they do now and the outcome that would be meaningfully better.

Separate observed evidence from founder assumptions. Interviews, support records, existing workflow data and direct observation can support a need. A competitor feature list or an internal opinion is still an assumption until the intended user confirms the problem and priority.

02

Map one complete journey before listing every feature

Write the first useful journey from entry to outcome: how the user arrives, what they must provide, the decision or action they complete, what confirmation they receive and what happens when something fails. Include the operator or administrator steps that make the user-facing path possible.

The journey exposes missing work that a feature list hides—account recovery, empty data, permissions, notifications, review queues, refunds, support and ownership. It also reveals where a manual step is safer than premature automation.

1. 01
   Problem and outcome

   One first user, one real situation and one observable improvement.

2. 02
   Primary journey

   The end-to-end user and operator path, including failure and recovery.

3. 03
   First phase

   Must-have, later and explicitly excluded work tied to one learning goal.

4. 04
   System boundaries

   Platforms, accounts, data, integrations, privacy, accessibility and ownership.

5. 05
   Acceptance evidence

   Conditions, tests and handover proof that make the phase inspectably complete.

03

Make the first phase prove something

‘MVP’ should not mean a cheaper copy of the whole roadmap. Choose the smallest phase that lets the intended user complete the important journey and lets the team test one risky assumption. Put every attractive but non-essential capability into later or excluded scope.

Name the learning signal before building. That may be a completed workflow, reduced manual handling, a successful assisted pilot or evidence that users abandon a step. Page views alone rarely prove that the underlying problem or solution is valuable.

04

Expose constraints before choosing the stack

Platform, device, offline behaviour, identity, payments, sensitive data, third-party integrations, migration, accessibility and operator ownership change the architecture and effort. They belong in the brief before anyone turns a preferred framework into a foregone conclusion.

Record which accounts, domains, repositories, provider data and credentials the buyer will own. Unknowns should be visible and assigned a validation action rather than silently converted into a fixed estimate.

05

Define done in evidence, not adjectives

‘Fast’, ‘secure’, ‘easy’ and ‘production-ready’ are directions until they have observable conditions. Write user stories and acceptance criteria for the individual journey, then add a phase-level definition of done covering responsive behaviour, accessibility, failure states, data handling, deployment and handover.

A useful brief stays alive as evidence changes. When the team learns that a user need, integration or constraint is different, update the source decision and show how scope or acceptance changed. The document is a shared map, not a guarantee that discovery has ended.