Somewhere in most of these conversations, the owner asks the honest question:
Could I build this in house, or should I have you guys build it?
It is the right question, and it is usually asked apologetically, as though it were rude. It is not rude. Anyone who cannot give you a straight answer to it, including a straight answer that sometimes goes against them, is selling rather than advising.
So here is the straight version, with no prices in it, because price is not actually the decision.
The decision is not what you think it is
Owners usually frame this as a cost comparison: what does building it cost, versus buying a product, versus hiring someone.
That framing hides the real variable, which is where the capability lives afterwards. Three years from now, when the model landscape has changed twice and half your workflows have moved, who in your world understands how your systems are wired well enough to change them?
There are only three answers. Your own people. A partner. Or nobody, in which case you are renting a capability and will keep renting it. All three are legitimate. They are just very different businesses to be running.
Path one: build it in house
This is right more often than vendors admit, and it is right in a narrower set of circumstances than enthusiastic owners believe.
Build in house when all of these are true:
- You already employ at least one person who ships software and will still be there in two years. Not someone who is interested in AI. Someone who has shipped and maintained something that other people depend on.
- That person has capacity you are willing to protect. If they are your only technical resource and they are already the bottleneck on the product that makes you money, this will not happen, regardless of intent.
- Your workflows are genuinely unusual. If how you do the work is a real differentiator rather than a habit, the knowledge of encoding it is worth keeping inside.
- You can tolerate a slow start. In-house builds are cheaper in cash and considerably more expensive in elapsed time, because the learning happens on your clock.
The honest failure mode: the project gets built to seventy percent by a talented person who then gets pulled onto something urgent. Nobody else understands it. Six months later it is quietly abandoned, and the real loss is not the money, it is a year and the organisation's appetite for trying again.
If you are going to build in house, the test is not "can we do this." It is "can we protect one person's time for long enough, and does someone else understand it well enough to keep it alive."
Path two: buy a product
There is now a large category of AI products sold ready to use. Some are genuinely good.
Buy when all of these are true:
- Your process is close to the industry default. If your workflow looks like everyone else's in your sector, a product built for that sector will fit, and paying for custom work is waste.
- The value is mostly inside the product's own walls. Tools that do one job well and do not need to reach deep into your systems are excellent buys.
- You have someone who will own adoption. This is the one that gets skipped. A product with no internal owner becomes a subscription nobody cancels.
The honest failure mode: you buy capability and inherit all of the implementation work anyway. The connections into your systems, the permissions, the specification of what good output looks like, the getting-people-to-use-it. Those do not come in the box. If your team cannot do them, a product purchase converts into shelfware with a renewal date.
Also worth knowing: much of this category is metered by usage, and costs scale with success. That is not a trap, but model your bill at the volume you are hoping for, not the volume you have today.
Path three: hire someone
The instinct here is sound. If this is going to matter, own the person.
Hire when all of these are true:
- You have enough work to keep them busy for years, not months. This is more work than most 10 to 50 person companies think, and less than they hope.
- You can actually evaluate the hire. Interviewing for a skill nobody in your building has is genuinely hard, and the market currently rewards confident description over demonstrated delivery.
- You can manage them. A senior technical person with no peer and no manager who understands the work will either leave or quietly build something only they can operate.
The honest failure mode: key person risk, wearing a badge. You have converted a vendor dependency into a single-employee dependency, which is usually worse, because a vendor has a contract and a successor and an employee has a notice period.
Path four, the one that gets missed: have it built, and keep the knowledge
The version we argue for is not "outsource it." It is have it built alongside your people, with the explicit goal that your people can run it afterwards.
In practice that means your team sits in the build. When we do this with partners, we train their engineers as part of the work, on purpose, because a system nobody on your side understands is a liability regardless of how good it is on day one.
What you are actually buying is not software. It is the backbone of how your company works agentically: the identity model, the approved sources, the permission boundaries, the routing, and the connections into the systems you already run on. The individual workflows sitting on top of that are the easy part and will change constantly.
The honest failure mode: you treat it as a delivery rather than a transfer. If nobody on your side ever engages, you have bought a dependency and the knowledge transfer never happens. That is on both parties, and it is worth naming in the contract rather than hoping.
A short test
Ask yourself four questions:
- Is this workflow a differentiator or a commodity? Commodity favours buying. Differentiator favours building or having it built.
- Do I have a technical person I can protect for six months? No means in house is off the table, whatever your ambitions.
- Does it need to reach into three or more of my systems? Yes means products will disappoint you, because integration is exactly what they leave out.
- Who owns it in year three? If you cannot name a person or an arrangement, fix that before you spend anything.
Most companies of this size land in the same place: buy the commodity tools, have the connective infrastructure built with your people involved, and hire only once the work is proven and continuous.
When we say no
For the sake of being concrete: if your processes are undocumented and nobody internally can describe how work actually moves, custom building is premature. You would be paying to encode confusion. Map it first, then decide. That is genuinely why we start with a two-day audit rather than a proposal, and a meaningful share of those audits end in "not yet."
Ending in "not yet" is a good outcome. It is a much cheaper one than the alternative.
If you want that conversation, apply at advisy.com.