The audit before we build: what we look at in a day or two
Before we write a line of code, we spend a day or two inside your company. What we look at during that audit, and what you walk away with either way.
By Jérôme Knops
Published October 27, 2026 · 4 min read
Before we propose anything, we spend a day or two inside your company. Not to write a specification document: to watch how work actually gets done, role by role. Here is what we look at during those two days, and what you get out of it, even if you never move forward with us.
Why an audit, not a specification document
A classic specification document gets written far from the field, in meetings, before anyone has watched the teams actually work. It takes weeks to draft, as long to get approved, and it is already outdated the day development starts: a site changing pace, a new hire, a new regulatory requirement, and whole pages stop matching reality.
You're starting from zero.
No. We start from what you already do, with the tools you already have: your tracking spreadsheet, your quotes, your WhatsApp threads with the crews, your current software if you have one. The audit exists to look at that material up close, not to imagine it from a desk.
What we look at during those one or two days
We spend that time with you and with the people who do the work every day, not only with management. Four things interest us first.
| What we look at | What it tells us |
|---|---|
| Who does what, in what order | The real workflow, not the official chart |
| Where information actually lives today | Spreadsheet, paper, messaging, software: what will need to come together |
| The moments where it breaks | Peak activity, an absence, the mistake that costs money |
| Who will use the application, and from where | At a desk, on site, from a phone |
A site supervisor filling in a report standing on site in the evening does not have the same needs as an assistant preparing quotes sitting at a desk. An audit that only visits one of the two misses half the picture.
What you walk away with
At the end of the one or two days, you receive three things, whether you move forward with us or not.
- A prioritized list of screens. What has to exist in the first version, and what can wait.
- A rough order of price and timeline. Not a final number, but a serious range for the first version.
- What should stay manual. An honest audit also says what an application will not fix, and why.
These three things are yours to keep. If you decide not to continue with us, or not right away, they still serve you: to discuss with another provider, or to prioritize your own internal projects.
What happens after the audit
If you move forward, the next step is a first version running in a few weeks, built from the screen list the audit produced, not from a theoretical document. It is also what avoids the derailments we see when a project starts with months of specification before the first line of code. More detail on this method is on our offer page.
You keep a say at every step: screens get built with the people who will use them, not in a blind spot between two deliveries.
What an audit does not do
An audit is not a free, no-strings-attached diagnostic: it takes time from your teams, and we bill for it in most cases. It does not replace a demonstration either: at this stage, we have not built anything yet, only observed. And it does not guarantee we are the right answer to your problem: it happens, after an audit, that we tell you so ourselves.
The audit before we build: the key takeaways
A day or two inside your company beats a specification document written far from the field: it shows what teams actually do, not what a chart claims they do. You walk away with a list of screens, a rough order of price and timeline, and a clear idea of what will stay manual.
Whether you continue with us or not, that work is yours to keep. It is the only honest way to start a project whose every detail nobody, at the first meeting, knows yet.
Founder and CTO of Edenio
Jérôme Knops is the founder of Edenio, where he designs and builds custom business applications for construction, supply chain and distribution companies. He runs the scoping meetings, writes the code, and stays the person you talk to once the tool is in production.
See all their articles
Jérôme Knops
