Start with the job you need done
A first engineer gives you daily build capacity and growing product knowledge inside the company. A fractional CTO takes responsibility for technical direction within an agreed remit. An agency gives you a delivery team. Those jobs overlap, but the titles don't tell you which responsibilities are included.
- Hire your first engineer
- When you have sustained work for a senior builder, can assess candidates, and know who will support their technical decisions.
- Bring in a fractional CTO
- When architecture or hiring decisions are blocking progress. Agree separately who writes the code: a CTO on their own and a CTO with a build team supply different capacity.
- Use an agency
- When you can define a delivery outcome and have someone able to review the work and accept responsibility for it afterward.
We sell fractional CTO engagements with a build team, so we have a commercial interest here. At Systellar Space, Wojciech helped screen and interview candidates for their first in-house senior engineer/architect. When we screen alongside a founder, we are testing whether someone can work in the codebase they will inherit. They've now made that hire. Read the Systellar engagement.
When your first engineer is the right next step
If the next year contains steady product work, hiring someone who learns your field every day makes sense. You keep that context in the company, and the person doing the work sees the consequences of their decisions over time.
Can you tell a strong first-engineer candidate from someone who worked well inside a mature team? Your first hire may have nobody to review their code or help with production problems. Look for experience taking a product through those conditions, and arrange independent technical assessment if you can't evaluate it yourself.
A senior engineer can own architecture too. Make that responsibility explicit in the role and compensation. If the job also includes recruiting a team and representing technical risk to investors, you've expanded it beyond a build role. One person's time still has to cover all of it.
What outside help should leave for the hire
Judge any external arrangement by what your first engineer inherits. A fractional CTO earns its place when the job description is stuck because nobody can say what the engineer will inherit: the state of the code, the architecture, which skills matter. They can settle that while you recruit, then review the new hire's work. An agency earns its place on a bounded release, as long as someone on your side can check that your future engineer can change what it delivers.
Either way, a working demo is not a handover. Budget for review and overlap, and if you need software built during the search, ask for named delivery capacity rather than advisory days. For the full comparison of these options on cost, equity, and risk, read Technical co-founder, fractional CTO, or agency.
Agree on ownership before work starts
Keeping engineering in-house may be a firm requirement. That's a valid decision. You can still buy a one-off review or help assessing candidates without handing over delivery. If external involvement itself is off limits, recruit directly and plan for the search time.
With any external arrangement, separate legal ownership from operational responsibility. Your contract should address IP assignment and third-party licences. Your company should control the repository and infrastructure accounts from the start, because owning code on paper won't help if only the supplier can deploy it.
- You own product priorities and budget. A technical partner explains consequences and recommends a path. Agree who can approve spending or change scope.
- Name the technical decision-maker. State who approves architecture, reviews changes, and accepts known risks. A fractional CTO's title alone grants no defined authority.
- Assign production responsibility. Write down who deploys, handles incidents, and maintains backups, including availability and response expectations.
- Define the exit. Agree notice, handover work, its cost, and how access changes. Keep decision records in the repository throughout the engagement.
Compare time to useful work
What needs to happen between signing and useful work? When you compare an agency's proposed start date with a candidate's notice period, include the time each will spend understanding your existing system before they can make changes you'd trust in production. That interval is the one nobody puts in the proposal. It costs real time.
Treat these as planning ranges. Check them against candidate notice periods, supplier capacity, and your codebase.
- First engineer: allow 3-6 months from opening the search to starting
- Interviews, offer negotiation, and notice periods can all affect this. After joining, allow roughly 2-6 weeks for orientation and initial contributions. Full operational independence can take longer.
- Fractional CTO: allow 1-4 weeks to agree scope and begin
- Subject to availability. Early work can clarify risks and the hiring brief. Delivery dates still depend on who builds and what they're taking on.
- Agency: allow 2-6 weeks for selection, scoping, and mobilisation
- Discovery may be a separate paid stage. Ask for a schedule tied to a specific release and its acceptance criteria.
If work cannot wait for a hire, cover the urgent part while keeping recruitment open. That adds coordination and an overlap bill. It only makes sense if the work done during the search leaves your new engineer with less uncertainty.
Budget for the overlap
The first hire costs more than a salary: employer contributions, equipment, onboarding, recruiter fees if you use one, and equity if it's part of the offer. Equity is dilution even when it doesn't use cash. If an external team is involved, count the weeks when they and your new hire work side by side, plus your own time.
Put hiring overlap on the budget before you choose a provider. Ending the external engagement the day someone joins saves an invoice while leaving the new hire to reconstruct decisions alone, and the learning time that follows still gets paid for.
Make the hiring handoff something you can check
A handover needs more than documentation. Your incoming engineer should demonstrate they can work with the system while someone who knows it is available to help. Agree the following checkpoints before the external engagement winds down. Three of them matter most.
- Before recruiting: describe the codebase, known risks, and decisions the hire will own. Use that to assess candidates against the work they'll actually do.
- During onboarding: have the engineer set up the project, ship a small change, and practise deployment and rollback in a safe environment.
- Before transferring responsibility: review monitoring and recovery procedures, confirm account access, and name the new incident owner. Record remaining gaps and agree whether any time-limited support remains.
Systellar's first in-house hire is evidence of recruitment alongside an external partnership. Our engagement there is still ongoing. It isn't proof of a completed exit, and a responsible handoff shouldn't be rushed to make the story tidier.
Decide what needs resolving before you hire
If you're choosing the role or deciding how much help to keep outside the company, bring the job description and your next milestone to a free 30-minute architecture call. We can talk through where responsibility belongs. The call won't establish whether an existing codebase is safe to inherit.
If that codebase is the uncertainty, our technical audit is €4,900, fixed scope, with a report in 7 business days. The same free call can be used to agree the areas to review. You get a written report, prioritised findings, and a live debrief to inform the work ahead, whether your next step is hiring, an agency, or a partnership.
Still deciding whether you need a technical co-founder? Our co-founder decision guide covers the equity and long-term partnership question separately.
If you already know what to build, can assess the candidates, and have enough work and runway for a senior hire, you may have everything you need to recruit directly.
Questions founders ask about the first hire
How long does it take to hire a first engineer?
Allow three to six months from opening the search to someone starting. Interviews, the offer, and a notice period all sit in that window, and the senior candidates who are worth hiring are usually employed and not in a hurry. Nothing about an external partner shortens the notice period, so start the search before the work becomes urgent.
Do I need a fractional CTO before hiring my first engineer?
Not always. You need one when you cannot yet describe what the engineer will inherit: which decisions are already made, which parts of the codebase are risky, and what the role actually owns. Writing that down is the work, and if nobody on your side can write it, that is the gap to fill first.
Should I hire my first engineer or retain someone part-time?
Hire the engineer when you can direct the work yourself and the decisions are already shaped. Retain someone part-time when the open question is what to build and how it should be put together. One produces code, the other produces decisions about it. What you get with a first hire is hours, and hours are not judgment.
Who reviews the first engineer's work?
Whoever you name, and it should be named before the offer. A senior engineer with nobody above them is being asked to review themselves, which works until the architecture is the thing that is wrong. Independent review is a line in the budget, not a favour to ask later.
Should the first hire own architecture?
Only if you say so in the role and pay for it. Architecture ownership, team building, and representing technical risk to investors are three jobs, and one person's week has to cover all of them. A title that implies all three without the compensation is how a good engineer leaves in month nine.
Can we start with an agency and hire later?
Yes, and it works when the agency hands over to a person you have already hired. The expensive version is the handover to nobody: the engagement ends, the invoice stops, and your new engineer reconstructs the decisions alone. Overlap costs money and is usually cheaper than the alternative.
What does an external partnership cost compared with a salary?
A first engineer is a recurring salary plus employer costs, equipment, onboarding, and often equity. A retainer is a monthly fee for a defined remit that you can stop. Neither is cheap. The hire stays, so the context keeps accumulating. Whatever a retainer learns leaves with it unless the handover puts it back in your repo.