You've got an idea. You want to know how much it will cost to build. So you write up what you're thinking and send it to a few engineers. Then you wait. And the quotes come back anywhere from £8,000 to £80,000 — for the same project.
This is not unusual. It happens because engineers are filling gaps with assumptions — and when the brief is thin, the assumptions diverge wildly.
A good prototype brief is not a full spec. It is the minimum set of structured information that lets an engineer produce a realistic range estimate — without spending hours asking clarifying questions first.
What outcome does the prototype need to demonstrate?
Engineers estimate effort based on what they need to build, not what you want to sell. So the most important thing in your brief is not the feature list — it is the outcome the prototype must demonstrate.
For a V1 prototype, that usually means: what does this thing need to do in front of a first user, investor, or test session?
Good outcome statement: "A wearable device that logs heart rate continuously for 72 hours on a single charge, syncs via BLE to an iOS app, and can be demonstrated in a lab environment."
Weak outcome statement: "A health monitoring wearable with app connectivity."
The good version tells the engineer what the success bar is. The weak version tells them almost nothing.
What are the hard constraints?
Constraints are the requirements that are non-negotiable. They exist independently of what you want — they come from physics, regulations, your supply chain, or your customer.
Common hardware constraints to include: - Power budget: Battery size, charge cycles, or mains-powered? - Form factor: Specific dimensions or weight limits? - Environmental: IP rating, temperature range, vibration? - Connectivity: Which protocols — BLE, WiFi, LoRaWAN, cellular? - Regulatory: CE, FCC, UKCA — and when is this a requirement?
Common software constraints: - Specific platforms (iOS only, Android first, web-only) - Authentication requirements (SSO, OAuth) - Data residency or compliance (GDPR, ISO 27001) - Integration requirements (must connect to Salesforce, Stripe, etc.)
If you don't know a constraint yet, say so explicitly. "We don't know the IP rating yet — assume none for V1" is far more useful than leaving it blank, which forces the engineer to assume the worst.
What does success look like at handover?
Engineers need to know when the prototype is done. Without a clear definition of done, scope creep is inevitable — and so is a bad estimate.
For each prototype, define: 1. What the prototype must demonstrably do 2. What level of polish or documentation is required 3. Whether you need source files, Gerbers, or just a working unit
For a V1 hardware prototype this might be: one functional PCB assembly, FreeRTOS firmware that runs the core loop, and a BOM — but no enclosure.
For a V1 web app it might be: three working user flows, deployed to a staging URL, with no mobile optimisation in scope.
What do you already have?
This is massively underused. Engineers can move much faster if you already have: - A reference product or competitor to benchmark against - Prior work from another contractor - A design sketch or CAD file - An existing codebase - Test data or sensor readings
Even a poor or partially complete prior effort cuts scoping time significantly. Share it.
What is your target timeline and budget band?
You do not need to give an exact budget. But giving a range — "we want this built for under £20k" or "our ceiling is £50k" — is genuinely useful. It tells the engineer whether to spec a simple solution or a robust one, whether to use off-the-shelf modules or custom silicon, whether to include a companion app or not.
Similarly, a target milestone date filters options. "We need a working unit for a trade show on 1 September" changes priorities and may require a premium on turnaround.
What can you share right now?
End the brief with what you can attach or share immediately: - Sketches, photos, or CAD files - Prior quotes or scoping documents - Reference products (links or photos) - Existing firmware or codebase - Any NDA you want us to sign first
If there is an NDA requirement, say that upfront. It avoids a round trip.
What not to include
Longer is not better. These things slow down scoping without adding value: - Feature lists without priority ("would be nice" features waste everyone's time) - Brand guidelines at this stage - Investor pitch decks (we need technical context, not market size) - Vague vision statements without outcome definitions
A one-page brief with the six sections above will get you a better estimate than a 20-page document without them.