Own the IP. Own the roadmap. Both are the right instinct. The trouble starts when the plan to get there is one enthusiastic person, a Copilot licence and a push straight to main.
We've lost count of how many times we've heard a version of the same sentence this year. “We've just hired an AI guy who says he can build this.” Sometimes it's a new hire. Sometimes it's an existing developer who got enthusiastic. Either way the strategy behind it is sound - replace outsourced delivery and per-seat SaaS with products the business owns outright.
We're not going to argue with that. It's the same argument we make to clients. What we'd push back on is the assumption underneath it, which is that building the thing and running the thing are the same job. They aren't, and the gap between them is where the cost lands, usually six to nine months later when the enthusiastic person is on annual leave and something breaks.
Below are the questions we ask when we walk into this situation, the answers we usually get, and what a good answer sounds like. If you're somewhere in the middle of this, use it as a checklist rather than a warning.
The eight questions
1. What product experience is behind this?
The answer we hear is “he did a course on Claude.” Courses are genuinely useful and the tooling has never been more approachable. But a course teaches you to build the feature. It doesn't teach you what a product owes its users on day 400, which is uptime, a support route, a change log, and someone who understands why a decision was made eighteen months ago.
A good answer names shipped products, not tools. Ask what they've taken into production before, who used it, and what broke. If the honest answer is “nothing yet, but they're sharp”, that's workable. Pair them with someone who has, and be explicit that's what you're doing.
2. Who is accountable at 7am when it's down?
The answer we hear is “me, alongside my day job, and I'm on annual leave next week.” One name and no cover is not an operating model, it's a single point of failure with a calendar.
A good answer has a named owner, a named second, an agreed response time, and a written runbook that a competent engineer who didn't build it could follow. Write the runbook while you build, not after the first incident. Two people who both understand the system is the minimum viable team, however small the product.
3. Has it actually been security tested?
The answer we hear is “yes, we've tested it, it works.” Functional testing tells you the happy path holds. It tells you nothing about what a motivated outsider can do with it, and AI features widen the surface in ways ordinary web apps don't - prompt injection through user content, tool calls that reach further than intended, model outputs rendered without escaping, keys sitting in a client bundle.
- Get an independent penetration test before anything with real data goes live. Budget for it up front.
- Treat model output as untrusted input. Never let it reach a shell, a database or a browser unescaped.
- Scope tool access to the least the feature needs, per user, not per application.
- Put secrets in a managed store and rotate them. A key in an environment file on someone's laptop is a key you can't revoke.
4. What are you measuring quality with?
The answer we hear is “we tried about ten prompts and it got them all right.” Ten prompts is a demo. It proves the feature can work, not that it does work, and it gives you no way to answer the only question that matters after launch, which is whether today's change made things better or worse.
Build an eval suite. It doesn't need to be elaborate to be transformative. Start with fifty real examples from the people who'll use the thing, write down what an acceptable answer looks like for each, and run them on every change. Add every production failure to the set as a regression case. We've written about this at length in evals, not demos, because it's the single practice that separates a product from a prototype.
“Ten prompts that worked is a demo. Fifty examples you rerun on every change is a product.”
5. Where does the data go, and who signed that off?
The answer we hear is “legal don't know about it, but it's fine, we ticked the box that says don't train on our data.” That box is real and it matters. It is also about a tenth of the obligation.
- Know which jurisdiction the inference runs in, and whether your contract actually pins it there.
- Know how long prompts and outputs are retained by the provider, and how long you retain them. Both need a stated period and a deletion job that runs.
- Do a data protection impact assessment before launch if personal data is anywhere near it. Retro-fitting one under audit pressure costs far more.
- Log what went to the model and what came back, redacted where it needs to be. When someone asks what the system told a customer in March, you want an answer.
Bring legal in early and give them something concrete to review. Their objection is almost never to AI. It's to finding out about it after the fact.
6. How does a change get to production?
The answer we hear is “I push to main and refresh the page.” It works right up until the day it doesn't, and the day it doesn't is the day you need to roll back and can't say what changed.
You don't need a heavyweight pipeline. You need version control with reviewed pull requests, a staging environment that looks like production, automated tests and evals running as a gate, one-command deploy and one-command rollback. That's a couple of days of setup for a small product, and it converts model upgrades from a leap of faith into a measured decision.
7. What does it cost to build and to run?
The answer we hear is “it's free, we're already paying for Copilot.” The licence is the cheap part. The real running cost is inference at production volume, hosting, logging and observability, the security work, and the days per month someone spends keeping it alive.
Model the unit economics before you commit. Cost per request, multiplied by realistic monthly volume, plus a fixed platform cost, plus the loaded cost of the people supporting it. Then compare that against the SaaS licence you're replacing. In our experience building still wins often enough to be worth doing, but it wins by a sane margin rather than an infinite one, and knowing the real number is what keeps the project funded when someone senior asks.
8. What happens when that person leaves?
Nobody asks this one and it's the one that bites. If the knowledge lives in one head, you haven't replaced a vendor dependency, you've swapped it for a smaller and less contractual one.
The fix is unglamorous. Architecture decisions written down as you make them. Code reviewed by a second person as a rule, not a favour. Infrastructure defined in the repository rather than clicked into a console. Prompts and eval sets versioned alongside the code. None of it slows a capable team down by much, and all of it is what makes the product an asset on your balance sheet rather than a favour someone is doing you.
The shape that works
None of the above is an argument against going in-house. It's an argument for going in-house deliberately. The pattern we see working looks roughly like this.
- Pick a first product that matters but won't hurt. Real users, real value, contained blast radius if it's wrong. An internal tool before a customer-facing one.
- Build the guardrails alongside it, not after. Evals, observability, access control and the deploy pipeline go in with the first feature. Bolted on later, they cost three times as much and land half as well.
- Put an experienced pair of hands next to your team. Not to take the work off them - to make sure the first product sets the standard the next five follow.
- Give it a real budget line. Inference, tooling, security testing and support time, named and funded. Products that live inside someone's slack time die inside someone's slack time.
- Review it in ninety days against the questions above. Honestly, in writing, with the gaps listed.
Where we come in
We're doing exactly this with several clients right now. We help shape the internal AI function, build the first product alongside the team so the guardrails get learned by using them rather than reading about them, and then step back to a lighter cadence - code review, eval debugging, model upgrade reviews, the architecture calls when something new lands. Your team stays autonomous and owns the roadmap. They just don't learn guardrails, evals, security and deployment the expensive way.
There's more detail on how that engagement runs in going in-house with AI, without going it alone.
And if you've read this far because a version of that sentence was said in one of your meetings recently, we'd genuinely like to talk. Half an hour, no deck. We'll tell you which of the eight you've already got covered and which two are worth doing next, whether or not you ever work with us.
