How a project actually runs.
The short version is on the homepage. This is the long one: what happens each week, what we need from you, and what protects you if it goes wrong.
- Step 01
20 minutes
A call, 20 minutes
You describe the problem in whatever shape it’s currently in: the spreadsheet, the WhatsApp group, the process nobody has written down. We ask the questions that change the answer: who touches this, what goes wrong, what happens when two people do it at once.
By the end we’ll tell you whether it’s worth building. Sometimes the honest answer is that a subscription tool you can buy this afternoon does 90% of it, and we’ll name the tool. You’ve lost twenty minutes.
What you get
- A straight answer on whether custom software is the right call
- A rough size, and which band you’re likely in
- A note of what we’d need to see before quoting
What we need from you
Nothing prepared. The messy version of the problem is the useful one.
- Step 02
Three working days
A written scope and a fixed quote
Within three working days you get a document, not a slide deck. Every screen, every user role, every rule the system has to enforce. What’s included, and the part most quotes skip: what is explicitly not.
One price and one date. If you read it and something is missing, we revise it before anyone commits. If you read it and walk away, that’s a fine outcome too, and the document is yours to keep.
What you get
- A scope document you can read without a technical background
- One fixed price and one launch date
- The payment terms in writing: half to start, half on delivery
What we need from you
An hour to read it properly and push back on anything that isn’t how your business actually works.
- Step 03
The bulk of the project
Weekly builds
In the first week you get a URL you can open. It won’t be finished. It will be real, running on real infrastructure, with the first screens working. Every week after that, the same URL, further along.
Once a week you get a short note: what’s new, what’s next, anything that turned out differently to expected. You can reply “that’s not how approvals work here” in week two, when it costs nothing to change, instead of in week nine.
What you get
- A working URL from week one, updated weekly
- A written note each week: done, next, decisions needed
- Direct access to the person writing the code, not a ticket queue
What we need from you
Twenty minutes a week to look at the build and answer questions. This is the part that decides whether the project lands on time.
- Step 04
A week, usually
Launch
Your data is migrated, your team is walked through the system, and the code is transferred to you once the final invoice is paid. Up to then it runs on our servers, which is what makes a working URL in week one possible.
You also get written handover: how it works, how to run it, what a future developer needs to know. It exists because the alternative is a business that depends on one person answering their phone.
What you get
- The system live, and the code transferred on final payment
- Existing data migrated and checked
- A walkthrough for the people who’ll use it daily
- Written handover documentation
What we need from you
A couple of hours with the people who’ll actually use it, and a decision on the go-live date.
- Step 05
30 days, then optional
Thirty days of fixes, then your call
Anything broken in the first 30 days after launch gets fixed at no charge. Broken means it doesn’t do what the scope said it would. That’s a bug, and bugs are ours.
After that, take a monthly plan if you want changes made regularly, or take nothing and come back when you need something. Plenty of clients need neither for months. We’d rather you paid us when there’s work than paid a retainer for silence.
What you get
- Free fixes for 30 days after launch
- A support plan if you want one, month to month, cancel any time
- No obligation if you don’t
What we need from you
Tell us when something looks wrong. Early.
If it goes wrong
The protection is structural, not a promise.
“A developer took the deposit and went quiet” is the most common story we hear. Testimonials don’t answer it. These four things do.
Nothing to pay until you have read the scope
The call and the written scope cost you nothing. You see every screen, every rule, the price and the date before any money changes hands, and you can walk away at that point having spent nothing but an hour of reading.
Half the fee rides on delivery
Half when you agree the scope, half when the system is delivered and running. We are working against a balance we have not been paid, which is the only incentive that reliably survives a hard month.
You would know within a week
A working URL from week one, updated every week after. If we went quiet you would know in days, not at the end of a three month silence with nothing to show.
Scope in writing, changes in writing
The price can only move if you change what you asked for, and then you get the new number before the work starts, not on the final invoice.
What happens when you want something different.
You will. Seeing week three of a real system tends to change what you thought you wanted in week one. That’s the point of showing you.
Small changes inside the agreed shape are just part of the build; we don’t nickel-and-dime them. Anything that adds a screen, a role or an integration gets a written change note with its own price and its own effect on the date, and nothing starts until you say yes.
What never happens: an invoice at the end with hours on it you didn’t know were being spent.
Where projects go wrong.
Almost never the code. They go wrong when nobody on the client side has time to answer questions, or when the person who knows how the process really works was never in the room.
So we ask for one named decision-maker and twenty minutes a week. If your business can’t spare that right now, the honest move is to start in a month rather than start badly.
Start at step one.
Twenty minutes, no obligation, no deck. Worst case, you leave with a clearer idea of what you need, and possibly the name of a cheaper tool that already does it.