Development Brief - 15 Questions for the Client

A solid development brief saves weeks of back-and-forth and protects the budget from "and also this". Without answers to basic questions, the team guesses requirements while the client is surprised by timelines and price. Below - 15 questions worth asking before an estimate and kick-off. The answers turn an idea into a clear scope, not a wish list.

• Why a brief - lock the goal, boundaries, and success criteria
• When to ask - before the proposal and before kick-off
• Who answers - the decision maker and product owner, not "everyone a little"
• What you get - clear scope, realistic timeline, transparent budget
• Rule - no answer = risk of rework and hidden costs

Why collect a brief before the start

Building a site, service, or integration almost always stalls on uncertainty, not on code. If the goal is fuzzy, priorities shift every week, and "must-have" appears at the finish line - timelines and cost grow.

A brief is not bureaucracy. It is a short contract on project meaning: what we build, for whom, toward which result, under which constraints. The earlier these questions are closed, the more accurate the estimate and the calmer both sides.

15 questions for the client

1. What business problem are we solving?

Not "we need a website", but what hurts now: few leads, chaos in requests, manual processes, an outdated catalog. The problem shapes architecture and feature priorities.

2. Who is the target audience and what is their main scenario?

Who is the user: B2B buyer, retail customer, employee, partner. One primary scenario matters more than ten secondary ones.

3. How will we know the project succeeded?

You need measurable criteria: lead count, conversion, order handling time, fewer errors, faster content publishing. Without KPIs, "done" stays subjective.

4. What is the timeline, and is there a hard deadline?

A launch for a trade show, season, or product release changes the plan: MVP now or full scope later. A deadline without priorities usually means rework.

5. What budget range is realistic?

A budget corridor helps cut unrealistic scope early. An honest range beats "roughly inexpensive" with no numbers.

6. What already exists: site, CRM, ERP, APIs, content?

Inventory saves money. Integrating a live CRM and migrating a catalog are separate workstreams, not "a small thing at the end".

7. Which integrations are mandatory at launch?

Payments, warehouse, 1C/ERP, email, analytics, messengers. The integration list affects timeline more than the choice of framework.

8. Are there constraints on stack, hosting, and security?

Corporate standards, on-premise, infosec requirements, cloud bans - all of this must be in the brief before the estimate, not after choosing a vendor.

9. Who makes decisions and who approves stages?

One decision maker speeds the project up. If approval goes through five departments with no owner - add buffer for waiting and changing minds.

10. What is must-have in v1, and what can wait?

Split "needed to launch" from "nice later". An MVP with a clear core delivers value faster and costs less than "everything at once".

11. Are there references for "how it should be" and anti-examples for "how not"?

Links to sites and products save hours of UX and tone debates. Anti-examples help too: they mark taste and expectation boundaries.

12. Who prepares content, copy, photos, and access credentials?

Content often becomes the bottleneck. If texts and service access arrive late - design and development idle.

13. Which user roles and access levels are needed?

Guest, client, manager, admin, partner - different dashboards and permissions. Describe the role model before designing screens.

14. Are there legal, personal-data, or industry requirements?

GDPR / local privacy laws, healthcare, finance, public sector - change storage architecture, consents, logs, and contracts. These cannot be "added later".

15. Who supports the product after launch?

Updates, monitoring, content edits, incident response. If support is missing from the plan - a working product risks aging fast.

How to use the answers in practice

Condense answers into one page:

From this table it is easy to build a proposal and roadmap. If a cell is empty - that is not "a detail for later", it is an open risk.

Common brief mistakes

• Confusing a wish ("make it beautiful") with a result ("grow leads by 30%").
• Treating integrations as "a button", not a separate workstream.
• Not assigning a product owner on the client side.
• Building must-have from the entire backlog with no prioritization.
• Ignoring support: launch without a support owner = debt from day one.

Bottom line

A development brief is 15 short but firm questions about goal, audience, KPIs, timeline, budget, integrations, constraints, roles, and support. The fuller the answers before the start, the more accurate the estimate and the fewer surprises along the way.

If you need help building a brief, prioritizing an MVP, or estimating development from your answers - get in touch.

Frequently asked questions

How long does filling a brief take?

Usually 1-2 business days if there is a decision maker and access to basic data. It is harder when decisions are spread across departments: then a short 1-2 hour workshop beats weeks of email.

Can you estimate a project without a brief?

You can give a from-to range, not a precise quote. Without goal, integrations, and success criteria, estimates almost always float. A brief reduces uncertainty and protects both sides from false expectations.

Does a brief replace a technical specification?

No - a brief is the input to a spec. It locks meaning and boundaries. The spec then describes screens, data, APIs, roles, and acceptance criteria. Without a brief, specs often bloat and change mid-flight.

What if the client does not know the budget?

Offer a corridor and scope options: MVP / standard / extended. That makes a realistic scope easier to choose. "Budget is unlimited" in practice almost always means priorities are not yet aligned.

Should the brief be updated during development?

Yes, when the goal, deadline, or must-have changes. A brief is a living boundary document. Any scope expansion must explicitly change timeline or budget, or the team works on debt.