Why the process matters more than the technology
Buyers often ask which programming language or framework a builder uses. It's rarely the question that decides the outcome. Projects fail because the builder misunderstood the business, the scope drifted, the data was a mess, or nobody used the result. Every one of those is a process problem.
A good process makes misunderstandings visible early, when they're cheap to fix. A bad one hides them until the end, when they're expensive. That's the whole difference.
So when you evaluate a builder, ask them to walk you through their process with a real example, and listen for the moments where you'd see working software and where you'd be asked to decide. If those moments are months apart, the risk sits with you.
Step 1: Show the real work
The project should start with how your company actually works, not with a list of features. That means sharing the real material on a call: the spreadsheets, the chat groups, the forms, the exports, the paper job sheets. Ideally the people who use them every day are there to explain.
The builder's job at this stage is to map every hand-off: who creates what, who needs it next, where it waits, where it gets copied, where it gets lost. This is what we call reverse-engineering the company.
What you bring: access to the material, and one or two people who know the operation. What to watch for: a builder who sends a long questionnaire instead of looking at the real thing.
Step 2: Fixed scope and price
From the map, the builder proposes a scope. It should be written in business terms you can check: which roles use the system, which hand-offs it handles, which integrations it includes, which data gets migrated, what the support period covers.
Then a fixed price, with a clear definition of what counts as a change and how changes are priced. If the scope is too large for one fixed price, split it into phases, each with its own price and go-live date.
Warning sign: an estimate in hours with a wide range and no firm commitment. That moves the risk of the builder's misunderstandings onto you.
Step 3: A first working version
This is where good projects diverge from the rest. Instead of weeks of design documents, you should see something working on your own data very early. With us, that's within 24 hours of kickoff: small, but real, running on a sample of your data, and clickable by your team.
Its purpose isn't to impress you. It's to test the understanding. People react to working software in ways they never react to diagrams. 'That's not how we do it' in week one costs nothing. In month three it costs a lot.
Step 4: Build in short loops
From the first version, the system grows in short cycles. Each cycle adds a piece, the people who'll use it click through it, and their feedback shapes the next cycle.
- Keep the loops short: days, not months, between something new and someone using it.
- Get feedback from the actual users, not only from the manager who commissioned the project.
- Prioritise the hand-offs where work is lost today, not the features that are nice to demo.
- Keep a 'later' list for good ideas outside the current scope, so they don't quietly expand it.
- Decide quickly. A question left unanswered for a week costs a week.
Step 5: Data migration
Your existing data needs to move into the new structure: clients, contacts, jobs, prices, stock, staff, history. This is the step most often underestimated.
A sound migration starts early with a sample, not late with everything. The builder maps each old source to the new structure, imports a sample and shows your people the result. They spot problems quickly: duplicates, outdated prices, a code used for two different things. After cleanup, the full import runs and is checked again. Our article on Excel to database migration covers this in detail.
What you bring: someone who knows the data and has the authority to decide what's correct.
Step 6: Testing with real people
Before go-live, the people who'll use the system every day should run real scenarios in it: a new enquiry, a job from start to invoice, a schedule change at 7 am, a client complaint. Not a checklist of buttons, but the actual situations they deal with.
This is also when permissions get tested properly. Does the field technician see only their jobs? Does the branch manager see only their branch? Does the client portal show only that client's data?
Step 7: Go-live, one team at a time
Switching the whole company on a Monday morning is risky. A safer pattern is to start with one team, branch or site. Their old spreadsheets become read-only so there's one version of the truth. The builder fixes what they report, quickly. Once the first group stops asking questions, the next group follows.
Plan go-live away from your busiest period, and make sure someone from the builder's side is available during the first days.
Step 8: Support and change
Real use exposes what nobody thought of. The first months after launch bring a steady stream of small adjustments, and they should be covered by an included support period rather than a new invoice for each one.
Our plans include three, six or twelve months of support and changes depending on the plan. After that, Maxxing Care at €2,900 per month covers changes, new features and priority fixes. The system should keep evolving with the company; that's much of the point of building rather than buying.
Who does what
Clear roles on both sides prevent most of the friction in a project. This is the split that works.
- Your decision-maker: approves scope, answers questions within a day, and has the final word on priorities.
- Your process experts: the people who do the work today. They explain the real flow, test new parts and flag what's wrong.
- Your data owner: knows the spreadsheets and decides what's correct during migration.
- The builder's lead: owns the plan, the scope and the communication, and is the single person you call.
- The builder's team: designs, builds, migrates, tests and secures the system, and stays on for support.
How long the whole process takes
For a single-company system with a clear scope, the process above typically runs three to four weeks with us (Core, €18,000). With the AI layer, integrations and a client portal, six to eight weeks (Maxxed, €48,000). Groups of companies are rolled out in phases (Empire, from €120k). Our article on how long it takes to build custom software explains what speeds this up and what slows it down.
Start with step 1
If you're considering custom software, you can do step 1 today: gather the spreadsheets, chats and tools that run your company, and note where work gets lost. Then apply and show us. We'll map it, give you a fixed price, and you'll have a first working version on your own data within 24 hours of kickoff.