Bespoke SaaS: the model behind AI Hero

A tool for every process becomes a swiss army knife

A product sold to a thousand teams has to generalize. Every team’s workflow is a little different, so the software grows an option for each one, and configuration screens pile up to cover every case. You buy it because it does a hundred things adequately, then spend the first month deciding which forty to turn off. What you never get is the part that is actually yours: the specific shape of how your team does the work. That part lives on in spreadsheets and workarounds bolted onto the edges of the tool you paid for.

For a long time this was simply the price of software. Custom fit existed, but only enterprises with custom-build budgets could pay for it. Everyone else adapted their process to the schema someone else chose. That trade is what has changed, and the change is worth walking through carefully, because the obvious conclusion (“so just build custom”) is about half right.

Custom is affordable again

What made bespoke software expensive was never the idea. It was the volume of hand-work between the idea and a running system. Agentic AI now does most of that volume work: agents write the code, agents review the code, and a small team can take a well-understood workflow to a working system in weeks. We see this in our own studio, where each prototype in the gallery came out of a short design sprint rather than a quarter of engineering. The build has stopped being the hard part.

So if the build is cheap, the obvious move is to commission one: hire a consultancy, or take the forward-deployed offer where engineers arrive on site and build it out. Both work, and both break in the same place. The consultancy ships once, the scope freezes at the statement of work, and the people who understood the system leave the day it goes live. The forward-deployed model is the same shape with a friendlier face: you were buying headcount, and when the engagement ends, someone still has to run, patch, and upgrade what they built. Usually that someone is you.

Day two never ends

It’s tempting to read that as a maintenance problem, as if the risk were an unpatched server. The real problem is bigger. Software that fits a living organization has to keep changing, because four separate forces keep moving underneath it.

Actual usage. The first month in production teaches you what the design got wrong. The screen you thought was the product sits unused while everyone lives in the view that was added as an afterthought. No spec survives contact with real operators, and the software has to follow what they actually do.

Organizational priorities. The workflow you automated this quarter reports into a different org next quarter. A new customer segment, a new regulation, a reorg—each one changes what the software should do, and none of them was in the statement of work.

Growing scope. Automating one workflow makes the three workflows around it visible. Once the software handles intake, everyone asks why it doesn’t handle triage. The boundary of “what the system does” moves every time the system works.

Your people. Employees get better at AI-native tools. The operator who was cautious around agents in month one is asking for batch actions and higher autonomy thresholds by month six. Software frozen at their month-one skill level starts to feel like a training-wheels version of itself.

A handover can’t absorb any of this. What absorbs it is a product team: people who watch how the software is used, keep a roadmap that follows your priorities, and ship the next change every week. That, more than the build, is the thing worth paying for. It’s also the part every commissioned-build model hands back to you.

What agentic AI is actually for

There’s a second decision hiding inside the first one: what the AI in your software should be. The common move today is to add a chat box to an existing tool and call it a copilot. The chat can answer questions about the work, but the work itself still happens the old way, in the old screens, at the old pace. The better use of agentic AI is to design the software around what agents can now do: take actions, hold a plan, and carry work forward between a person’s decisions, with the person staying in charge of the ones that matter. Our prototype gallery is this argument made concrete—fourteen explorations, each one a real workflow redesigned around agents rather than decorated with one.

The two decisions reinforce each other. Software designed around agents is exactly the kind of software that has to keep evolving, because every one of the four forces above moves faster when agents are doing part of the work. Which brings the argument back to the team.

Bespoke SaaS: built for you, run by us

So the model we’ve landed on keeps the fit of custom and keeps the team. We design the software around how your team already works, with a working first version in your environment within four weeks of signature. We host it in a cloud environment dedicated to you, under enterprise SLAs, and the incidents, patches, and upgrades stay with us. When you want a change, you describe it in a paragraph and it ships on a weekly cadence. And you pay for it the way you pay for software: an annual, predictable subscription.

Here’s how the four ways of buying software compare on the questions that decide the outcome.

Every other column asks you to trade fit against burden. What makes the fourth column possible is the cost collapse above: once agents do the volume work of building and our team stays for the evolving, we can price fitted software like a product instead of a project.

Send a paragraph

This is the argument our prototypes are built to test, and the invitation is the same one on the last slide of the deck: describe the workflow you’d like to elevate, in a paragraph. Not a requirements document, just a paragraph about the work and where it hurts. We come back with a one-page design within a week, and you’ll know quickly whether this model fits the problem you have.