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. At some point an ERP project appears that is meant to replace everything — and a year later half the company still runs on Excel.

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 pay for the parts nobody touches. When one area doesn't fit, you adapt your business rather than the software — because the alternative would be a change project.

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

Every module we ship brings four things — otherwise we don't consider it done:

• Permissions. Who may see and do what is part of the module, not bolted on afterwards.
• Documentation. Written for the people doing the work, not as an API reference.
• Migrations. The module can move into an existing database without damaging it.
• An interface that works on a phone. Not "responsive somehow", but usable one-handed, standing up, wearing gloves.

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. When the warehouse follows later, it joins: same login, same master data, same interface.

And if a module doesn't do what you need, that's a question for us — not a reason to bend your process.