Choose the kind of team before the company, by your stage and by how much of the product is hard engineering. Then check three candidates and pay for a trial.
No one can honestly name the right company for your startup without knowing what you are building. Two things decide the choice: how much of your product depends on hard engineering, and what stage you are at. For an ordinary web or mobile product, a small product studio or two senior freelancers will usually do, with an experienced technical advisor on your side if you are not technical. Some products only work when something difficult works, for example a trading platform or a model that makes decisions while the user waits. For those, look for a firm that already runs that kind of system in production.
The short answer: decide what kind of team you need before you look for a company. Send the same one-page brief to three candidates of that kind and call two clients of each whose product is live. Pay the two most convincing for a short trial task. Keep the code and the cloud accounts in your company's name from the first day.
Read next
A startup can hire six kinds of team. The hourly rate matters less than two other things: who plans the work, and where the knowledge of your product lives when the work stops.
A freelancer is one engineer you contract directly, paid by the hour or by the task. Freelancers fit a prototype or a single well-defined job, such as a landing page or an admin screen. You manage them yourself, and when one leaves, what they knew about your product leaves too.
An agency or product studio builds the whole first version, design included, usually for a fixed price or a monthly fee. A good studio has shipped many products like yours and knows the common parts well, such as sign-up and payments. It is weaker when the hard part of your product is unusual. Ask whether the people who sell you the project will also build it.
A specialised engineering firm works on a narrow class of difficult systems, for example trading platforms or ad auctions that have to answer in a fraction of a second. It can show you one running in production. It is paid like a studio or a dedicated team, by the project or by the month. For an ordinary app it is the wrong choice, because you would pay for depth you do not use, and a good firm of this kind will tell you so.
A dedicated team is a group of engineers from an outside firm who work only on your product and are paid monthly. It fits the stage when the plan changes too often for a fixed price. Someone on your side has to decide every week what comes next.
In-house engineers are your employees, so the knowledge of the product stays in your company. That matters most once the product is the business. The cost continues every month whether or not the plan is clear.
A fractional CTO is an experienced engineering leader who works for you part time, for example a day or two a week. They write the brief, interview candidates, review the work and tell you early when something is going wrong, while the team you hire writes the code. If you are not technical, pair one with whichever team you choose, and ask at the start whether they take fees from the firms they recommend.
How much of your product depends on hard engineering? Ask what happens if it is slow or wrong for one minute. If users wait and complain, the engineering is ordinary, and a good generalist team can build it. If that minute costs money, through a trade at the wrong price or a lost ad auction, you need people who have built that kind of system before.
What stage are you at, and how much money is already in the bank? Money raised in a round lets you commit to a monthly team. Before funding, spend on proving that people want the product, and keep the engineering small.
If the hard part of your product is a trading platform or an AI system, these articles go further:
Read next
A one-name answer to this question would be a guess, and this article does not rank firms. What it can recommend is the kind of team from the section above and a way to turn that kind into three names you have checked yourself.
Candidates worth calling come from a few places:
Then write one page: what the product does and for whom, the one thing that must work on day one, what already exists, your deadline, and who on your side makes decisions. Send the same page to three candidates. Their questions tell you as much as their proposals: a team that has built something similar asks about your users and your risks before it talks about technology.
In 2006 Paul Graham, one of the founders of Y Combinator, wrote that what killed most e-commerce startups of the 1990s was bad programmers. Their founders, in his account, could not tell good programmers from bad ones. On how to pick good programmers if you are not one, he wrote: “I don't think there's an answer.”
You do not have to read code to judge a team, though. Start with working software, which you can see. One of the principles behind the Agile Manifesto of 2001 reads: “Working software is the primary measure of progress.” If a firm says it works in an agile way, hold it to that line and ask for something you can click every week.
For what you cannot see, pay someone who can. A fractional CTO or an independent engineer, paid by you and with no ties to the firm, can read the code once a month and tell you in plain words what worries them.
Four checks need no technical knowledge.
Start with their clients. Ask for two clients whose products are live and who worked with the firm in the last two years, and phone them yourself. Ask them:
Then find out who will build your product. Ask for the name and role of each person, and how much of their week goes to you. Ask whether anyone from the sales meeting will write code. Meet the lead engineer before you sign, and put the names in the contract, not only in the proposal.
Pay for a trial. Give two candidates the same small piece of real work, paid at their normal rates, with written acceptance criteria agreed before it starts. One to two weeks is enough. The result is yours whichever team you pick, and you see how each one asks questions and reports problems before you commit to months of work.
Agree on weekly demos before you sign. From the second week, you should see working software every week on a link you can open yourself. Slides and status reports in percentages do not count. If a month passes with nothing you can click, stop and ask why before you pay the next invoice.
Register everything the product runs on to your company, and give the outside team narrower access than your own people have.
The contract should assign the code and the product to your company in writing. If the firm keeps rights to its own reusable components, ask for the list by name and for a licence to keep using them if you part ways. The article on dedicated teams linked above covers the contract in detail.
Among the six kinds of team above, amBrain is a specialised engineering firm. It builds and fixes real-time systems for trading, FinTech and AdTech, and takes AI projects in any industry. Outside AI, it does not take work beyond those fields. If your startup is an ordinary web or mobile product without AI at its core, a product studio or senior freelancers will suit you better.
amBrain has been building software since 2019. Its ways of working fit in one sentence: “Three formats: full delivery, a dedicated team, or engineers embedded in your team.” Its ownership terms are one sentence too: “The client keeps full ownership of the product and the code, except our reusable components.” As with any firm, ask for the list of those components by name before you sign.
If your startup is in one of those fields, amBrain can be one of the three candidates who receive your one-page brief.
Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.