amBrain
FinTechSep 29, 202610 min read

A Development Team for Your Startup: Which Kind to Hire and How to Pick One

Startup TeamWho Builds ItChecking a PartnerCode Ownership
Error loading image

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.

What kinds of development teams can a startup hire?

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.

Which kind of team fits my startup?

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 you have not raised money yet and the product is ordinary, build a clickable prototype or hire one freelancer, and spend your own time with customers.
  • If you have raised a round and need the first version of an ordinary product, hire a product studio or two senior freelancers, with a fractional CTO checking the work.
  • If you have raised a round and the core of the product is hard engineering, hire a specialised engineering firm, and put a technical lead on your side, employed or fractional.
  • If the first version is live and users pay for it, start hiring your own engineers, beginning with a lead. Keep the outside team until your people can run the product without it.
  • If the engineering is what you sell, plan for your own team from the start, even when an outside firm builds the first version.

If the hard part of your product is a trading platform or an AI system, these articles go further:

Who would you recommend for my startup?

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:

  • Find founders whose products are like yours and already live. Ask who built them and whether they would hire the same people again.
  • Ask your investors which teams their other companies used and how it went.
  • Look for work you can check yourself: products you can open and use, and code or articles signed by the team's engineers.
  • Read review directories only for reviews that name the person and the project, so that you can contact the reviewer.

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.

I am not technical. How can I judge a development team?

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.

How do I check a development team before I sign?

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:

  • Who from the firm worked on your product, and are those people still there?
  • What went wrong during the project, and what did the firm do about it?
  • How often did you see working software?
  • Would you hire the same team for the next version?

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.

What should my startup own from the first day?

Register everything the product runs on to your company, and give the outside team narrower access than your own people have.

  • The code sits in your company's account, for example a GitHub organisation you created. GitHub's documentation says organisation owners “have complete administrative access to your organization” and that the role should be limited, “but to no less than two people”. Give that role to two people from your company.
  • Cloud accounts are opened with a company email address. In Amazon Web Services, the email address and password used to create an account sign in to an identity with “complete access to all AWS services and resources in the account”. That address should belong to your company.
  • If you have an iPhone app, enrol in Apple's developer program as your company. Whoever enrols becomes the Account Holder, the person who, in Apple's words, needs to “accept legal agreements on behalf of your organization” and “approve banking changes in your account”.
  • The domain name, company email, analytics and payment provider accounts follow the same rule.

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.

What are the red flags when hiring a development team?

  • You get a fixed price for the whole product after one call, before anyone asks what could wait until later.
  • The firm wants to hold the code or any of your accounts in its own name.
  • There is no client you can call, only screenshots and logos.
  • A paid trial is refused, but a large deposit is expected before you have seen anything work.
  • A month goes by with nothing you can click, and progress arrives as percentages.
  • Every feature and deadline is accepted without a single question about what matters most.
  • The product would run on the firm's own platform under a licence, and nobody explains what happens if you leave.

Where does amBrain fit?

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.

Common questions

  • Do I need a technical co-founder instead of a development team? It depends on your investors and on what you sell. Y Combinator's FAQ answers a founder who is not technical this way: “It's important for the founding team to have the skills to build their product themselves, rather than outsourcing it to someone else. For most businesses, that usually means you need a technical co-founder.” If you plan to raise from investors who see it that way, start looking for that person now, even if an outside team builds the first version.
  • Should I pay a fixed price or a monthly fee? A fixed price fits a small first version that you can describe completely on paper. If the plan will change as you learn from users, a monthly team with weekly demos gives you more control. In both cases, write down what “done” means for each piece before the work starts.
  • Can I switch teams later? Yes, if the code and the accounts are already yours and the product can be built from written instructions. Test it before you need it: ask an engineer from outside the team to set the product up on a clean machine using only the documentation.

Have a design like this on the table?

Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.