Two years ago, building a custom internal app for one team's specific workflow was a six-figure engagement. Today the same app — narrower, more opinionated, better at the job — is a 2-to-4-week build on a platform that did not exist when you signed your current SaaS contract.
That has changed something quietly in how mid-market companies should think about their tooling. The default for a long time was: when a team needs to do X, buy SaaS that does X plus 50 other things, then spend a year configuring it for X.
The default now should be different. When a team needs to do X, build a small AI app that does X — narrowly, opinionated, owned by you — and skip the SaaS contract entirely. Or run them side-by-side and let the SaaS go when its renewal lands.
The cost curve actually crossed
On a real engagement last quarter we built three internal apps for a mid-market services firm. One replaced a $54K/year SaaS tool that the team had been paying for and barely using. One replaced a manual Google Sheet that ran a critical workflow. One did something the team had wanted forever but no vendor sold.
Combined build cost: roughly six weeks of engagement. Combined ongoing cost: the model spend (a few hundred dollars a month) plus a light retainer. The SaaS line that died paid for the whole engagement inside the first year.
This is not an unusual story. It is the new shape of the market. The interesting question is no longer whether to build custom — it is which custom apps to build first and how to scope them so you ship instead of perfecting.
What you build first
The apps that work best as your first builds share a few traits. They are owned by one team, not committee-built. They have a clear primary user (a name, not a role). They replace something concrete — a SaaS line, a Sheet, an inbox-driven process. And they ship at v1 in 2–4 weeks, with the understanding that v2 lands a month later.
Apps that fail share traits too. They get scoped in a planning meeting with everyone in the room. They try to replace a category of tooling instead of a specific workflow. They get built with 30 features at the start, because nobody wanted to defer a stakeholder's request, and the result is something nobody on the team owns.
The discipline is: ship v1 narrow. Get it used. Add what real usage actually demands. Cut the features that nobody touches by the second week.
Building faster than your team adopts
There is a real organizational risk here that is worth naming. If we ship faster than your team can absorb new tools — even good ones — you end up with three half-adopted apps instead of one well-used SaaS. The pacing matters.
The pattern that works is to build ahead of need, not behind it. When a team is actively asking for a tool, they are six weeks past the point where they should have had it. Build the next app for the team while they are still onboarding the last one. By the time they are ready, it is waiting.
This requires a different relationship with build cost than most companies have. Old-mindset: "this app is expensive, so let's make sure we really need it." New-mindset: "this app is cheap, so let's ship it now and find out if we needed it."
The honest hedge — when not to build
Not everything should be custom. Email, calendar, document editing, source control, identity, payroll, accounting: still buy SaaS. The custom apps that win are the ones where the work is genuinely specific to your team and the SaaS landscape is either nonexistent or hilariously over-scoped for what you need.
Operations dashboards. Internal knowledge search. Workflow tools nobody else has. Sales call summarizers tuned to your team's voice. Ticket classifiers that know your taxonomy. Onboarding apps that match your hiring process. That kind of work — narrow, specific, your-shape — is where building faster than you adopt actually pays off.