Value in the first week. A working platform in three.
Long IT projects fail because the feedback arrives too late to matter. Work is delivered in blocks with acceptance criteria attached, and you can stop at any block boundary holding something that keeps working.
Six blocks. Each one ends in something you keep
Every phase is a stop point, not a milestone on the way to one. Click a phase to see exactly what walking away at that boundary would leave you holding.
Foundations
Days 1–7Your web address, company email, one secure sign-in for everyone, managed devices, a tidy shared drive and backup that has been tested by restoring it.
Digital footprint
Days 1–7A credible website, enquiry capture that can't be lost, local search foundations and verifiable credentials.
Core platform
Days 8–21The system of record: clients, jobs, costs, approvals, compliance and field capture, live and in daily use.
Money & scheduling
Days 8–21Quoting and margin control, rate libraries, scheduling with calendar sync, timesheets feeding job costing.
Portals & AI
~4 weeksClient-facing portals with scoped access, automated reminders, and AI assistance applied where it repays the effort.
Scale
OngoingCost tuning as you grow, deeper integrations, security review, and the platform keeping pace with the business.
Your build gets a full-time engineer.
Not a slice of one, shared across a book of accounts. No account manager, no junior handed your project, no ticket queue between you and the code — you brief the person who writes it. That is the only reason a working product in three weeks is a commitment rather than a hope.
Two ways to engage. Both with the meter visible
Bespoke work carries bespoke pricing, but not vague pricing. Build work is quoted stage by stage against a written scope. Everything after it runs on an hourly rate — which is a control you hold, not a tap left running.
Quoted stage by stage
Each stage is scoped, priced and accepted before the next one is quoted. You are never committing to twelve weeks of work on the strength of a first conversation.
- A fixed price per stage — written scope, written acceptance criteria, agreed before work starts.
- Payment on acceptance — you pay for a stage once it does what the scope said it would do.
- A stop point at every boundary — pause or walk at the end of any stage, keeping everything delivered so far.
- Longer engagements priced accordingly — a larger scope is more secure work, and the rate reflects that.
Hourly consultation
Once the platform is live, change is constant and unpredictable. An hourly rate is the honest instrument for it — you authorise the work, you see the hours, and you turn the tap off whenever you want.
- Changes and refinements — reshaping the code as your workflow shifts, which it will once people are actually using it.
- Training and handover — sessions for new staff, or for a process nobody had thought about at build time.
- Third-party vendors — dealing with your other suppliers and their support desks, in their language, so your team doesn't have to.
- Ad-hoc advice — the "should we buy this or build it?" conversation, before the money is spent rather than after.
Third-party running costs — Microsoft licensing, cloud hosting, the domain — are set up on your own accounts and billed to you directly at cost. They are set out line by line before anything starts, and no margin is taken on them.
Nobody can promise bug-free software. This is what can be promised instead.
Every non-trivial system carries defects, and any developer who tells you otherwise is either inexperienced or selling. The nature of the beast is that problems surface once real people put real work through the software, in combinations nobody anticipated. What matters is not the pretence that bugs won't happen — it's what occurs in the hour after one does. You get direct access to the person who wrote the code, on call, with issues triaged by how much damage they are actually doing.
The two questions everyone asks here
There's no catch, but there is a shape. Week one delivers foundations and web presence — genuinely useful on its own. The following two weeks deliver a working core platform, not a finished product. It then grows for as long as it's worth growing. The reason the dates hold is that your build has an engineer on it full time rather than in the gaps, and each block carries written acceptance criteria rather than a vague sense of "done".
It will, at some point — all software does, and the honest position is to say so rather than promise perfection and quietly hope. Defects surface when real people put real work through a system in combinations nobody predicted at build time. What is promised is availability: direct access to the person who wrote the code, with issues triaged by severity. Something that has stopped your work is dealt with immediately, whatever the hour. Something cosmetic is logged and cleared with the next batch of work. You always know which category yours is in and what is happening about it.
The next stage is a conversation, not a commitment.
Describe the workflow that hurts. You'll get an honest read on what a first stage would contain, what it would cost, and where the stop points sit — in writing, before anything starts.