Hire Engineers or Bring In a Technical Partner: How to Cost Both Paths

You have the idea for a trading terminal, a budget for it, and no engineering team. The question that follows is almost always framed as a price comparison: what does it cost to hire engineers, and what does it cost to have a firm build the thing and hand it over.

That framing hides the decision. Both paths end with code that runs. They differ in when the first usable version exists, who understands the system a year later, what happens when a key person leaves, and what you are holding if the work stops.

Both paths produce code; they differ in where the knowledge lives

A trading terminal is not one system. It is a market data path, an order entry path, pre-trade risk checks, connectivity to venues or brokers, position and account state, a screen that has to keep redrawing while the book moves, and a back office that reconciles all of it after the close.

When you hire, you are not buying that system. You are building the organisation that will produce it, and the knowledge of how it works starts at zero and accumulates inside the heads of people you employ. That is an asset while they stay and it is the entire risk when they do not.

When you contract a partner, you are buying a system plus a decision history that already exists somewhere else. The knowledge starts higher and sits outside your company on day one. Whether it ever moves inside is a contract term and a working practice, not something that happens on its own.

It helps to be concrete about what knowledge of the system means here, because it is not the source code:

• Why the sequencing scheme is the one it is, and which failure it rejects that a simpler scheme accepts
• Which venue behaviours the connectivity layer works around, and which incident each workaround came out of
• The order the risk checks run in, and what the system does when one of them does not answer in time
• The recovery procedure when the market data feed gaps and the book has to be rebuilt mid-session
• Which tests are load-bearing and which ones only look like coverage
• What the deploy path is on a volatile morning, and who is allowed to run it

None of that lives in a repository by default. It lives in a person until a process forces it into writing, whether that person is your employee or a partner engineer.

The first usable version is decided before the first commit

The hiring path has a queue in front of it that budget does not remove. You write a role you can defend technically, source in a market where trading engineers are scarce, interview for skills nobody inside your company can yet evaluate, wait out notice periods, and then spend the first stretch watching a new team argue about an architecture rather than build one.

The partner path starts at scope instead of sourcing, which is where the time difference comes from. What it does not remove is the work only you can do: deciding what the terminal is for, which instruments and venues matter first, and who the first users are.

And some of the schedule belongs to neither path. These items run at their own pace no matter who is writing the code:

• Broker or venue onboarding, and the paperwork sitting behind it
• Conformance testing in the venue test environment, in windows the venue schedules and you do not
• Market data licensing, which decides what you are allowed to display and to whom you may redistribute it
• Clock synchronisation, audit trails and whatever record keeping your regulator expects
• The first users being willing to route real orders through a system that is new
• Your own product decisions, especially the two that contradict each other

So the honest comparison is not a race between two delivery dates. It is a question of which path puts fewer things you cannot influence in front of the work, and which one starts the parts you can influence sooner.

What each path does when a key person leaves

Put the same question to both paths. If the engineer who wrote the market data handler stops working on Monday, what happens on Tuesday, and what happens in the quarter after that.

In a small team you have hired, the answer usually depends on one name. Early teams concentrate knowledge by design: one person owns the hot path, another owns connectivity, and the roadmap quietly reorganises itself around whoever is still there. In a partner arrangement it depends on whether more than one engineer there has read the code, and on whether your contract says so.

Neither structure is safe by itself. A partner with a single engineer on your account is exposed the same way a two-person in-house team is, and the defence is identical in both cases: knowledge written down while it is being created rather than reconstructed after the fact.

• A design note per subsystem stating what it does, what it deliberately refuses to do, and what breaks it
• Decision records with the alternatives that were considered, kept in the repository next to the code they explain
• Tests that replay a captured session, so a failure is reproduced exactly instead of argued about
• At least two people who have merged changes to each critical path - a staffing rule, not a documentation rule
• A runbook for every incident that has actually happened, written the week it happened
• A deploy and rollback path any on-call engineer can run without waking someone up for a password

Handover is a deliverable with an acceptance test, not an email at the end

The word handover covers two very different events. One is a transfer of files. The other is a transfer of the ability to keep going without the people who built it, and only the second one is worth paying for.

Write the second one into the scope as a list of artefacts with an acceptance test attached to each. A reasonable list looks like this:

• Repositories with their full history, not an archive of the final state - history is where the reasoning is
• A build a new engineer reproduces on a clean machine from the written steps, with no undocumented local setup
• Infrastructure described as code, together with the environments it produces and the way they differ
• Secrets held by you, with a rotation procedure that has been executed at least once rather than described
• Deployment and rollback runbooks, run by your side while the partner watches and says nothing
• Monitoring, alert thresholds, and one line per alert explaining what it means and what to do about it
• Protocol and message specifications for every external connection, including the fields you use and the ones you ignore
• The test suite, plus a demonstration of tests failing on purpose, so you see what they catch
• A named period in which your engineers make the changes and the partner only reviews them

A handover that has never been rehearsed is a plan, not a deliverable. Rehearse it in the middle of the build, not after the final invoice, and the rehearsal is simple: your engineers deploy a change and roll it back while the people who wrote the system watch.

Ownership is a separate question from handover, and it is settled in the contract before the work starts rather than discovered at the end. Our own answer is one sentence, and we do not shorten it in any version of any document.

Three formats sit between the two answers

The question is usually posed as a binary - hire a team or hand the whole thing to someone else. In practice most builds sit between those poles, and the position is allowed to change as the system matures.

Three formats: full delivery, a dedicated team, or engineers embedded in your team. That is how we describe our own side of it, and the difference between the three is not the invoice - it is who holds the plan, who holds the priorities, and who is accountable for the result.

• Full delivery: the partner holds the plan, the sequencing and the outcome; you hold product decisions and acceptance. It fits a first version with a scope you can define and no team to manage yet
• A dedicated team: your backlog and your priorities, their people working on your product and nothing else. It fits the stage where scope moves faster than a fixed plan tolerates
• Engineers embedded in your team: your process, your code review, their specialists on the paths where a mistake is expensive - the order path, venue connectivity, the recovery procedure
• The three are steps rather than exclusive options. A build can start as full delivery and end with two engineers inside a team you hired while the system was being written

That last point dissolves most of the original question. The strongest version of the partner path plans for your own team from the beginning: you hire against a system that already exists, your interviews are informed by the code the candidate will maintain, and the first thing a new hire reads is a decision record instead of a blank repository.

Cost both paths, including the parts that never appear on an invoice

A rate comparison is the least useful number in this decision, because the two paths bill you in different units. Put both lists side by side and cost them honestly.

The hiring path charges you for:

• Recruiting time, and the cost of one wrong hire in a specialist market where the wrong hire is discovered late
• Employer costs, equipment, licences, and the market data subscriptions a development environment needs before it produces anything
• Management attention - somebody has to run the team, and at the start that somebody is usually you
• The first architecture decision made twice, once wrong, which is the normal price of a team learning a domain on your build
• Capacity that outlives the build, when a team sized for construction is larger than maintenance requires
• A standing obligation that continues whether or not the roadmap is clear this quarter

The partner path charges you for:

• A rate that carries specialists you would never keep busy full time on your own, such as an engineer who has debugged a session-level protocol before
• Coordination across a boundary, which is real work and is paid in written specifications rather than hallway conversations
• A dependency that lasts exactly as long as the handover stays untested
• The risk that reusable components are load-bearing in ways nobody wrote down, which is why the ownership clause has to be read before signature
• The cost of specifying: a partner is only as accurate as the decisions you hand over

Then cost the exits, because both paths have one. The hiring path ends by reducing a team you built, and the knowledge walks out in those heads. The partner path ends with a handover you either rehearsed or did not, and the distance between those two endings is the risk of the path.

Before you sign anything, run both options through one question: if this stopped on Friday, what would we still hold on Monday. Answer it in artefacts - repositories, reproducible environments, documentation, and people who can rebuild the system from them - because intentions do not survive a departure and artefacts do.

What amBrain can substantiate publicly: we have been building software since 2019 from Yerevan, Armenia, with hot paths written in Rust, we built the Spectre Trade trading terminal, and a mini-exchange we built runs in production on MOEX colocation. If you are weighing a hire against a partner for a terminal of your own, take the handover list above into the first conversation and ask whoever is across the table, ourselves included, to answer it line by line.