Skip to main content
Skip to content
Comparison

Build an AI team, or bring one in

Hire the engineers, or engage a firm that hands the work back. What each one costs you in time, risk and what you are left holding.

CH.01 · Side by side

The question is usually framed as cost, and cost is the part that misleads. Hiring builds a capability you keep and pays for it before it produces anything: a senior ML engineer in Lisbon is months of searching, then months of ramp. Engaging a firm buys delivery now and risks leaving you with a system nobody inside can change. The useful question is which risk you can afford this year, and what you insist on owning at the end.

What mattersHire and buildEngage a firm
Time to the first working thingMonths: search, notice periods, then ramp on your systemsWeeks, because the method and the standards are already standing
What you hold afterwardsThe people, and everything they knowDepends entirely on the agreement. Ask before you sign.
If it goes wrongYou carry the hire, the salary and the re-hireThe engagement ends at its stage boundary
BreadthWhat your hires happen to have done beforeWhatever the firm has shipped, across clients and sectors
The second projectCheaper: the team is already there and already knows your systemsRoughly the same as the first, unless you kept the capability
Hardest partHiring senior AI people against everyone else hiring themMaking sure the handover is real and not a slide deck

When hiring is right

  • AI is going into the product you sell, not only the way you work.
  • You have enough work to keep a team busy past the first project.
  • You can wait two to three quarters for the first thing that works.
  • You already have engineers who can interview AI engineers properly.
  • The domain is unusual enough that the learning curve is the real asset.

When bringing a firm in is right

  • You need to know whether this is worth doing before you commit headcount.
  • The first project is well defined and the second one is not yet.
  • You want the capability transferred rather than the dependency extended.
  • Your constraints are regulatory, and you need people who have shipped inside them before.
  • You have engineers already, and what is missing is the AI-specific judgement.
CH.03 · Our honest take
We are one of the firms, so read this knowing that. The pattern we see work is neither pure: bring people in for the first build, insist the agreement says the code, the models and the documentation are yours, and have your own engineers in the build from day one so the handover is a formality rather than an event. If a firm will not put ownership and training in writing, that is the answer to the question. We do it the other way round: we build it, you own it, and the engagement ends.

Two weeks of AI Discovery ends with a ranked list of what is worth doing and what each one needs, including whether it needs us at all. Or take the readiness check first. Take the readiness check

CH.05 · Questions

What buyers ask before they choose.

Over one project, a firm. Over three years of steady work, your own team. Cost is the part of this question that misleads: hiring pays for a capability before it produces anything, and engaging pays for delivery now, with the risk of being left holding a system nobody inside can change.

Months, not weeks, and then months more before that person is productive on your systems. Search, notice periods and ramp-up are the real timeline, and you are hiring against everyone else trying to hire the same people.

That the code, the models and the documentation are yours, and that handover includes training your team to run them. If a firm will not put ownership and training in writing, you have your answer about what you would be left holding.

That is the pattern we see work. Bring people in for the first build, put your own engineers inside it from day one, and require the agreement to transfer the capability. Handover becomes a formality instead of an event.

Then you are closer than you think, and what is usually missing is the AI-specific judgement rather than the engineering. That is a smaller gap: a senior engineer your team can ask, or training on your own codebase, rather than a full build.

Start

Bring us the problem nobody has cracked yet.

We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.