How I work: four phases, and who actually does them

Because a quotation given before looking at the systems is a bet, and bets are paid for either way: in change requests or in quality cut to stay inside the number. The analysis is a piece of work in its own right, with defined deliverables — a map of the flows, the manual work in hours, an architecture document — that stay yours even if you then build nothing with me, and that any other supplier can work from. It is also the phase in which I can tell you the project is not worth doing, and that happens.

Analysis, architecture and code review I do myself and do not delegate. For development, when the volume calls for it, I rely on a small network of people I have worked with for years — and I tell you that at quotation stage, not once the project has started. Every line that reaches production passes through my review, theirs included, with no exceptions when we are in a hurry. The person you deal with is still me: there is no account manager in between, and one will not appear after signing.

Three things. One person with the authority to decide on scope, because without somebody who can say no the project grows until it eats the budget. Access to the people who touch the data every day, who are the ones who know how it really works. And the time it takes to get access and credentials from the vendors of your systems, which is the variable that moves the dates most: it is rarely the code that makes a delivery slip.

With things you can try, not with percentages. At every milestone there is a flow or a function in an environment you can reach, and you try it on your own data with the people who will use it. The cost of this approach is that it needs your time during the project and not only at final acceptance. The advantage is that a misunderstanding surfaces at milestone two, when correcting it is cheap.

They change at the next milestone, not mid-flight. Changing direction halfway through a milestone means throwing away work already done and destabilising every estimate after it, so the request is recorded and assessed at the delivery point: either it enters the scope with its impact on time and cost declared, or it goes into the backlog. What I don't do is accept silent changes and then present a slip as a surprise.

The same way, with one difference in the calendar. The analysis phase is the one part of a project that genuinely benefits from being in the room: watching somebody retype an order tells you more than an hour of describing it. So I travel for it, in a block of a few days rather than in scattered visits, and travel costs are agreed in advance rather than appearing on an invoice. If travel is not practical — a site that cannot host visitors, a schedule that doesn't allow it — the analysis can be done remotely with screen sharing and recorded sessions with the people who do the work. It is slower and it finds slightly less, and I say so rather than pretending the two are equivalent.

English, written in English rather than translated from Italian afterwards: the architecture document, the field mappings, the scope, the commit messages and the code comments. It matters more than it sounds, because those documents exist precisely so that somebody who is not me can pick the project up — and a document that has been machine-translated at handover is a document nobody trusts. If you also need an Italian version for a subsidiary or an auditor, that is a separate deliverable and it gets said in the quotation.

The source code, the technical documentation, the architecture document and the credentials to every service and piece of infrastructure, all in your name. No encrypted components, no usage licence that forces you to stay, no service that stops working if you stop working with me. I also hand over the list of known weak points: there are always some, and hiding them does not make them disappear — it only makes you find them at the worst moment.

Gradually, with the previous process still live as a safety net. First the new flow runs alongside it read-only and the results are compared with what already exists; then writing is enabled on one part; then on all of it. The manual process is switched off when the new one has proved itself on your data, not on the day of delivery. It costs a few extra weeks and it has avoided practically every operational stoppage that a switch-style release produces.

Few at a time, and it is a choice: analysis, architecture and code review stay with me, while for development I rely on a small network of trusted people, which is what lets me scale the firepower on a project without multiplying the projects. The calendar is one of the first things we discuss on the call, so you know straight away whether the timing matches yours. The advantage is that when I am working on your project I am actually there, and the person deciding the technical things is the person you talk to.