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.

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.

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.