Seven steps, and one loop.

You tell us what you need built and roughly when you need it. It takes about five minutes, costs nothing, and commits you to nothing. We reply with whether it is something we can take on.

The first step is deliberately small. You are not signing anything, not paying anything, and not committing to a scope you have not thought through yet. You describe the problem in your own words and we tell you honestly whether it is work we can do well. If it is not, we say so rather than taking it on and learning on your budget.

We work out exactly what the thing has to do before anyone writes a line of code. Every feature, every edge case, and the fixed price are agreed in writing, so nobody discovers a surprise halfway through.

This is the step most projects skip and most projects regret skipping. We go through what each screen does, what happens when something goes wrong, who is allowed to do what, and what the thing is not going to do in this round. All of it gets written down and agreed before any code exists, because a change of mind here costs a conversation, while the same change of mind after the build costs real money.

We build it. You get a working link you can open at any point, so you watch it come together rather than waiting months for a reveal that misses the mark.

You get a link on the first day there is anything to see, and it keeps updating as we work. That is not a courtesy, it is a safeguard: if we have misunderstood something, you find out in week one rather than at handover. Watching it take shape is also the easiest way to notice the thing you forgot to ask for while it is still cheap to add.

We try to break it ourselves first. Every screen and every form, on phones and desktops, slow connections included. You should never be the person who finds the obvious fault.

Before it reaches you, we go through it trying to make it fail. Every form gets the wrong input on purpose. Every screen gets checked on a phone as well as a desktop. Slow connections, empty states, someone clicking the button twice. None of this is glamorous and all of it is the difference between software that demos well and software that survives contact with real use.

You put it in front of real work and real people. Anything confusing, missing, or wrong comes back to us as a plain list, not a formal ticketing process.

Now it meets reality. You and the people who will actually use it put it through real tasks, not a scripted demo. What comes back to us is a plain list in whatever form suits you, because making a client learn a ticketing system to report a typo is a way of receiving less feedback, not better feedback.

The decision point. If anything is not right we go straight back to requirement gathering and run the loop again, at no extra cost. Only once you are genuinely happy does it move forward.

This is the only step with two exits, and it is yours to choose. If anything is still not right, we go back to requirement gathering and run the loop again at no extra cost against the agreed scope. There is no cap on how many times that can happen. Nothing goes live on the strength of you being tired of asking.

It goes live. The code and the accounts are yours, documented, with nothing locked to us. The same people who built it stay on to keep it running.

It goes live and it becomes yours. The code, the hosting, the domain and the accounts are all in your name, documented well enough that another developer could pick it up. We stay on to maintain it because that is the work we want, not because you are locked in and have no other option.