Bespoke SaaS: the build stopped being the hard part

The build stopped being the hard part

Each of the fourteen prototypes in our gallery came out of a short design sprint, days of work rather than a quarter of engineering. That speed is the fact this essay rests on. What made bespoke software expensive was never the idea; it was the volume of hand-work between the idea and a running system, and agents now do most of that volume work: they write the code, they review the code, and a small team can take a well-understood workflow to a working system in weeks. So the build has stopped being the hard part. What stays hard is that the software has to keep changing after it ships, and the viable model for that is a product team that stays, priced like software rather than like a project.

This piece is for the owner deciding how to get software for a workflow no tool on the market quite covers, and it stays at the level of models and costs; there is no architecture in it. First we walk the four forces that keep a fitted system changing, then the ways of buying software that each solve one half of the problem, then the four-way comparison and the model we’ve landed on.

Four forces keep moving under any fitted system

It’s tempting to read “the software has to keep changing” as a maintenance problem, as if the risk were an unpatched server. The problem is bigger: four separate forces keep moving underneath any system fitted to a living organization, and none of them waits for a contract renewal.

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, and the software has to follow what the operators 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, and the system’s scope grows 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, which is where the next two sections go.

Generic SaaS fits the median team

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, and everyone else adapted their process to the schema someone else chose. That trade is what the cost collapse changed, and it’s worth walking through carefully, because the obvious conclusion (“so just build custom”) is about half right.

Consulting and forward-deployed break at the statement of work

If the build is cheap, the obvious move is to commission one: hire a consultancy, or take the forward-deployed offer where engineers embed on site and build against your data. The forward-deployed model, which Palantir pioneered and the AI labs have since adopted, exists for a good reason. As The Pragmatic Engineer’s write-up of the role describes it, a forward-deployed engineer lives on-site for weeks or months, learns the customer’s domain, and ships production code against the customer’s real data, because for new problems the customer often doesn’t know what they need until they see it working. On the build, both models work.

Both also 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 industry’s own handover guidance tells clients to plan post-launch support into the original scope and to budget 15 to 20 percent of the build cost per year for the maintenance that comes back to them. The forward-deployed engagement ends the same way: you were buying embedded headcount, and when the engineers roll off, someone still has to run, patch, and evolve what they built. Usually that someone is you. And in Palantir’s version of the model, what the engineers learn at your site hardens into the vendor’s platform for the next customer; what stays with you is the system as of roll-off day.

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 the team stays for the evolving, fitted software can be priced like a product instead of a project.

Software designed around agents evolves fastest

One consequence follows once the point holds. The common move today is to add a chat box to an existing tool and call it a copilot; the chat answers questions about the work while the work still happens the old way, in the old screens. Software designed around what agents can now do (take actions, hold a plan, carry work forward between a person’s decisions) is the version worth building, and it is also the version that changes fastest, because each of the four forces above moves faster when agents do part of the work. So the standing team matters more for AI-native software, not less. Our prototype gallery is fourteen explorations of exactly this kind of software.

Send a paragraph

The other consequence is an invitation, the same one on the last slide of the deck: describe the workflow you want rebuilt, 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.