Business websites

Business websites

Most software projects do not fail for technical reasons. They fail because the scope was never written down clearly, because the person deciding and the person using are not the same, and because nobody owns the thing after handover.

I work in a plain way. Before the first line of code, I write down the scope, the assumptions, and what is explicitly out of scope. That document is part of the contract, not a slide deck.

How I start

The first session runs about ninety minutes and costs nothing. It is not a sales call. The goal is to establish three things: what the real problem is, which constraints cannot move, and where the budget actually sits. If I conclude another firm fits better, I will say so.

After that session you get a short document: the proposed scope, an estimate in weeks, the team size needed, and a price range. It does not commit you to anything, and you are welcome to take it to another supplier for comparison.

How I build

I deliver in two-week increments. At the end of each one there is something running that you can open and use, not a progress report. If three increments in you decide the direction is wrong, stopping there is far cheaper than stopping at the end.

The code lives in your repository from day one, not mine. You have full access throughout. This sounds obvious, but not every supplier does it, and it is worth asking every supplier you talk to.

How I hand over

At the end you receive four things: the complete source, architecture and operations documentation, access to every piece of infrastructure and third-party service registered in your name, and a handover session for your own team or your next supplier.

I do not hold source code as leverage, I do not register your domains or cloud accounts under my own identity, and I do not write code that only I can read. A good project is one you can walk away from without losing anything.

Warranty and what comes after

For sixty days after handover, defects inside the agreed scope are fixed at no charge. After that, if you want ongoing help there is a separate maintenance agreement, billed on actual hours with transparent reporting.

I do not sell mandatory retainers. If the system runs fine and you need nothing more, you pay nothing more.

When something goes wrong

Every software project hits trouble at some point. What separates suppliers is not whether trouble happens, but when you hear about it.

I report early and plainly. If a piece is running behind the estimate, you know that week, not at final acceptance. If an early assumption turns out wrong, I say so along with two or three ways forward and what each one costs, so the choice is yours rather than mine.

Every scope change is written down and priced before the work happens. I do not build extra and invoice afterwards, and I do not quietly cut corners to hit a date.

Who I am not for

Worth saying up front so neither side wastes time. I am a poor fit if you want a team that takes instructions and asks nothing, if the budget covers only the first release and nothing for running it afterwards, or if requirements change weekly with nobody on your side able to settle them.

In those cases an hourly team or an off-the-shelf platform will serve you better, and I am happy to point you at one.