How We Approach Client Projects: From Brief to Launch

The most expensive mistakes in client work do not happen during development. They happen in the first conversation, when the wrong assumptions are allowed to become the foundation everything else is built on. We learned this the hard way. Now we have a process that is specifically designed to surface those wrong assumptions before a single line of code is written.

Phase 1 — The brief that actually captures the problem

Most clients come with a solution in mind, not a problem statement. "I need an app that does X" is a solution. The problem is what happens to the client's customer when X does not exist. We spend the first meeting getting to the problem, because the solution we build at the end of that process is almost never the same as the solution described at the start — and it is almost always better.

• What does your customer do today to solve this problem? (Reveals the real competition)
• What is the cost of this problem going unsolved for one more month? (Reveals urgency)
• Who is the one person this product absolutely must work for? (Prevents designing for nobody)
• What does success look like in 90 days? Not a year — 90 days. (Anchors scope)
• What has already been tried that did not work? (Saves us from proposing the same thing)

Phase 2 — Scope that has a real edge

We write a scope document that lists what is in, what is explicitly out, and what is undecided. The "undecided" list is the most important part — it names every assumption that has not been resolved yet. Those undecideds are the landmines. We get them on paper early so we can make conscious decisions about each one instead of discovering them mid-build.

Scope without an explicit out-of-scope list is not a scope. It is a wishlist with a deadline attached.

Phase 3 — Design before development, always

We do not start building until there is at least a mid-fidelity design that the client has approved in writing. This sounds obvious. In practice, clients often push to skip it — "just start building, we will figure out the design as we go." We have learned to hold the line here. Reworking a design in Figma takes two hours. Reworking it in code takes two days. The design phase is not overhead. It is compression.

Phase 4 — Development in weekly visible increments

We ship a working build to the client every Friday. Not documentation of what was built — a link they can click and use. This does two things: it keeps the client engaged and informed, and it forces us to integrate and test frequently instead of assembling everything at the end and discovering the seams do not fit.

Phase 5 — The launch buffer we always protect

We build a mandatory two-week buffer before the stated launch date into every project timeline. Not because we expect to need it — because we always do. Something always surfaces in the final two weeks that nobody anticipated. A third-party API that behaves differently in production. A device the client uses that exposes a layout issue. A security review that flags something. The buffer is not pessimism. It is professionalism.

Closing

Process is not bureaucracy. It is the thing that lets a 21-person team with different skills, working asynchronously, produce a coherent product that the client is proud of. Without it, the creative freedom you think you are preserving by skipping the structure just becomes chaos that someone pays for later — usually the client, sometimes you, often both.