Too Big for Spreadsheets, Too Small for a Suite

Between a spreadsheet that has stopped coping and a suite that swallows the whole business, there is an arrangement most small companies end up with anyway: two or three stable products that each do one thing well, plus one deliberately small piece built across the gap between them.

It is cheaper than a suite and it is not free. It costs ongoing maintenance rather than licence fees, and it fails in four specific ways that are worth knowing before you choose it.

What already exists here

This space is occupied, and it would be misleading to write as though we had found something nobody else had noticed.

There is a growing cluster of products positioned exactly here - ERP-lite tools, pages titled “ERP alternative”, low-code database platforms. There are consultancies selling in this space; one we read describes itself, in these words, as filling the gap “between Excel and ERP”, and sells audits, setup and custom builds at published prices. And there is at least one good vendor page recommending best-of-breed composition across roughly eight functional areas - inventory, accounting, customer records, ecommerce, point of sale - explicitly as a way of avoiding the risk of a large ERP implementation.

So the arrangement is recommended, and it is sold. What we could not find on any page we opened on 24 August 2026 is a description of it as an architecture - something an owner can reason about and compose deliberately, with its own costs and its own ways of going wrong.

The best of the pages we read recommends composing products and then supplies no rule for deciding what to build and what to buy, and treats the joins between products as a step that happens rather than a cost that recurs. The consultancy sells the arrangement as a managed service, which is a legitimate offer and also leaves the reader dependent on the seller rather than able to judge it. The third page treats the choice as spreadsheets, off-the-shelf, or custom, with no hybrid at all.

That gap - sold and recommended, but not described - is what this page is for. It also means the page recommends no products, which is deliberate.

What the composition actually looks like

Three parts, and the proportions matter more than the pieces.

The stable products. Two or three, each doing something standard well and bought off the shelf: accounting, probably; whatever handles your customer records; perhaps something trade-specific. You do not build these and you should not want to. They are commodities, they are maintained by someone else, and the moment you build your own you have acquired a permanent obligation in exchange for nothing.

The built piece. One small system covering the part of your operation that no product fits, because it is specific to how you work. Usually this is the thing you currently do in a spreadsheet that everyone else in your trade does differently. It is the smallest of the three parts, and it is the only part where your business is genuinely unusual.

The joins. The connections that move data between them - an export, an import, a scheduled sync, sometimes just a shared identifier used consistently. These are the least glamorous part and the source of most of the ongoing cost.

The ratio we see most often is roughly four-fifths bought, one-fifth built. When the built share creeps much beyond that, something has usually gone wrong in the analysis rather than in the business.

The rule: keep what is stable, build across the gap

The whole method is one question applied to each part of your operation: is this the same for everyone in your trade, or is it specific to us?

If it is the same for everyone - invoicing, VAT, payroll, basic customer records - buy it. Someone else has already solved it, keeps solving it as regulations change, and will do so more cheaply than you can.

If it is genuinely specific to you - the way you quote, the way jobs move through your particular process, the pricing logic that took years to work out - that is the gap, and it is the only part worth building.

Two cautions on applying it.

First, most people overestimate how unusual they are. The initial answer is often that everything is specific, and it rarely survives a careful walk through the actual work. The test is not whether your way feels distinctive but whether a product exists that already does it - and whether anyone has asked.

Second, the built piece should cover one complete path, not a slice of several. A system that handles quoting end to end is useful on the Monday after launch. One that handles four steps of six across three processes retires nothing, and the spreadsheet survives alongside it.

The four ways this arrangement fails

None of the pages we opened lists these, and they are the honest cost of the approach.

Failure mode	What it costs	Early warning sign
Integration decay	The joins are the maintenance. Products update, interfaces change, and a sync that worked for a year stops quietly. Budget attention, not just money	Someone starts checking a number manually “just in case”
Data drift	The same fact lives in two systems and they disagree. Nobody decided which one wins, so both are trusted until neither is	Two people quote different figures from different screens
Dependency spread	Instead of one vendor you now have three plus your own built piece. Each has its own pricing, terms and end-of-life risk	A price rise on one product forces a decision about the whole arrangement
No single audit trail	Reconstructing what happened to one job means looking in three places, and nothing joins them by default	A dispute or an audit takes days rather than minutes

None of these is fatal, and all four are cheaper than the suite you avoided. But they are real, they arrive later rather than sooner, and a page recommending this arrangement without naming them is selling rather than describing.

The mitigation for the first two is the same and unglamorous: decide, in writing, which system is the source of truth for each fact, and check the joins on a schedule rather than when something looks wrong.

When it stops being enough

There are conditions under which the composition should be abandoned for a suite, and no page we opened states them. Ours:

When the joins outnumber the products. Three systems and two joins is an architecture. Six systems and eleven joins is a maintenance project with a business attached.

When no one can answer a cross-cutting question. If “what did we make on this customer last year” requires three exports and an afternoon, the arrangement has stopped serving the thing you actually need from it.

When a regulator or a buyer requires one trail. Some obligations are simply easier to meet inside one system, and arguing otherwise is expensive.

When the built piece has grown into a product. If what you built now needs its own roadmap, its own support and someone’s continuous attention, you have become a software company by accident. Sometimes that is the right answer. It should be a decision.

What this costs that a licence does not

The honest comparison is not price against price.

A suite costs money on a schedule and someone else’s attention. This arrangement costs less money and your attention - a few hours a quarter checking joins, a decision each time one of the products changes, and a relationship with whoever maintains the built piece.

That is a genuinely better trade for most businesses of this size, and it is a trade rather than a saving. Anyone presenting it as simply cheaper has left out the column that eventually matters.

What this page cannot tell you

Three limitations, one of them deliberate.

It recommends no products. Every source we read resolves to a purchase from its author, and the specific tools that suit you depend on your trade, your accountant and what your team already knows. Naming products here would date within a year and would make this the thing it is arguing against.

It cannot tell you whether your gap is real. People are poor judges of how unusual their own process is, and the rule above is only as good as the honesty of that assessment. If nobody has asked a vendor whether their product can already do it, the analysis has not started.

It is our framing, from what we build most often for businesses of this size. No success rate is claimed and none is measured.

What to do this week

List the parts of your operation on one page. Beside each, write “same as everyone” or “specific to us”, and be sceptical of the second answer.

For everything in the second column, check whether a product already does it - ask the vendor directly, in writing, about the specific thing. Most of that column moves to the first once someone actually asks.

Whatever is left is your gap, and it is almost always smaller than it looked. That is the thing worth building, and nothing else is.

FAQ

Which products should we use? We deliberately do not say. The right ones depend on your trade, what your accountant supports, and what your team already knows - and a page that named them would be out of date within a year. Ask the vendors the specific question in the last section; that filters faster than any recommendation list.

Is this just a worse ERP? It is a different trade rather than a worse version. A suite gives you one vendor, one trail and one bill in exchange for fitting your business to its shape. This gives you fit and lower cost in exchange for maintaining the joins yourself. Neither is universally better; the four failure modes above are what you are accepting.

Who maintains the built piece? Someone must, and deciding who before you build it is the difference between an asset and an orphan. It does not have to be whoever built it - but it does have to be documented well enough that it need not be.

What if we grow into needing a suite anyway? Then the composition will have paid for itself in the meantime, and the built piece will have told you exactly what your requirements are - which is the most expensive thing to work out during a suite implementation. Outgrowing this arrangement is a success, not a mistake.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_34f83ecf6a3e and req_eeb500a287ea, both at zero budget. Three pages opened and read in full. See research/live-result-set.md.
• This space is occupied and the page says so. ERP-lite products, “ERP alternative” pages and consultancies positioned “between Excel and ERP” all exist; one opened vendor uses that phrase verbatim, and one recommends best-of-breed composition across roughly eight functional areas. What we could not find on any page we opened was a description of the arrangement as an architecture with its own failure modes - that distinction, not the existence of the middle tier, is this page’s contribution.
• The composition rule, the four failure modes, the end conditions and the roughly four-fifths bought ratio are Garaxe’s framing, from what we build most often at this size. No client outcome, success rate or case result is claimed.
• No product is recommended anywhere on this page, deliberately. One opened source publishes service prices; they are one firm’s offer in one market and are not reproduced.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what owners search for.