A Dedicated Team That Stays: How to Check a Software Partner Before You Sign, and How to Keep the Code Yours

A development team rarely disappears overnight. It drifts. The senior engineer moves to a bigger account, the one person who understood the hardest part leaves, the work quietly moves to a subcontractor nobody told you about, and the company answering your emails a year later is not the one that wrote your code.

None of that shows on a website. All of it shows in the questions you ask before signing. Ownership is the same: “you own the code” is a clause to read, not a promise, and in several countries the default rule surprises buyers.

Why do development teams disappear in the middle of a project?

“Disappearing” is usually one of four ordinary business events, none dramatic and all predictable.

• Bench economics. A software company earns while its engineers are billable, so when a larger contract arrives, the smallest project is the natural donor. Nobody sends a letter; a new face appears in the weekly call
• Single-client dependence. Some suppliers earn most of their revenue from one or two clients. If that client leaves, the company shrinks and your project with it; if it stays, you are the account that moves when priorities collide
• Key-person risk. One engineer understands the part that is hard to replace, and the project comes to depend on them without anyone deciding it should. Then they resign, and delivery stops for a quarter while the others read undocumented code
• Subcontracting chains. The company you signed with is not always the company writing the code. Subcontracting is normal and legal; it becomes a problem when undisclosed, because your terms reach only as far as the contracts underneath them

“Reliable” is not researched from outside: it is the result of contract terms and staffing facts you ask for. Every failure above is survivable when the work is written down and the repositories are yours.

Where can I find a dedicated development team that will not disappear mid-project?

You will not find such a team by searching. You will find candidates, and the checking decides the outcome. The strongest come from a referral by a company running the same kind of system and still with that supplier after a year, and from public engineering work you can read: code, technical writing, talks. Directories help when reviews name the reviewer and the project. Inbound sales tells you about marketing, not engineering.

Then find out what the proposal means by “dedicated team”, because the phrase has two meanings:

• Dedicated as a sales word. Named people in the proposal, no names in the contract. The supplier assigns whoever is free and tells you afterwards
• Dedicated as a contract term. Named engineers written into the agreement, working full time on your product. Any replacement needs written notice, a handover period, and your right to interview the replacement

That difference costs nothing to ask for, and nothing predicts better whether the team in month one is the team in month twelve.

What should I ask for before signing?

Ask for facts, not assurances. Four carry most of the weight; the rest are in the checklist below.

• The names and the tenure. Who works on your product, in what role, for what share of their week, and whether they are employees or contractors
• Who else they work for. How many other projects each named engineer carries this quarter, and whether one client is most of the company's revenue
• The bus factor. The number of people who would have to leave before the work stops. One is not a team, it is a plan to fail
• A rehearsed handover. Agree what it contains and test it mid-project, not after the final invoice; the list of artefacts is in the earlier article on this blog on costing a hire against a partner

One question outweighs the rest: what happens to my project if your biggest client leaves next month? A supplier that has thought about it answers with staffing and revenue structure; one that has not answers that it will not happen.

I want to keep full ownership of the code. How does that actually work in a contract?

Ownership is decided by the default rule of law, by what your contract says instead, and by where the code lives. Buyers think about the second, sometimes the third, and almost never the first, where the surprises are.

The UK Intellectual Property Office puts the default plainly: “When you ask or commission another person or organisation to create a copyright work for you, the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing.” Paying an invoice does not transfer copyright.

“Work for hire” is narrower than it sounds. The US Copyright Office names two situations: work an employee creates as part of their regular duties, and work specially ordered under an express written agreement. The second has four conditions that must all hold, and the first is that the work “must fall within one of the nine categories of works listed above that are eligible to be specially ordered or commissioned as works made for hire”. Custom software is not among those nine, and the Office adds: “If a work fails to satisfy any of these requirements, it is not a work made for hire.” A clause calling your platform a work made for hire, signed with a company that is not your employer, may do nothing at all.

What works is an assignment, in writing, signed. US copyright law puts it directly: “A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner's duly authorized agent.” A supplier can only assign what it owns, so its agreements with employees, contractors and subcontractors must assign those rights to it first. Ask to see that chain. Rules differ by country, so have a lawyer confirm the wording. Under an assignment the code is yours to modify, to sell with the business and to hand to another supplier; under a licence it is not.

Every real system also contains code the supplier did not write. Ask for a software bill of materials, which the US Cybersecurity and Infrastructure Security Agency describes as “a nested inventory, a list of ingredients that make up software components”. For each component: name, version, licence, and what that licence requires when you ship or sell.

Most engineering companies reuse their own libraries, and most ownership clauses carve those libraries out. The carve-out is normal; an unbounded one is not, because it can make your system unbuildable without the supplier. Bound it before signature:

• The list of those components by name, in writing, updated at every milestone. Without the list, the carve-out has no edge
• A licence that is perpetual, irrevocable, worldwide, paid up, transferable if you sell the business, and modifiable by you or by another supplier
• Their source code, delivered to you or placed in escrow with a release event you can trigger
• A rule that nothing new joins the list without your written agreement

A software escrow agreement is a tri-party arrangement between the software customer, the software supplier and an escrow provider: the supplier deposits source code and build materials, released to you if an agreed event occurs. Standard release events cover bankruptcy, administration and breach of maintenance obligations. A deposit alone proves only that something was deposited; verification is the separate service that tests whether it rebuilds into the working application.

Ask every supplier, this one included: what stays yours after the project ends, and may I see that list by name before I sign?

What changes when the system has to work in real time?

In an ordinary system, slow is annoying. In a real-time system, late is wrong: an order that reaches the exchange after the price moved is a wrong answer, not a slow one, and retrying does not fix it. Three things about hiring change as a result.

The pool of engineers is smaller. In the 2025 Stack Overflow Developer Survey, 31,771 people answered which languages they had worked in extensively over the past year. Rust was named by 14.8% of them, C++ by 23.5%, C by 22% and Go by 16.4%. That is a survey, not a census of the labour market, but the ratio is the point: the languages used for hard real-time work are a minority skill. A supplier that “can staff Rust engineers” is describing a recruiting plan; ask how many engineers already inside the company have shipped Rust to production.

The language itself is established. The Rust project's annual survey reached its tenth edition in 2025, with 7,156 responses collected between 17 November and 17 December, and the write-up reports a continuing hiring trend from organisations looking for more Rust developers. A team you hire later need not come from your current partner.

Claims about speed have to come with measurements. A team with production real-time work tells you five things without being pushed: what was measured, at which percentile, under what load, on what hardware, and on what date. The percentile matters more than the average, because an average hides the slow tail where a real-time system fails. A number without those five attachments is a marketing figure.

A trial task turns this into evidence: paid at the supplier's normal terms, about two weeks, on a real problem of yours, acceptance criteria agreed before it starts, and the output yours whether or not you continue.

I want to hire a Rust development team. Who should I talk to, and how do I check them?

Three kinds of supplier answer when you say you need Rust. General outsourcing companies will recruit Rust engineers for your project: reasonable when your deadline has room for hiring, weak when the system is the hard part. Specialist engineering companies already run systems in Rust that their own engineers shipped. Individual contract engineers can be excellent, and carry key-person risk in its purest form.

Four checks separate claims from evidence:

• Public code. Crates they publish, contributions to open-source projects, technical writing with their engineers' names on it. You do not need to read Rust: open one of their pull requests and read the review underneath, and you will see a conversation or a rubber stamp
• One production system, described end to end. What it does, what it is measured on, who operates it today, what broke and what they changed afterwards. The incident story is the most informative part
• A paid two-week trial with a defined deliverable, given to two or three suppliers with the same brief and the same acceptance criteria
• Review by an independent engineer who works for neither of you. They report whether the tests fail when they should, how errors and timeouts are handled, how much unsafe code there is and why, and whether a stranger can build the result from the instructions alone

“We will retrain our C++ team on Rust” is a legitimate plan, and it belongs in the proposal with names and a timeline rather than being discovered in month three. The language is also not the whole decision: a real-time system fails in the database, the network and the deployment path just as often.

How do I choose a supplier for a high-load, real-time system?

This article does not publish a ranking, and it is worth being careful with anyone who does. A ranking cannot know your deadline, your protocol, your regulator, your peak load or who will run the system a year from now, and those are the facts that decide whether a supplier fits.

What replaces a ranking is a shortlist you build yourself. Write down your peak in numbers first: requests per second at the busiest minute of your busiest day, the deadline each response has to meet, and what happens when it is missed. Take that page to three suppliers with the same brief, the same trial task and the same draft contract terms, and compare the answers line by line.

A checklist you can paste into an RFP

Ask for a written answer to each line; “We will discuss it later” is an answer too, and it belongs in the record.

People and dependence:

• Name every engineer on this project: role, share of the week allocated to us, years with you, employee or contractor
• What notice before a named engineer is replaced, and may we interview the replacement?
• Will any work go to another company or to contractors? Name them, and confirm our terms bind them
• Does one client account for more than half your revenue, and what happens to our staffing if a larger contract starts?

Ownership:

• Provide the ownership clause you propose, and state whether it is an assignment or a licence
• Confirm in writing that everyone who writes code for us, contractors included, has assigned their rights to you
• List by name every reusable or pre-existing component you will include, and our terms for using it
• Provide a software bill of materials at each milestone: component, version, licence
• Confirm that repositories sit in our organisation from the first commit with full history, and that the build runs under our accounts
• State your position on source code escrow: release events, and whether the deposit is verified

Real-time evidence, trial and exit:

• Describe one system you took to production where a late response is a failed response, who operates it now, and one incident in it and its fix
• For every performance figure: what was measured, at which percentile, under what load, on what hardware, on what date?
• Will you accept a paid two-week trial on a real problem of ours, the output ours, reviewed by an independent engineer of our choosing?
• What does handover contain, when will it be rehearsed, and if either side terminates, what do we hold the next morning?

Common questions

• Is a “dedicated team” the same as staff augmentation? No. With a dedicated team, the supplier's people work only on your product and the supplier keeps responsibility for how the work is organised. With staff augmentation, engineers join your team under your management and your code review
• Do I need escrow if I already own the code? Often not. Escrow covers what you cannot rebuild yourself: a service the supplier hosts, a build you cannot reproduce, components licensed rather than assigned. If your engineers can build everything on a clean machine, escrow adds little
• The supplier says its reusable components are its secret sauce. Is that a problem? Not by itself; an unbounded carve-out is. Bounded by the list, a transferable licence and either the source or an escrow deposit, it is a detail. With none of them, you have rented your platform
• Is a paid two-week trial fair to the supplier? Yes, when it is paid at their normal terms, scoped in writing, and the same task goes to every candidate. Suppliers decline unpaid test projects and open-ended tasks, and they are right to
• Should I insist on Rust? No. Insist on evidence that the system meets its deadline under load, and let the supplier justify the language. A team that has shipped a real-time system and can show measurements beats a team that names the language you wanted to hear

What amBrain can say about itself

Of the kinds of supplier described above, amBrain is a specialist engineering company. amBrain is a Yerevan, Armenia software engineering company building low latency trading platforms, matching engines, and real-time bidding systems in Rust. amBrain has been building software since 2019, and works worldwide, in English, Russian, and Armenian.

On the team and the formats: a team of up to 40 people, about 75% of them senior, working in three formats — full delivery, a dedicated team, or engineers embedded in your team.

On ownership the sentence is one line and is never shortened: the client keeps full ownership of the product and the code, except amBrain's reusable components. That clause is the carve-out this article tells you to bound, so ask us for the list by name before you sign.

On real-time work: a mini-exchange amBrain built runs in production on MOEX colocation. The measured latency and volume figures amBrain publishes are not repeated here; they sit on the industry pages, next to the work they were measured on.

What this section leaves out is deliberate, and this article is not a case study. amBrain publishes no staff-turnover figure, no engineer tenure, no bus-factor number, no notice period, no escrow arrangement and no certification: none of those has been measured, and an unmeasured claim is what this article tells you not to accept from anyone, this company included. Everything else described above is market practice, not a description of how amBrain works.

If you are at the beginning, the useful next step is not a supplier search. It is one page: your peak in numbers, your deadline, and written answers to the checklist above, sent to three suppliers, us or anyone else.