How we work
A software project is steered
Most projects do not fail on the technology. They fail because nobody knew where things stood. Here is how we work so that does not happen.
The sequence
Five stages, in this order
Each stage ends in something visible: something you can read, try, or turn down. We do not move to the next one until it is approved.
Deliverable · Written scope
Discovery
We watch the real work and agree on a precise scope.
See the detail
We look at the spreadsheets, notebooks and chat threads that compensate for the current tool, then write down what the software will do, what it will not, and in what order.
Deliverable · Approved design
Design
You walk through the screens and approve the data before any code.
See the detail
Screens, data and architecture are drawn early, while changing your mind is still simple and cheap.
Deliverable · Testable release
Build
The product advances in working blocks your teams can try.
See the detail
The gaps between the plan and real use show up during the build, while they are still easy to correct.
Deliverable · System in service
Go-live
Data, training and a way back are prepared before you switch over.
See the detail
We prepare the data migration, the hosting, the backups, the monitoring, and a safe rollback procedure.
Deliverable · Ongoing support
Operation
The same team monitors, fixes and evolves the software.
See the detail
Security patches, updates and new features stay with people who already know the system.
Our working rules
What you can expect from us
These are not sales promises: they are the rules we hold ourselves to on every project, and that you may hold us to.
Ask your questionsFrequently asked
What companies ask us before starting
01How long does it take?
That depends entirely on scope. We give no timeline before the discovery stage — a number quoted before looking at how you work would simply be made up.
02How is the price set?
On the scope written at the end of discovery. You know what is included before committing to the build.
03What if our needs change along the way?
That is the rule, not the exception. Delivering in blocks exists for exactly this: we reorder what is left to build rather than freezing everything up front.
04Do we have to replace everything at once?
No, and we advise against it. We start with the most expensive pain point, put it into service, then extend.
05What happens to our existing data?
It is migrated at the go-live stage — including out of spreadsheets, which is the most common case by far.
06What happens after delivery?
The operation stage: security patches, updates, monitoring and new features. The software is not abandoned on the day it goes live.
Discovery is where we start
One conversation is enough to know whether the project stands up. It commits you to nothing.