Short answer: if software is your product and you can find the right person, a technical co-founder is the strongest option and the hardest to get. If you cannot, build the first version with a studio or a proven freelancer, keep ownership of everything, and make your first engineering hire once you have users and a roadmap to show candidates. Hire employees for work that is continuous; buy project capacity for work that ends.
Disclosure and scope. BBR is a software studio, one of the five options below. The sections on equity and contractor status are general background, not legal, tax or financial advice. Rules differ by country and state; use a qualified adviser.
The five options
| Option | What you get | Cost shape | Best when | Main risk |
|---|---|---|---|---|
| Technical co-founder | A partner who builds and owns technical direction | Significant equity, little or no cash | Software is the business and you have someone you trust | Hard to find; a bad match is expensive to undo |
| First employee (founding engineer) | Full-time commitment and accumulated product knowledge | Salary plus a smaller equity grant; recruiting time | Demand is proven and there is steady work | Hiring the wrong person with nobody able to judge; one skill set only |
| Freelancers | Flexible capacity in a specific skill | Hourly or per task; no overhead | Narrow, well-defined work; someone on your side can manage | Continuity and coordination fall on you |
| Studio / agency | A managed team covering design, build and release | Project or monthly fee; ends when the work ends | First version, fixed deadline, no technical lead | Vendor choice; dependency if ownership is not set up properly |
| Staff augmentation | External engineers inside your team and process | Monthly per person | You have a technical lead and need more hands fast | Provides capacity, not direction; useless without leadership |
These are not exclusive. A common and sensible sequence is studio for the first release, first employee once it has traction, then freelancers or augmentation for spikes. The trade-offs between the two outsourced options are covered in agency vs freelancer.
What to hire first, by product type
| Product | First capacity to secure | Why |
|---|---|---|
| Web SaaS, B2B | A full-stack engineer comfortable with a mainstream web framework and a relational database; part-time product design | Most of the work is forms, data, permissions and billing. One strong generalist covers a lot |
| Consumer mobile app | A cross-platform mobile engineer plus backend capacity, with real design input from the start | Consumer apps are judged on feel. Design is not optional, and store release is its own skill |
| Two-sided marketplace | A small team rather than one person, or a studio | Two interfaces, payments with payouts, and admin tooling are too broad for a single hire to ship quickly |
| AI-based product | A product-minded software engineer experienced with hosted model APIs | Most AI products are software built around a model someone else trained. Research hires come later, if at all. See how to build an AI product |
| Deep-tech or proprietary algorithm | A technical co-founder or senior specialist in-house | The knowledge is the company. It should not sit with a vendor |
| Hardware with a companion app | Firmware and hardware expertise in-house; app can be outsourced | The app is a bounded project; the device is the core |
| Software that supports a non-software business | A studio or freelancer, not an employee | There is rarely enough continuous work to keep an engineer occupied and interested |
A note on seniority: for a first hire, experience matters more than it will later. The first engineer makes decisions about structure, data and infrastructure that the company lives with for years, and has no one to review them. One senior generalist is usually worth more at this stage than two juniors.
How a non-technical founder can vet technical ability
You cannot judge code, and you do not need to. You need evidence that does not depend on the candidate's own description of themselves.
1. Shipped work you can use
Ask for links to live products: apps in the stores, web apps you can sign up for. Use them. Then ask exactly what the person built, what they would change now, and what was hardest. People who did the work answer in detail and volunteer the flaws. For a studio, the same applies; ours are listed in the case studies.
2. A paid trial task
Give finalists a small, real piece of work, a few hours to two days, and pay for it at their normal rate. Paying is fair, and it keeps strong candidates in the process. Evaluate what you can see yourself:
- Did they ask clarifying questions before starting?
- Did they deliver when they said they would, or tell you early that they would not?
- Does the result work when you follow their instructions?
- Is the written explanation clear to a non-engineer?
3. Independent code review
Pay an experienced engineer with no stake in the outcome for an hour or two to review the trial code and, ideally, join one interview. You can find such a person through your network, an adviser, or a fractional CTO. Ask them three things: is it readable, is it structured sensibly, and would you be comfortable inheriting it?
4. Reference calls
Speak to people who have worked with the candidate, preferably ones you find yourself as well as ones they supply. Useful questions: What did they own? How did they behave when something went wrong? Would you work with them again, and in what role?
5. How they explain things
Ask the candidate to explain a technical trade-off in your product to you, in plain language. An engineer who can make you understand it will also be able to work with customers, designers and future hires. One who cannot, or will not, becomes a bottleneck in a small company.
Signals that mean little
- Years of experience on its own
- Long lists of technologies on a CV
- Whiteboard puzzles, which test a skill you do not need
- Confidence in an interview
When the candidate is a company rather than a person, use the same evidence-first approach with our list of questions to ask a development agency.
Equity versus cash: the basics, stated cautiously
This section describes common practice in general terms. It is not advice; equity has legal and tax consequences that depend on where you and the recipient are based.
- Co-founders typically receive a substantial share of the company in exchange for working for little or no salary at the start. Shares normally vest over several years, commonly with a one-year cliff, so that someone who leaves early does not keep a large stake.
- Early employees typically receive a market or somewhat below-market salary plus a much smaller grant, usually as options, also vesting over time.
- Freelancers and agencies are normally paid in cash. Offers of equity in place of fees are declined by most established vendors, because they cannot pay their own staff in your shares. A vendor willing to work for equity alone deserves extra scrutiny, not less. (BBR does not take equity-only or deferred-payment projects.)
- Equity is not free. It is the most expensive currency you have if the company succeeds. Use it for people whose long-term commitment you need, not to reduce a short-term invoice.
- Put it in writing. Verbal promises about ownership are a frequent cause of founder disputes. Vesting terms, IP assignment and what happens on departure should be documented by a lawyer at the start.
A workable hiring process
- Define the work, not the title. Write down what needs to exist in six months and which skills that requires.
- Choose the capacity type using the tables above.
- Write an honest description: stage, funding, what is built, what is not, salary range and equity range. Strong candidates filter on honesty.
- Source through referrals first, then communities and boards.
- Screen on shipped work, then hold one conversation about how they would approach your product.
- Run the paid trial with two or three finalists, with an independent reviewer.
- Check references.
- Make a written offer with IP assignment and confidentiality terms, reviewed by a lawyer.
- Onboard deliberately: access to everything, a first task that ships within a week, and a scheduled check-in at 30 days.
Common mistakes
Hiring before you know what to build
An engineer without a defined problem will build something, and you will pay for it. Do the customer interviews and write the scope first. Our guide to building an MVP step by step covers that groundwork.
Hiring the cheapest option for the most important decisions
The first version sets the data model and architecture. Saving on seniority here is often repaid with a rewrite.
Hiring a specialist when you need a generalist
A startup with one engineer needs someone who can do database, API, front end and deployment adequately, not someone who does one of them superbly.
Giving away equity under time pressure
Large grants to people you met a month ago, with no vesting, are very hard to reverse.
Not owning the accounts
Repository, cloud, domain and app store accounts should belong to the company from day one, whoever writes the code.
Treating contractors like employees without checking the rules
In several countries, a long-term, full-time contractor working under your direction may be classed as an employee. Ask an accountant or lawyer before the arrangement becomes long-term.
Waiting for the perfect co-founder
Months spent searching are months without learning from users. If the search is not converging, a working first version built by an outside team often makes the co-founder or first-hire conversation easier, because there is something real to join. See building an MVP without a technical co-founder, or how BBR approaches software development for startups.