Platform vs Custom: How to Know Which One You Actually Need

Two business owners. Both built something. Both are scared to touch it.

Different technology. Same paralysis.

The Zapier Jenga Tower

It started with one zap. Probably something sensible: a form submission triggers an email, a purchase delivers a file. Clean, five minutes to set up, works immediately. So you add another. And another. Six months later your entire product delivery workflow runs through a stack of connected platforms that nobody, including you, fully understands end to end.

It works. That’s the thing. It works every day and you’ve stopped thinking about it, which is exactly the problem.

Because you also know, somewhere in the back of your mind, that you dare not touch it. Not because it’s broken. Because it’s load-bearing duct tape. One misconfigured zap, one platform that quietly changes an API, one trigger that fires in the wrong order, and the whole thing comes down like a jenga tower. Silently, probably. You’ll find out when a customer asks where their thing is.

This is what happens when you solve a custom problem with platform tools.

What this business actually needed was a small, boring, well-built custom app. Probably four to six weeks of work. Something owned, understood, and documented. Instead they have a distributed system spread across four platforms with the operational logic living in the gaps between them, and the person who set it up has long since moved on.

The Accidental Product Company

This one usually starts with a genuine business requirement that doesn’t fit anything off the shelf. They needed a CRM. And a booking engine. And because they operate across currencies, some foreign exchange monitoring. And payments. And it all needed to talk to the website.

Someone looked at that list and said: we’ll build it. A developer, an agency, maybe an AI at midnight. And they did. A custom application built on Rails, Node.js, or whatever JavaScript framework was cool that week. Covering all of it, integrated, running, doing the job.

Two years later the app that was meant to serve the business is now the actual business. They’ve accidentally become a product company with a customer base of one. The app needs maintenance. Dependencies need updating. The booking logic has edge cases that took months to discover. The FX monitoring breaks when an exchange rate API changes something upstream. Every quarter there’s something.

They wanted control. They got it. It turns out owning a bespoke software product is a significant ongoing commitment that nobody budgeted for, because nobody really said it out loud at the start.

What this business actually needed was the right off-the-shelf tool for each job: a CRM, a booking platform, an FX data service, a payments layer. Each one maintained by a vendor whose entire job is to keep that specific thing working. And then, yes, a small custom middleware layer to make them all talk to each other. Something focused, documented, and scoped to the integration problem only. Not a product. A bridge.

The Question Worth Asking First

Neither of these businesses made an obviously bad decision in the moment. Both were responding to real constraints with what seemed like reasonable solutions. The problem isn’t that they chose wrong. It’s that they didn’t ask the right question before they chose.

The question isn’t which platform is better. It’s: which parts of this problem already have a good enough solution, and which parts are genuinely novel?

Most business problems are mostly solved by existing tools. A CRM does CRM things. A booking platform handles bookings. A payments layer processes payments. The part that’s genuinely novel is usually the bit in between: the specific way your business needs those things to connect and behave together. That’s the part worth building custom. Just that part.

If you try to solve the whole thing with platforms, you get the jenga tower. If you try to build the whole thing custom, you accidentally become a product company. The answer is usually a combination: good off-the-shelf tools for the solved problems, a small focused custom layer for the part that’s actually yours.

The custom piece should be small enough to understand, documented well enough to hand over, and scoped tightly enough that the person maintaining it isn’t also maintaining everything else. If it’s grown beyond that, something went wrong somewhere upstream.

We wrote recently about people who built something with AI and are now terrified it’ll break. The Zapier story gets there a different way. Different tools, same outcome: infrastructure you’re scared to touch, running a business you care about.

The wrong decision doesn’t announce itself on launch day. It announces itself the day you realise you’re afraid to change anything.

If you’re not sure which category you’re in, or you suspect you already know and have been avoiding it, we do a one-hour call. You tell us what the business does, we ask some questions, and by the end you know what you actually have and what needs fixing versus what can wait. No proposal, no commitment. Just clarity on something you’ve probably been avoiding.

Most people leave feeling better than when they started.

Book a call here