Why we cut software into modules

Most of the companies we talk to have the same story behind them. First a few spreadsheets. Then one tool for time tracking, a second one for orders, a third for the warehouse. Each sensible on its own, together a patchwork nobody can keep in view. At some point the big ERP project appears, meant to replace all of it — and a year later half the company still runs on Excel, because the ERP doesn't fit in exactly the place that matters most.

The problem isn't the software. It's how it's cut.

An ERP is one block. You buy all of it at once, you roll out all of it at once, and you maintain the parts nobody touches. That isn't an accident, it's the shape: an ERP wants to model the whole company, so it has to be a little responsible everywhere — and is therefore never fully yours anywhere.

Where that difference actually bites can be listed:

When one area doesn't fit, you have two options. Either you bend your process until it fits the software. Or you start a change project that runs for months. Both cost — only the first is paid in your people's time, and that never shows up on an invoice.

That's where we start. Usable is a kit: you take the modules your business needs today and snap more on later. A module here isn't a checkbox on a price list, it's a self-contained piece of software with its own data, its own permissions and its own documentation.

What a module ships with

"Module" sounds like kit marketing, so it matters what we mean by it. Every module we ship brings four things — otherwise we don't consider it done, and it doesn't go out:

• Permissions. Who may see and do what is part of the module, not bolted on afterwards. The warehouse hand sees the warehouse, not the payroll. It isn't a setting you can forget.
• Documentation. Written for the people doing the work, not as an API reference. The help sits where the work happens.
• Migrations. The module can move into an existing database without damaging it. Yesterday's data is still there tomorrow — and fits the new module, instead of sitting beside it.
• An interface that works on a phone. Not "responsive somehow", but usable one-handed, standing up, wearing gloves. People working outside don't type it up back at a desk.

What changes for you

You start with whatever hurts. If order handling is the problem, that's where you begin — instead of a rollout project that shows its first benefit twelve months in. One area, solved cleanly, is worth more than ten that half-work.

When the warehouse follows later, it joins: same login, same master data, same interface. Your people don't learn a second program, they get a second area inside the same one. And what you decided about roles and permissions in the first module still holds — you don't start from zero.

As your business grows, the system grows with it, in the order your reality dictates — not the one a rollout plan prescribes.

Where a kit is worse

So this doesn't stay sales prose: there are cases where a block is the better answer.

• When a business already has everything in one system and is happy with it. Then a switch is risk without return. A kit pays off where something is missing or snagging — not for its own sake.
• When the processes are extremely standardised. Some industries have finished systems that model that one workflow perfectly. Building against those makes little sense.
• When nobody wants to make decisions. A kit assumes somebody says where to start. If you'd rather not make that call, buying a block and taking its workflow is the honest choice.

The fair sentence is: a kit moves decisions to you. That is the price of a cut that fits you.

An example of how it actually runs

A business with 30 people, maintenance in plant engineering. The starting point is never "we need a system" but a concrete annoyance — here: two missed inspection deadlines within a year.

1. First step: equipment and inspections. The inventory comes from a spreadsheet; from now on the intervals hang off the device. Effort: an afternoon of importing, a week of follow-up.
2. After six weeks: damage reports join, because it turns out defects are still being reported by message — and therefore never reach the failure rate the next interval is derived from.
3. After a quarter: maintenance and notifications. Only now, because before that nobody could have said who should receive which alert.
4. Later: time tracking, because the same people already book their hours against the same equipment.

Not one of those steps is a project. Each is reversible on its own, and after each one something works.

And when a module doesn't fit?

Then that's a question for us, not a reason to bend your process. A module that snags in one place is a job for us — not a problem you learn to live with.

That's the real difference from the block: with an ERP, you're the one who adapts. With a kit, the cut stays negotiable — until it fits your business, and not the other way around.

If you want to see what that would look like for you: the configurator lets you pick your area and your modules and shows the result straight away. And if you're still wondering whether you're even at that point — the five signs are in When spreadsheets break.