How I Actually Run Projects

The agile vs. waterfall debate is a real conversation for teams with product managers, sprint ceremonies, and backlogs. For a solo developer working with a small business client, it's mostly noise. Here's what the process actually looks like.

Define the Scope Before Anything Else

Every project starts with a written scope: what gets built, what's explicitly not included, and what the deliverables are. This isn't a 40-page requirements document — it's a page or two that both sides agree on before any work starts.

The scope document exists to prevent the most common project failure: scope creep that neither side noticed happening. When someone asks "can we add X?", the scope document gives both sides a reference point for whether X is a small adjustment or a separate project.

Communication Over Ceremonies

Agile methodology calls for daily standups, sprint reviews, retrospectives. That structure makes sense for a 10-person engineering team. For a small business client working with one developer, it's overhead.

What actually works: communicate early when something changes. If a requirement turns out to be harder than expected, say so before it becomes a delay. If the client's vision shifts partway through, catch it before building the wrong thing. The mechanism doesn't matter — email, a short call, a message — what matters is that neither side is surprised.

Ship Working Software, Not Progress Reports

The client wants to see the thing, not hear about the thing. I share working previews early — before everything is polished — so feedback comes while there's still room to change direction. A staging environment that the client can actually click around in is worth more than a status update email.

This is the part of agile thinking that actually applies at small scale: short feedback loops, real deliverables over documentation, adjusting when requirements clarify.

After Launch

For sites with a monthly SEO retainer, the ongoing process is simple: agreed deliverables each month (content, GBP updates, performance review), delivered on a predictable schedule. No sprint planning. No velocity tracking. Just the work that was agreed on, done.

For one-off builds, the relationship continues as needed — fixes, additions, questions. You have direct access to the person who built it.