You don't need a platform. You need the thing that works on Tuesday.

Retool's 2026 AI Build vs. Buy report makes a point we've been seeing in our own pipeline: AI-assisted development has dropped the cost of custom software far enough that teams are now ripping out SaaS tools that don't fit. That's good news. But it comes with a new failure mode, and it's the one we spend the most time talking clients out of.

They want a platform. They should want a thing.

The platform trap

When building software was expensive, you had to amortize that cost across every possible future use case. So you scoped wide. You built a "platform" — something configurable, extensible, ready for the workflows you might have in three years.

That's the same instinct that bloated the SaaS tools people are now trying to escape. Every feature you didn't need, every config screen you ignored, every onboarding flow built for a company ten times your size. Somebody scoped that for a future that wasn't yours.

Marty Cagan's recent piece on build vs. buy draws the line clearly: build where the work is differentiated, buy where it isn't. We'd add a corollary. When you do build, build for the actual job. Not the abstracted version of the job. Not the platform version. The job.

Build for the business you have

The best custom software we've shipped has a depressingly narrow brief. One contractor needed a tool that took a job photo, pulled the customer record, and generated a change order PDF. That's it. No "field service platform." No modules. One workflow, used 40 times a day, that used to take 15 minutes and now takes 90 seconds.

If that contractor's business changes in two years, we'll change the software. AI-assisted development is what makes that affordable. The whole point of the new economics is that you don't have to predict the future anymore. You can build for now and rebuild when now is different.

What we actually scope

When a client asks for a system, we try to find the smallest unit of work that's painful. CIO's reporting on AI workflow tools in the enterprise lines up with what we see: the wins come from automating specific, high-frequency steps, not from sweeping process redesigns.

So we ask:

- What does someone on your team do every day that they hate? - Where does the same data get retyped? - Which handoff between two tools is breaking most often?

Those are buildable. They're testable. They're cheap to get wrong and cheaper to fix.

The implication

If you're scoping a custom build right now, resist the urge to make it a platform. Make it the thing that works on Tuesday. Ship it. Use it. Let the next version be informed by what you learned, not by what you guessed.

The new build economics reward small, sharp, replaceable software. The platform mindset is a holdover from when software was expensive. It isn't anymore.