How to Brief a Developer for a Custom Portal (So You Don't Waste Budget)

“I want a website like Facebook, but for plumbers.”

In the software development world, this is known as the “Iceberg Brief”. It looks small and simple on the surface, but hides massive complexity, cost, and risk underneath.

If you approach a development agency with a vague brief, one of two things will happen:

They will quote you a massive “safety buffer” price to cover the unknowns.
They will guess what you want, build the wrong thing, and you will spend months fighting over “scope creep”.

The secret to a successful, on-budget project isn’t choosing the cheapest developer: it’s writing the clearest brief.

Here is how to write a spec sheet that saves you thousands.

1. The “Problem-First” Approach (The Context)

Don’t start with solutions. Start with problems. Developers are problem solvers. If you tell them “I need a blue button here,” you are limiting them. If you tell them “Users keep missing the checkout step,” they might invent a solution you never thought of.

Bad Brief: “We need a login system.” Good Brief: “We need a secure way for our wholesale clients to view their specific pricing tiers, so they stop calling the office to ask for quotes.”

2. Define Your “User Personas”

Who is actually going to be clicking the buttons? A 22-year-old tech-savvy intern uses software very differently from a 60-year-old field engineer wearing safety gloves.

Define your actors:

The Admin (You): Wants to see reports, manage users, and export data.
The Client: Wants to see their invoice, pay quickly, and leave.
The Field Worker: Wants big buttons, high contrast, and offline capability.

3. The “Happy Path” (User Stories)

Walk through the ideal journey for each user. In agile development, we call these “User Stories”. Format them like this: “As a [User], I want to [Action], so that [Benefit].”

“As a Client, I want to upload my tax documents, so that my accountant receives them instantly.”
“As an Admin, I want to receive an email when a document is uploaded, so that I can review it.”

This creates a definitive checklist of features that leaves no room for ambiguity.

4. Functional vs. Non-Functional Requirements

This is where most briefs fall short. Functional Requirements describe what the system does (e.g., “Send an email”). Non-Functional Requirements describe how the system performs.

You need to specify:

Scale: Are we building for 10 users or 10,000?
Speed: Does the dashboard need to load in under 1 second?
Security: Do we need Two-Factor Authentication (2FA)? Is the data sensitive (GDPR/HIPAA)?
Devices: Does this need to work on an iPad? On a phone? on Internet Explorer (please say no)?

5. What is “Out of Scope”?

Defining what you are not building is just as important as what you are building. This prevents “Feature Creep”: the silent killer of budgets.

“Phase 1 will NOT include a mobile app.”
“Phase 1 will NOT integrate with Xero (Manual export only).”

Be ruthless. Build the Minimum Viable Product (MVP) first. Launch it. Learn from it. Then build Phase 2.

6. Budget & Timeline

Be honest. The “How long is a piece of string?” game helps no one. If you have a budget of £5,000, tell the developer. They will tell you what is realistic for that price. If you hide your budget, they might design a £50,000 Ferrari when you can only afford a Ford.

Timeline: Start with your deadline and work backward. If you need to launch in 8 weeks, be aware that development takes time. You cannot rush quality code (unless you pay for a bigger team).

Conclusion: Clarity is Currency

The time you spend writing a detailed brief pays for itself ten times over. It reduces meetings, eliminates re-work, and ensures you get exactly the digital asset you envisioned.

Don’t know where to start? We offer a paid “Discovery Workshop” where we help you write the technical specification for your project: yours to keep, whether you build with us or not. Book a Workshop.