I have been on more agency engagements than I care to count, on both sides of the table. The patterns of which ones succeed and which ones fail are nearly independent of the technical work. The code is usually fine. What varies is the shape of the engagement around the code — and four particular habits seem to make the difference, every time, across every domain.
These are the four we have built our studio around. None of them are clever. Most of them are slightly uncomfortable.
Habit one: a real demo at the end of every sprint, on a real URL
Not a screenshot. Not a video. Not a localhost walkthrough. A URL the client can open from their phone on the way home and break by clicking the wrong thing.
This is the single most important habit, and the one most agencies subtly avoid. It is uncomfortable. The thing isn't done yet. It's rough at the edges. Half the buttons go nowhere. We don't want to ship it under our name.
Ship it anyway — at the sprint boundary, not before.
We used to do these demos every Friday. We stopped. Weekly demos sound great until you've lived inside one: by Wednesday the team is performance-coding to make Friday's demo look good, not building the right thing. The work bends toward the spectacle. We moved to a strict two-week sprint with the demo at the very end, and quality went up across the board. The demo is the artefact of the sprint, not a separate thing the team has to manufacture on top of the work.
The end-of-sprint demo still does the three things nothing else can. It catches misalignment within two weeks instead of a quarter — clients sometimes don't know what they want until they see it not-quite-right. It builds a habit of finishing, in the original meaning of the word: getting something to the state where a human can interact with it. And it creates an unambiguous record of progress that the client can show their board, their co-founders, their investors. That last one matters more than agencies usually realise.
The discipline also forces the team to think about deployment from week one. Systems that get deployed at every sprint boundary rarely have nightmare cutover days. Systems that get deployed once at the end of the engagement always do.
Habit two: write every architectural decision down
Not in Slack. Slack is for ephemera; architectural decisions are not ephemeral. In a markdown file in the repo, dated, owned by one engineer, structured as a short Architecture Decision Record: what we're deciding, why we considered other options, what we're choosing, what we expect to give up.
The ADR is a one-screen document. We write at least one a week, sometimes three. They live in docs/adr/ next to the code, and the file is reviewed in the same pull request as the implementation. Future-us is grateful approximately 80% of the time, and "I wonder why we made this weird choice" debugging sessions are reduced by half.
The discipline is the value. The artifact is a side effect. If you can't write down why you made a choice, you don't actually understand the choice — you're vibes-coding architecture, and you will pay for it.
Habit three: throwaway-Slack, durable-everything-else
We exchange a great deal of context with clients in Slack. The context is irreplaceable. The Slack threads are not. We treat Slack as throwaway by design.
If a piece of information matters more than a day, it goes somewhere durable. Decisions go in an ADR. Bugs go in the issue tracker. Long-form feedback goes in a pull request comment. Roadmap shifts go in the project plan, with a date and an owner.
This sounds bureaucratic. It saves enormous time. By month three of an engagement, "where did we agree on that?" should never resolve to "I have to scroll through Slack for an hour". It should resolve to "look in the ADR, second paragraph". The lookup cost difference is the difference between an engagement that compounds and one that decays.
Habit four: one accountable engineer per surface
Agency teams have a chronic disease called diffuse ownership. Three engineers all touched the auth system; none of them owns it. When the auth system breaks on Saturday, the on-call person Slacks "who knows the auth code?" and the answer is "we all do a bit, ask Jamie, no wait Jamie is on holiday."
Eliminate this. Every meaningful surface of the system — auth, payments, the search pipeline, the deploy process, the database schema — has exactly one engineer whose name is attached to it. They are not the only contributor. They are the one who answers the on-call ping at 2am and the only one who can approve a structural change.
This isn't about silos. It's about accountability without ambiguity. When Jamie is on holiday and the auth system breaks, the team knows: ping Jamie, no decisions until Monday, escalate to the architect if something has to ship now. That's what accountability under the surface looks like.
It also produces vastly better engineers. Engineers who own surfaces grow faster than engineers who pinball between them. The lifelong learners on every team I've been on are the ones with deep "I own this" responsibility. The ones who never get great are the ones who never owned anything.
What these four have in common
They are all forms of reducing slack — in the engineering sense, the gap between intention and reality. Without them, the gap accrues silently throughout an engagement until it's too large to close. With them, the gap is surfaced weekly and pinched shut.
None of these are about being smarter. They are about being more honest, more often, in writing, with the people paying for the work. That turns out to be the durable competitive advantage of any agency operating in this space.
The good news for clients evaluating agencies: these four habits are easy to ask about. "How often do we get a real demo?" "Where do architectural decisions live?" "Who owns the auth system?" The answers tell you everything you need to know in five minutes.
The good news for agencies considering adopting them: they compound. The first engagement runs harder. The fifth runs itself.