Brief builder

Build aproject brief

Answer three questions and you’ll get a checklist of what to send us and what will affect the cost. Nothing is sent until you choose to send it.

What to send, by situation

Approved designs or a written specification: The estimate can only be as accurate as the scope it’s based on.
Anything your client has fixed: Required hosting, existing platforms, security rules or a launch date all change how we build.
Access to the repository and hosting: Ideally in your or your client’s accounts, so nobody has to transfer ownership later.
One person who can make decisions: Usually your project manager, so questions get answered quickly.
Keys for any connected services: Test and live keys, shared through a password manager, never in chat.

Design files we can inspect: We need the exact values and to see how components are put together.
Your design system, if you have one: Existing tokens and components save time and keep decisions consistent.
Real or realistic content: Placeholder text hides layout problems that real content shows up.
Browsers and devices that matter: Especially if your audience uses older phones or a particular browser.
The codebase we’re building into: Adding to an existing project is different from starting fresh.

Access to the code: Read access is enough to start. We’ll need more before changing anything.
Hosting and service accounts: Or at least a list of them, so we can see the whole picture.
Any documents or history: Old briefs, lists of known bugs, handover notes or chat exports. It all helps.
Contact details for the last developer: If you have them. A short conversation can save days.
What you need next: Launching a feature, fixing a bug and reducing risk lead to different advice.

Each system’s name and plan: What an API can do, and how often you can call it, often depends on the plan you pay for.
Their API documentation: Or a contact at the provider if the documentation has gaps.
Test accounts: Testing against live data is risky, and sometimes not allowed.
Access keys, shared securely: Through a password manager, and limited to what the integration needs.
Some example records: Real examples show up mismatches that a specification misses.

Access to the code and hosting: Including any test server. If there isn’t one, setting it up is often the first job.
One place for requests: Your issue tracker, or one we set up, so requests don’t get lost in email and chat.
Someone who sets priorities: For when there’s more to do than time to do it.
Access to any monitoring: Error and uptime alerts help spot problems before your users do.

The URLs that matter most: Usually the pages that bring traffic or revenue, not just the homepage.
Search Console or analytics access: Real visitor data shows what people actually experience.
Access to the code and a test server: So changes can be tried before they go live.
A list of tracking and third-party scripts: And who asked for each, because removing one is a business decision.