Not a methodology diagram. The practical answer to what happens after you say yes, how you will know whether it is going well, and what you are left holding at the end.
A conversation about the problem rather than the solution. We would rather spend an unpaid hour understanding it than quote against a brief that turns out to describe the wrong thing. Sometimes this ends with a recommendation not to build.
What is included, what is explicitly not, what we need from you and by when, and what happens if the scope changes. Both sides sign it. Nothing starts before that.
Working software you can use, not status reports. You see it early and often, which is what makes it cheap to change direction while changing direction is still cheap.
What moved, what is next, what is blocked and what needs a decision from you. Short, written, and consistent, so you are never wondering where things stand.
Live deployment, then verification against the real environment rather than a developer's machine. Every claim we make about the system being live is one we have actually checked.
Source code, documentation, a working local setup, deployment steps and a walkthrough. The test is whether another engineer could take it on without us, and that is deliberate.
We tell you when not to build. The advice that costs us a project is the advice worth having. If a package would serve you better, or the manual process is not actually costing enough to justify fixing, that is what you will hear.
You talk to the person doing the work. There is no account manager relaying your requirements to someone you never meet. The person designing the system is in the conversation.
Bad news arrives early. If something is going to be late, or an estimate was wrong, you hear it as soon as we know rather than at the deadline. Late surprises are how projects actually fail.
We build so you can leave. Standard technology, documented, tested, owned by you. Lock-in is a business model we would rather not have.
Engagements go wrong for predictable reasons, and most of them are on this list. Saying it up front is more useful than discovering it in week four.
Not a committee. Someone who can answer a question within a day or two, because waiting for decisions is the single most common cause of a project running long.
The staff who use the current process know where it actually breaks. A brief written without them describes the process as management believes it works.
Including the spreadsheets nobody mentions and the workarounds everyone is slightly embarrassed by. We have seen worse, and hiding it only makes the estimate wrong.
Sometimes the right answer is a smaller build, a package, or nothing at all. If that is unwelcome, we are probably not the right supplier.