The fastest way to lose money on offshore hiring is to skip the brief. The second fastest is to write a brief that sounds detailed but answers none of the questions that actually matter.
I've reviewed hundreds of briefs from prospective clients over the years. The pattern is always the same: long briefs that describe what the founder wants the product to be without answering the questions that determine whether anyone can build it. Pages of features, no pricing model. Detailed user flows, no real customer named. Tech stack opinions, no deployment plan. The brief reads like a wishlist instead of a contract.
A good brief is shorter than people expect, sharper than they're comfortable with, and answers the eight questions below. If you can answer all eight before contacting any developer, you'll skip 80% of the disasters that destroy offshore engagements.
The eight questions
1. Who specifically pays for this?
Not "small businesses." Not "founders." A specific persona, named and sized: "Bootstrapped SaaS founders running $200k–$2M ARR products in the marketing tech space, who currently pay for HubSpot but find it overkill for their stage."
The test: can you describe one real person who would pay for what you're building? Not someone you've made up — someone you've actually talked to. If the answer is no, the work you need first isn't development, it's customer research. Hiring a developer before customer research is the most expensive way to do customer research.
What good answers look like: a 2-3 sentence persona naming role, company size, current solution, and what they pay now.
What bad answers reveal: vague phrasing ("everyone who...", "small businesses generally...") tells you the founder hasn't actually identified the buyer yet. Hire a coach to fix this before you hire a developer.
2. What do they pay for it?
A real number. Not a price range. Not "we'll figure out pricing later."
If the answer is "$50/month subscription," good — that's a constraint that shapes architecture, design, and feature priority. If the answer is "we don't know yet," you'll build the wrong product. Pricing isn't a marketing decision you make at launch; it's a technical decision you make at design.
A SaaS at $5/month per user has a totally different architecture than a SaaS at $500/month per user. The cheap product needs heavy automation, low support cost, viral mechanics. The expensive product needs deep customisation, white-glove onboarding, customer-success workflows. Same idea, totally different builds. You need to know which one you're making.
What good answers look like: a specific pricing model with one or two tiers and rough numbers. Even "$X/month per user, $Y for the team plan" is enough to start.
What bad answers reveal: pricing avoidance is a signal that the founder hasn't found product-market fit yet. Real customers haven't agreed to a real price. The development work is premature.
3. What's the smallest useful version?
Not the smallest complete version. The smallest version that one paying customer would actually use to solve their problem.
Founders chronically over-scope MVPs. They want auth + onboarding + dashboard + main feature + reporting + admin panel + integrations + email notifications. That's a 6-month build. Real MVPs ship in 6–10 weeks because they cut everything that isn't core.
The discipline: list the features. Mark the ones a customer would refuse to pay without. Cut everything else from V1. The cut list always includes things you think are critical. They're not. Your customers will tell you what they actually need after using V1.
What good answers look like: 3–5 features, with the ability to defend why each is non-negotiable. "Customer can sign up, create their first thing, share it with a teammate." That's a real MVP.
What bad answers reveal: long feature lists are a sign the founder doesn't yet know what their product is. The development is still discovery, and discovery should be done by the founder talking to customers, not by a developer building speculatively.
4. What's the data model?
Not the schema. The list of 5–10 things your software needs to remember.
For a project management tool: users, teams, projects, tasks, comments, attachments, notifications. That's it. Seven entities. If your data model has 30 entities, your scope is wrong, not your data model.
The data model is the cheapest part of the brief to get right and the most expensive part to get wrong. A developer who starts coding without a clear data model produces code that needs to be rewritten in month 3 when you discover the schema can't hold what you actually need.
What good answers look like: a numbered list of entities with their key relationships. "Users have many Projects. Projects have many Tasks. Tasks belong to one User."
What bad answers reveal: vagueness ("we'll need a database with all the user data") is a sign the founder hasn't thought through what the software actually does. Sit with this before hiring.
5. What integrations are non-negotiable?
Stripe? Google OAuth? A specific HRIS or CRM? List them, with priority order.
Each integration adds 1–3 days of work and 0–60% probability of unforeseen complications. The founder who says "and we'll integrate with all the major HR platforms" hasn't realised that's 12 integrations × 2 days each = 24 days of integration work, plus the maintenance overhead forever. Pick three to start.
For most SMB software, the must-haves are usually: payments (Stripe or Paddle), auth (Google + email/password), email (SES, Postmark, or SendGrid), and one customer-data integration (whatever your buyers actually use).
What good answers look like: a list of 3–5 must-have integrations with rationale, and a list of 5–10 nice-to-haves explicitly deferred to V2.
What bad answers reveal: "we'll integrate with everything" is not a strategy, it's an admission that the founder hasn't picked. Pick.
6. What's the real deadline?
Not "ASAP." Not "as soon as possible." A specific date with a specific reason.
Real deadlines come from: customer commitments, demo days, fundraising timelines, runway dates, conference launches, regulatory cutoffs. They're external to the project. They have consequences if missed.
Fake deadlines come from: founder anxiety, generic urgency, and competitive paranoia. They're internal and changeable. They don't drive scope decisions because everyone knows they're soft.
The deadline matters because it shapes scope. A real 8-week deadline forces brutal prioritisation. A fake "ASAP" deadline lets scope creep without resistance. The first builds shipping products. The second builds endless development.
What good answers look like: "Customer demo on June 14. Need usable build by June 7. Can defer non-essentials past launch."
What bad answers reveal: "ASAP" or "no specific deadline" is a signal that the founder hasn't earned a deadline by selling the work in advance. Sell first, then build.
7. What's the real budget?
Same logic. A real number, not "what does it cost?"
The honest range for a small SaaS MVP is $8,000–$25,000 USD with one good developer over 8–12 weeks. If your budget is $2,000, you need no-code (Bubble, Softr, Glide), not code. If your budget is $200,000, you can hire an agency. Anywhere in between, you're hiring an individual freelancer.
The founder who refuses to share budget thinks they're protecting themselves from being overcharged. They're actually preventing the developer from giving honest scope advice. A good developer will tell you "with a $5,000 budget, here's what we can realistically do" or "for what you've described, you need at least $15,000." Without a number, neither conversation can happen.
What good answers look like: a specific dollar range with stated flexibility. "We have $15,000 for V1 with another $10,000 reserved for Q2 work."
What bad answers reveal: "what does it cost?" is a sign the founder is shopping for the cheapest quote rather than scoping a project. Cheapest quote is rarely the right hire.
8. What happens if it works?
The question most briefs skip — and the one that determines whether the developer makes good architectural decisions.
If V1 ships and you get 50 paying customers, what's the next 90 days look like? Add a team-sharing feature? Build mobile? Hit 5,000 customers and need to scale? Each answer points the developer at different architecture decisions today.
A developer who doesn't know what success looks like will optimise for shipping V1 and ignore the bombs they're planting in V2. The architecture choice that gets V1 out in 6 weeks instead of 8 might add 3 months to the V2 build. Knowing what V2 looks like is how V1 gets built well.
What good answers look like: a 1-2 paragraph description of what success unlocks — what features come next, what scale you're aiming for, what platforms you'd add.
What bad answers reveal: "we'll figure that out later" gives the developer no signal about which architectural shortcuts are safe and which are mortgaging the future. They'll guess. They'll guess wrong.
What a real brief looks like
A complete brief that hits all eight questions is usually 1–2 pages. Not 30. Not a video. Not a 12-tab Notion workspace. Just a clear document a stranger could read in 10 minutes.
Here's the actual structure I send to my own clients before we start:
PROJECT BRIEF — [Product Name]
THE BUYER (Q1, Q2)
[Persona, size, current solution, what they pay now]
THE PROBLEM (Q3)
[The specific job-to-be-done. The smallest version that helps.]
THE PRODUCT (Q3, Q4)
[3-5 features. Data model with key entities. What's deferred.]
INTEGRATIONS (Q5)
[Must-haves with rationale. Nice-to-haves deferred to V2.]
CONSTRAINTS (Q6, Q7)
[Real deadline with reason. Real budget with range.]
THE FUTURE (Q8)
[What happens if V1 works. What V2 might look like.]
That's it. Two pages. If your brief is longer, you're including things that don't help. If it's shorter, you're missing things that matter.
What happens after the brief
Send the brief to two or three candidates. Pay each of them $100–$300 for an hour of scoping conversation. Let them push back, ask questions, propose changes. The candidates who engage substantively are the ones to take seriously. The candidates who say "looks good, when do we start?" without any pushback are the ones to skip.
The best candidates often suggest cutting features you thought were essential. Listen. They're seeing scope creep that you've stopped noticing. The brief that survives a senior developer's pushback is the brief that ships on time.
What to do next
If your brief survives the eight questions and you'd like to talk, my service pages walk through the most common shapes: SaaS startups, bootstrappers, WordPress migration, and the Lead Steer retainer.
If you want to think about the next part of the engagement — the contract — read International Contractor Contracts: What Matters and What's Theater.
---
Part of the Offshore Hiring pillar guide.