When you need a custom system, and when a ready-made platform is enough

Many growing companies reach a point where the way they work starts to slow them down. Orders increase, the team grows, and so do the files. Two options appear: subscribe to a ready-made platform, or build a system of your own.

I build custom systems for a living. Even so, I often advise business owners not to build anything until they are sure a ready-made platform can't do the job. Here is how I think through that decision, with a short checklist at the end.

Signs you've outgrown spreadsheets

Excel is a good place to start. It's fast, flexible, and familiar. The trouble starts when the spreadsheet becomes the system. These are the signs I see most often:

• More than one version of the truth. Sales keeps one file, the warehouse keeps another, and the numbers don't match at month end.
• One person holds it together. A single employee understands the formulas and the hidden columns. When they're on leave, the report waits.
• Copy and paste is part of the job. Orders arrive as WhatsApp messages, get typed into the sheet, then typed again into the accounting software.
• Nobody knows who changed what. A number changed, and no one can say when or why.
• A simple report takes days. Management asks for one figure, and the team pulls it together from several files.
• You can't control access. You want each sales rep to see only their own orders, but the file is either open to the whole team or locked.

One or two of these signs don't mean you need a custom system. They mean it's time to move the work into a proper tool. In many cases, the first step is a ready-made platform.

What ready-made platforms do well

These platforms solve problems thousands of companies share. Accounting software knows journal entries, invoices and VAT. An online store platform knows the cart, payment and shipping. A CRM knows sales stages and follow-ups. A booking system knows appointments and reminders.

They are strong where a custom project struggles to compete:

• They keep up with change. When e-invoicing requirements or payment gateways change, the platform vendor handles the update.
• Many users have tested them before you. The common bugs were found and mostly fixed before you arrived.
• You can start quickly. You can be working within days.
• The cost is predictable. A monthly or yearly subscription instead of a development budget.

If your way of working is close to the way the platform was designed, the ready-made platform is the right choice. And if a tool you already use is enough, I'll tell you so plainly, even when that means you don't need me.

Where ready-made platforms stop

A ready-made platform is designed for the common case. Difficulty starts when an important part of your work falls outside it.

Take a typical situation. A distribution company uses good accounting software, an online store, and an app to track its delivery reps. Each of the three works well on its own. But an order from the store has to pass through the warehouse, get assigned to a rep, then become an invoice. None of the tools knows that whole journey, so someone moves the data between them by hand, day after day.

Another case: a field services company prices its contracts by region, contract type and number of visits. Platforms allow limited customization, so pricing lives in a side spreadsheet, and the manual errors come back.

In both cases the tools themselves are fine. What's broken is the gap between them.

The "integrate, don't rebuild" rule

The rule I work by is simple: I don't build what an existing platform already does well. I integrate it, and build only what's missing.

In practice that means:

• Accounting stays in your accounting software. I won't rewrite ledgers and invoicing that your software already handles and updates as regulations change.
• Your store stays on its platform. Cart, payment and shipping are solved problems there.
• I build the layer that connects them. A small system that receives the order from the store through its API, routes it to the warehouse, assigns it to a rep, and sends the invoice to the accounting software.
• And I build what no platform offers. Your own pricing logic, for example, or a dashboard that pulls the numbers from your tools into one screen for management.

A good custom system is usually smaller than people expect, because it only builds the missing piece.

This approach usually costs less than building it all from scratch, carries less risk, and leaves you free to replace one platform later without rebuilding the rest.

Integration has one condition: the platform has to allow it. Some platforms offer a clear, documented API; others offer limited access or very little. So in the first week of a project I check the APIs of the platforms you use myself, and hand you a written report on what can be connected and what can't. That protects both sides from promises that can't be kept.

When a custom system is the right call

In some situations, building is clearly the better path:

• The way you work is what sets you apart from competitors, and squeezing it into a template means giving that up.
• You pay for several platforms, use a small part of each, and run the rest by hand.
• You need permissions or approval steps that the available platforms don't support.
• You have users outside the company, such as customers or suppliers, who need a portal of your own.
• Your data is sensitive, and you want it kept in accounts you own and control.

Even then, the answer is rarely to build it all. More often, one part gets built and the rest stays on platforms.

How I handle this decision in practice

I start with one or more calls to understand how the work runs today. Then I write a spec in Arabic: what will be built, and what stays on your current platforms. When a project is a good fit, I prepare a clickable prototype within days, with a walkthrough video, free of charge, so you can see the idea before committing to anything.

The offer is priced item by item, and you can remove or postpone any item. Delivery comes in releases on a staging environment that you test yourselves. The code repository and all accounts are registered in your company's name from day one. After launch there is a support period, then optional maintenance.

A decision checklist

Answer yes or no:

• Do you have more than one file holding the same numbers, and do they disagree?
• Does important daily work depend on one person who understands the spreadsheet?
• Does someone on your team move data by hand between two or more tools on a daily basis?
• Have you tried a ready-made platform in your field, and found an important part of your work left outside it?
• Is that missing part a way of working that genuinely sets you apart?
• Do the platforms you use offer an API that allows integration?
• Do customers or suppliers need to log in to the system?
• Does management need one screen that brings together numbers from separate tools?

If most of your answers are "no", a ready-made platform, or better organization of what you already have, is probably enough for now. If most are "yes", you likely need your tools connected, and perhaps a small system that covers what's missing.

If it helps, describe how your process runs today and which tools you use, and I'll share my view on what needs building and what doesn't.

Related to this articleConnecting your systems