Method
Our software development method: scope, build, run
Most software projects fail at the scoping stage, not during development. That is why we refuse to quote for a project we have not scoped.
Our method has three stages: scope on site with future users before pricing, build a usable first version early and get it tested, then run it with training, monitoring and tested backups. The code, the data and the scoping documents belong to you from day one, with no licence and no exit fee.
Stage 1 · Scope
We write down your business before the first line of code, during a day on site with the people who will use the software, not just those who decide on it. This stage captures the rules, roles, exceptions and real documents, audits your existing data and its quality, and produces a scoping document that stays yours, even without a follow-up. The quote is based on this document, not on a hunch.
- A record of the rules, roles, exceptions and real documents
- An audit of your existing data and its quality
- A scoping document that stays yours, even without a follow-up
- A quote based on this document, not on a hunch
Stage 2 · Build
A usable version arrives early, deliberately incomplete at first. It is by using it that your teams find what no meeting would have revealed. Your users test it and adjust course early, with regular check-ins and permanent access to the current version. Data migration is handled at the start of the project, not the end, and anything not yet built can be reordered at no extra cost.
- Your users test it and adjust course early
- Regular check-ins, permanent access to the current version
- Data migration handled at the start of the project, not the end
- Anything not yet built can be reordered at no extra cost
Stage 3 · Run
Going live is not the end of the project. It requires a reversible switchover, training, monitoring, and backups that are actually tested, not just ticked off a list. Changes then continue at the pace of your business, with the same point of contact.
- User training and operational documentation
- Monitoring of errors and performance
- Backups and restores that are actually tested
- Changes at the pace of your business, same point of contact
What belongs to you
A studio that holds you captive through your own code no longer needs to be good. We would rather be chosen than endured. From day one, you hold the source code in your repository from the first commit, the data on infrastructure you are accountable for, the scoping deliverables (rules, scope, architecture), the operational and takeover documentation, and third-party service accounts in your name.
- The source code, in your repository, from the first commit
- The data, on infrastructure you are accountable for
- The scoping deliverables: rules, scope, architecture
- Operational and takeover documentation
- Third-party service accounts, in your name
What you do not pay for
No licence on software that is already yours, no exit fee and no buying back your own code, no mandatory maintenance to keep using it, and no surcharge for a full export of your data.
- A licence on software that is already yours
- An exit fee or having to buy back your own code
- Mandatory maintenance to keep using it
- A surcharge for a full export of your data
Frequently asked questions
What exactly does this method guarantee?
Thorough scoping sharply reduces the risk of scope creep; it does not eliminate it. If your business changes during the project, the scope changes too, and we tell you with the corresponding figure, rather than absorbing it silently and billing it at the end.
Why do you refuse to quote without scoping?
Because a figure given blind is wrong in both directions, too high or too low. Scoping exists to write down your rules and your scope before we commit you to a price.
What do we keep if the project does not go any further after scoping?
The scoping document is yours to keep: the written business rules, the scope and the architecture belong to you, even if you do not continue with us.
Can we change provider partway through the project?
Yes. The code is in your repository from the first commit and third-party service accounts are in your name: there is no contractual dependency stopping you from taking the project elsewhere.
A project, a question?
Describe what you need in a few lines: you deal directly with the team, in Lille.