Approach
Building internal tools: five stages from process to system
What stands at the end is neither a CRM nor an ERP nor an app, but a company where a value appears once and then travels through the processes that actually exist.
Automating an unresolved process does not improve it, it makes it go wrong faster. That is why one step sits between mapping and development that most people skip: simplify and standardise. This page describes the five stages and how they are paid for.
The step almost everyone skips
A company describes what its people do today. It receives software that reproduces exactly that — including the double entry, the detours and the steps that exist only because somebody introduced them years ago. The result is an expensive, faster replica of the old state.
So a step of its own belongs between mapping and development: simplify and standardise the process. Only what is left after that gets built.
How far that carries shows in a project for a window installation company. The usual workflow was: measure, carry the figures to the office, have sales calculate, call back, get the customer to come in and sign. The task was not to speed that chain up but to delete two of its links outright — the calculation in the office and the customer's second visit. Only then was it clear what the software actually had to do: calculate and take a signature where the measuring happens.
That order is also why we sometimes advise against building. If, after simplification, off-the-shelf software fits the process, we say so and name it.
Five stages
Every stage ends in something written and is quoted separately. There is no point at which you carry on without a price and without a scope.
- 01
Record the process
The real path of the work, not the org chart: who decides, where information comes from, where it is lost, what is entered twice. That is the process review, and it ends in a written document.
- 02
Simplify and standardise
Duplicated work and redundant steps drop out; different variants of the same process come onto one model. In a project covering three plants this was the heaviest part of the work — and the precondition for one platform being able to serve all three.
- 03
Fix the scope in writing
What is included, what is not, what it costs and how long it takes — in writing, before anything is built. The first stage is several modules closing the most expensive bottleneck, not the whole system at once.
- 04
Build in stages
Each stage is quoted and paid for separately. You see the current state regularly and check it against real workflows from your own operation, not against test data.
- 05
Hand over
The source code goes to you. There is no maintenance subscription: later changes are quoted separately, and the price is fixed before work begins.
Frequent questions
- Why not start with development straight away?
- Because software laid over an unresolved process does not repair it. It sets it in concrete — including the steps you would delete during mapping.
- Do we have to order the whole system at once?
- No. The first stage is several modules that close the most expensive bottleneck. Every further stage is quoted and paid for separately.
- What happens if something changes mid-project?
- Changes to the agreed scope are quoted as their own item and confirmed in writing before implementation. The original scope stays visible throughout.
- Do we get the source code?
- Yes, on handover. There is no maintenance subscription; later changes are quoted separately.
- Where do we start?
- With the process review. It costs €350, ends in a written document, and is credited in full against a project that starts within 45 days.
Start with the first stage
The process review is the first stage and the only one that starts with no precondition. What it examines is set out on the process review page.