Why I build small tools instead of big platforms

Every few months someone asks if I can build them "a platform." What they usually mean, once you dig into it, is one specific problem: a spreadsheet that's become unmanageable, a quote that takes twenty minutes to calculate by hand, a folder of brand assets nobody can find the right version of.

None of those need a platform. They need a small, well-made tool that does one job and gets out of the way.

Why smaller is usually correct

A platform is a bet that you'll need ten features later. Most of the time you won't — you'll need the one feature you asked for, built properly, shipped this month instead of next quarter.

The small-tool approach has a few practical advantages:

• It ships fast. A single-purpose tool can go from conversation to working demo in days, not sprints.
• It's cheap to be wrong about. If it turns out nobody uses it, you've lost a week, not a budget.
• It's obvious when it's done. "Does it solve the one problem?" is a much easier question to answer than "have we covered the roadmap?"

Where this doesn't apply

Some things genuinely are platforms — a CRM tracking hundreds of leads across a sales team, a client portal handling real payments and permissions. Those need proper architecture, not a weekend script. The skill isn't "always build small," it's telling the difference early, before either side has spent money finding out the hard way.

That's most of what a scoping call is for.