One app or four? How a machinery dealer should sequence quoting, stock, and service
A dealer rarely needs one big system. It needs the right small one first — usually quoting, because it needs no integration — then the next layer once the first is trusted. A sequencing guide, not a platform pitch.
A machinery dealer weighing software usually frames it as a single decision: one system for the whole business, or a scatter of separate tools. Framed that way, the honest answer is neither. The decision that actually matters is sequence — which one small system you build first, and what has to be true before you build the next. Get the order right and each step is short and low-risk. Get it wrong and you are back to the big-bang project everyone says they want to avoid.
We build these systems for machinery dealers, and the sequencing question comes up on every multi-workflow engagement: quoting, stock ordering, warehouse, service parts — where do you start, and do they have to be one thing. It is worth being precise, because "one platform" and "four tools" are both wrong for the same reason. One platform is too much at once. Four disconnected tools rebuild the original mess. The shape that works sits between them.
Why not one big system
The instinct to buy one system that does everything is understandable — a single place, one login, no seams. The trouble is the track record of large system rollouts. A review of more than sixty major ERP transformations found more than 80% ran over 200% past budget and missed their timelines (Kearney, 2023). That is enterprise-scale evidence and should not be stretched into "all software fails." But it names the risk precisely: the more you try to change at once, the longer it takes to deliver anything, and the more likely the whole thing stalls before the dealer sees a working screen.
Older ERP systems were built long ago, for a different problem, when replacing the core all at once was the only option on offer. That is no longer true. The engineering discipline for changing a running business incrementally has a name — Martin Fowler calls it the strangler fig: you grow the new system around the edges of the old one, moving one capability at a time, so value arrives early and nothing has to be switched off in a single frightening weekend (Fowler, 2024). The same idea runs through composable architecture (MACH Alliance, 2024) and Gartner's pace-layered model, which separates the slow-changing systems of record from the faster-changing pieces on top (Gartner, 2024). None of this is exotic. It is the ordinary way serious software gets built into a business that cannot stop running while you work.
What a micro-app actually is
We use the word micro-app, and it is worth defining it precisely, because loosely used it can sound like a licence to build a pile of little disconnected tools — the thing that becomes next year's mess. A micro-app, done properly, is not defined by being small. It is defined by being governed and removable:
- one bounded workflow with one clear outcome;
- a named business owner and a named technical maintainer;
- governed data sources and role-based access, not a private copy of the data;
- controlled interfaces to the systems of record, not a silo;
- logs, tests, monitoring, and a support path;
- exportable data and a documented way to remove or replace it;
- a success threshold, and a criterion for killing it.
That last pair is the point. A system worth building is a system you could delete in a week without business impact — because if it cannot be removed cleanly, it has hidden coupling that will cost you later. Deletability is not a weakness in the sell; it is the forcing function for clean architecture and real client ownership. The micro-apps share one catalog — the shared price and product data from the data work this cluster describes — so they are layers over one substrate, not four islands.
Start where there is no integration
Given that, the first app almost picks itself: quoting. Not because quoting is the most important workflow, but because it is the one that needs the least to get started. Quoting sits at the front of the sales path. It does not need to integrate with accounting or the sales ledger, it does not need existing customers imported — offers go to new prospects — and it does not depend on any other system being ready first. It is the clean place to build the shared catalog properly, ship a small app, and let the firm see a working screen in weeks rather than quarters.
And then something happens that no architecture diagram captures. The team quotes faster, the owner sees the sales floor actually using the thing, and confidence rises across the company. The next layer — stock ordering against the warehouse — is now easier, because the backbone it needs, the structured catalog of models and configurations, already exists and is already trusted. You are not starting over; you are adding a layer over a foundation that is paid for. That is the snowball: each app is faster to ship than the last, because each one reuses the data and the goodwill the previous one built.
| Choice | Time to first working screen | Integration needed up front | Risk if it stalls | Best when |
|---|---|---|---|---|
| One big ERP/suite rollout | Quarters to years | Everything, at once | The whole program; nothing ships | A full transformation is genuinely the goal and funded |
| Four disconnected tools | Fast, individually | None — and that's the problem | The original mess, rebuilt | Almost never |
| Sequenced micro-apps over one catalog | Weeks, starting with quoting | Only what each layer needs | One small app, contained | A dealer wants value early and a path that compounds |
The order, and the judgment
The sequence we run is the same on most dealer engagements. Start with the one workflow that hurts and needs no integration — usually quoting. Build the shared catalog once, correctly. Ship it small, let it prove itself, and use the confidence to fund the next layer — stock, then service — each reusing the catalog. On the multi-module platform we are building for a Polish distributor now, quoting is the first production target and integrates with the existing ERP through the internal IT lead; the warehouse module is second; the service module is deliberately deferred behind a question about the quality of the input data it would need. The order is not dogma. It follows dependency and pain, and it is a judgment made with the dealer, not a template applied to them.
So the answer to "one app or four" is: one at a time, over one shared catalog, in the order that delivers value soonest and compounds. In dealer quoting the intelligence belongs in the data behind the offer, not in writing it — and the system that ships is a simple app the team uses, extended one deliberate layer at a time. The first two weeks of that is a discovery sprint that produces a working prototype on your own data, which is where the sequence should start. The rest is operations, not theatre.