Every article about this model eventually gets the same reply: “OK, but where do I actually start?”
This is that answer. Not theory: what we built first at StudioHawk, what flopped, the team structure that made it work, and the parts nobody warns you about. Fair warning up front: the code is the easy bit. Everything around it is the actual work.
The first genuinely useful tool we built wasn’t glamorous. It was a call sentiment analyser: it reads the sentiment across all the calls and emails going to a client and flags whether that client is at risk. Not because our team couldn’t tell, but because humans are biased about exactly this. Nobody wants to believe their own client is unhappy. The machine has no ego in the game, it’s very good at detecting the issues, suggesting fixes, and flagging the account to the team leader or client success before it becomes a churn conversation.
That’s the template for a first tool: a real problem everyone recognises, a measurable output, and a comparison against how humans were doing it. If you run any client business, something in the retention-risk family is a genuinely good first build. Then follow the pain: whatever workflow your delivery team repeats most, and whatever data currently lives in six places that should live in one.
You’ve probably seen the stat: MIT’s 2025 research found 95% of enterprise GenAI pilots deliver no measurable return. Having lived through our own flops, I believe it, and I can tell you what the failures have in common.
They’re built in isolation. Built without the person who’ll actually use them. Built to solve a problem that wasn’t really a problem. Especially early on, a lot of people were building shit for the sake of building shit, and a tool like that has no baseline to beat, so nobody can even say whether it worked.
The fix is embarrassingly simple: only build tools that challenge work humans are already doing. Then you can compare one-to-one, human versus machine, see exactly where each wins, and refine. And build recursively: tools that feed their results back into your data, so each one makes the next one smarter. A one-off tool built on generic AI knows what Claude knows. A recursive tool built on your data lake knows what YOU know, and that’s the entire difference. More on that: the data moat.
Here’s the structure that works for us: an AI enablement team whose whole job is to work WITH departments and build things out together.
Yes, you want engineers on it. But the real project managers are the delivery people, the ones doing the work day in, day out. They know where the time goes and where the edge cases hide. Pair the devs with them, and go further: teach the delivery people enough code to build solutions themselves, because engineering has changed and that’s now a realistic ask.
And learn the distinction that kills most internal tools: building something YOU can use is a completely different skill from building something a TEAM will use. Getting buy-in across a whole team, handling everyone’s edge cases, making it obvious enough that busy people adopt it under deadline pressure: that’s the hard part. The code isn’t the bottleneck anymore. The adoption curve is. Budget your effort accordingly, because this genuinely takes longer than you think, just not for the reasons you’d expect.
Owning your software doesn’t mean owning everything, and pretending otherwise is how you burn a year.
Keep renting infrastructure. Building your own GPU setup makes no sense; cloud wins. (We keep a few Mac minis in the office for specific heavy jobs like intensive crawls, and that’s the extent of it.)
Keep renting your system of record. We’re not replacing HubSpot. The reliability of a mature CRM matters too much, and we pull from it as a central source of truth. Teams of thousands are competing to build the best CRM, why would you enter that race? The line: build what encodes YOUR way of working, rent what’s a solved problem.
The part nobody budgets for: every internal tool is a product, and products need upkeep.
Each tool needs an owner, a support path, QA, and monitoring, the same things you’d expect from any SaaS you pay for, because your team will hold it to that standard whether you planned to or not. A lot of the maintenance itself can be AI-assisted, but there must be central people who own it, and that’s another reason the AI enablement team matters: over time they build the map of who owns what, downtime monitoring, the works.
This isn’t overhead, it’s trust. Your team will only lean their real workflows on tools they’re confident won’t fall over. One flaky week can undo months of adoption.
Start with one tool, one team, one measurable baseline. Five people or more, there’s no excuse not to be underway. The code stopped being the hard part, which means the only real question left is whether you start.