A Development Process Without the Ceremony

Most development process was designed for teams of forty and gets applied to teams of two. Sprint ceremonies, story points, three-tier estimation and a project manager translating between people who sit next to each other — these solve coordination problems that exist at scale and cost real time when there is nothing to coordinate.

The opposite failure is just as common: no process at all, work that drifts, a client who has not seen anything in three weeks, and a launch that arrives as a surprise to everybody. Process exists to prevent that, and the useful amount is smaller than agencies suggest and larger than nothing.

What follows is the six-step process I actually run, what each step exists to prevent, and where I have seen the lightweight version fail.

What is process actually for?#

Removing the two failure modes that account for most unhappy projects — surprise and drift.

Surprise is a client discovering in week six that the thing being built is not the thing they imagined. Drift is a project that never quite finishes because the definition of done kept moving. Almost every process ritual is aimed at one of those, and any ritual that is not aimed at either is worth questioning.

Once you frame it that way, the amount of process needed becomes a function of how much surprise and drift the arrangement is prone to, rather than a fixed methodology applied uniformly. A two-week fixed-scope piece needs very little. A three-month build with several stakeholders needs more.

The second row does the most work for the least effort. A client who can open a URL and see the current state at any time asks better questions and asks them earlier, which is the cheapest correction mechanism available.

The right amount scales with the stakes#

A one-week audit needs a scope and a report. An eight-week product build needs weekly demos and a change process. Applying the second to the first is overhead; applying the first to the second is how projects go quiet and then go wrong.

How does it start?#

A message, then a call, then a scope — in that order and quickly.

The first contact does not need to be a brief. Most people asking for work do not have a specification and producing one is a task they should not be doing, because the useful questions are ones they would not know to answer. A few lines about the problem is enough to decide whether a call is worth having.

The call is for questions, not a pitch#

Thirty minutes of asking about the problem, the users, what exists today and where the deadline came from. A call that is mostly me talking about how I work has learned nothing and is why so many first conversations produce misaligned quotes.

Then a written scope, before anything else#

Deliverables, exclusions, assumptions, timeline shape and price. Two pages. This is the artefact everything downstream refers back to, and building without it is the single most reliable way to end up in a disagreement neither side can resolve — the whole subject of scoping properly.

A quick no is a service#

If the project is not a fit — wrong technology, wrong timeline, wrong shape — saying so in the first conversation is worth more to them than a polite delay. It is also faster than producing a proposal designed not to win.

What does building look like day to day?#

Small commits, small pull requests, and a deploy on every push.

The mechanical part of the process is deliberately unremarkable. Work happens in small increments, each with a clear commit message, each pushed to a branch that produces a preview deployment. Nothing is hidden on a local machine for a week.

Preview deploys change the relationship#

When every push produces a URL, progress stops being a status update and becomes something the client can look at. That removes the weekly ritual of describing work in words, which is a lossy medium for anything visual, and it catches misunderstandings within a day rather than at a milestone.

Small pull requests are for the client too#

A pull request that changes forty files cannot be meaningfully reviewed by anybody, including a technical client who wanted to follow along. Keeping them small makes the work legible and it makes reverting a mistake trivial instead of surgical.

Commit messages are documentation#

A year later, the reason a decision was made lives in the commit that made it or nowhere. Writing why rather than what takes an extra sentence and it is what makes a codebase explicable to whoever inherits it.

The baseline goes in first, not last#

Staging, CI, error tracking, uptime monitoring, backups, spam protection, email authentication and client-owned accounts are set up at the start of the build rather than before launch. Those eight things are an hour each at the beginning and a crisis each in production.

How does review actually work?#

On a real deploy, with real feedback, on a regular cadence.

The demo is the correction mechanism, and its value comes from being regular rather than from being polished. A weekly look at the actual thing, with an explicit invitation to say what is wrong, surfaces direction problems while they cost a day rather than a fortnight.

Show the unfinished version#

There is a strong temptation to hide work until it is presentable. That defeats the purpose — feedback on something half-built is cheap to act on, and feedback on something finished arrives after the cost has been paid. Showing rough work requires a little trust and it saves a great deal of rework.

Ask specific questions#

"What do you think?" produces politeness. "Is this the order somebody would actually do these steps in?" produces information. Directing attention at the decisions you are unsure about is what turns a demo into a review.

Write down what came out of it#

A short list of what was agreed and what changed, sent afterwards. Verbal agreement in a call evaporates, and two people remembering a conversation differently a month later is a category of dispute that a three-line summary prevents entirely.

Separate feedback from scope changes#

"The button should be blue" is feedback. "It should also handle recurring bookings" is a new project. Handling both in the same conversation without naming the difference is how scope grows without anybody deciding to grow it.

How do you handle changes?#

With a stated process, so change is routine rather than adversarial.

Scope changes are not a problem; unmanaged ones are. A client who learns something in week three and wants to act on it is behaving correctly, and a process that treats that as a violation makes them stop telling you things, which is much worse.

Estimate before agreeing, always#

Every change gets a quick estimate and an explicit yes before work starts. That is often five minutes, and it prevents the accumulation of small unpriced additions that turn a profitable project into an unprofitable one without any single decision causing it.

Offer the trade, not just the cost#

"That is two days — we can add it to the timeline, or drop the export feature to keep the date" gives the client a real decision. Presenting only the extra cost frames you as an obstacle; presenting the trade frames you as a partner managing a constraint.

Keep a visible list of deferred items#

Things agreed as out of scope should go somewhere both parties can see rather than being forgotten or silently reintroduced. It also becomes the natural starting point for a second phase, which is a much easier conversation than starting from nothing.

What happens at launch?#

A rehearsed deploy, a checked list, and somebody available afterwards.

Launch is the step most likely to be treated as an event rather than a process, and it is where avoidable problems concentrate. The deployment itself should be boring because it has been done many times to staging; what needs attention is everything around it.

Deploy to production before launch day#

The first production deployment should not be the launch. Getting the environment, the domain, the certificates and the environment variables working days earlier means launch day is a promotion rather than a first attempt.

Work through a real checklist#

Monitoring live, backups running and tested, error tracking receiving events, email authentication configured, analytics recording, and the forms actually sending. Each is trivial and each is forgotten regularly, which is exactly what a written list is for.

Be available for the first few days#

Real traffic finds things staging never did. A short period of active attention after launch is part of delivering the project rather than a separate support arrangement, and treating it that way avoids an awkward conversation in the first week.

Then hand it over properly#

Repository access, deployment instructions, environment variables, account ownership and a short document covering how to do the routine things. A proper handover is the difference between a client who owns their product and one who is dependent on you by accident.

What about testing?#

On the paths where failure is expensive, and not everywhere.

Comprehensive test coverage on a small project is a cost that rarely repays itself, and no tests at all means every deployment is a gamble. The useful middle is testing the flows whose failure would actually hurt — checkout, signup, the form that generates leads — and leaving the rest to review.

Type checking earns its place first#

A typecheck across the whole codebase catches an entire category of error for a fraction of the cost of unit tests, and it runs in seconds. It is the highest-return check available and it belongs in the pipeline from day one.

Test the thing that breaks twice#

The most reliable signal for what deserves a test is what has already broken. A regression test written after the second occurrence of a bug is worth more than ten speculative ones written in advance.

Manual checks are legitimate when written down#

For a small project, a checklist somebody works through before release is a reasonable substitute for automation, provided it exists as a document rather than as a habit. The failure mode is not manual testing; it is undocumented manual testing that varies by who is doing it.

Where does this process fail?#

Three places, and all three are about people rather than mechanics.

When the client cannot make decisions#

Weekly demos only work if somebody can act on them. A client who defers every question to an absent stakeholder turns the demo into a status meeting, and the drift the process exists to prevent happens anyway. The fix is establishing who decides before starting.

When feedback arrives all at once at the end#

A client who says everything is fine each week and then produces forty comments at the end has not been engaged, and the cost of that lands on both sides. Asking pointed questions during reviews rather than open ones is the main defence, and where it does not work, more frequent smaller checkpoints sometimes do.

When the work is genuinely exploratory#

A fixed scope and a launch date do not fit research — building something nobody has built, integrating with a system nobody understands. Forcing that into a fixed-scope shape produces either a padded estimate or an overrun, and the honest answer is a different engagement model entirely.

Why so few ceremonies?#

Because most of them coordinate between people, and on a small engagement there is nobody to coordinate with.

Standups exist so a team knows what everyone else is doing. Story points exist to make estimates comparable across people. Retrospectives exist to improve a team's working agreements. Each is genuinely valuable at scale and each is a solution to a problem that does not arise when the delivery team is one or two people talking daily.

Keep the ones that still apply#

Written scope, visible progress, regular review and a change process are the parts that survive at any size, because they address the client relationship rather than internal coordination. Those four are the process; everything else is optional.

Add ceremony when the team grows#

The moment there are three or four people building, coordination becomes a real problem and some of the machinery starts paying for itself. Adding it then, in response to an actual difficulty, works far better than adopting it in advance because it is standard.

What does it cost?#

Perhaps a tenth of the project, and it is not optional overhead.

Scoping, weekly demos, writing summaries, running a change process and doing a proper handover is roughly ten percent of the time on a typical build. That is real and it is far less than the cost of one significant misunderstanding discovered late, which is what all of it exists to prevent.

The honest counterweight: a light process depends heavily on the individuals involved being communicative and decisive, and it does not degrade gracefully when they are not. A larger agency's heavier machinery exists partly to produce acceptable outcomes with a rotating cast and an absent client, which is a genuine advantage in some situations. If your organisation cannot give a project a decision-maker who will look at it weekly, more structure will serve you better than less — and that is worth knowing about yourself before choosing who to work with.

Process exists to prevent surprise and drift. Any ritual not aimed at one of those was designed for a coordination problem you do not have.

Conclusion#

Six steps: a message, a call, a written scope, building with visible progress, regular review on a real deploy, and a launch with a proper handover. Each exists to prevent either surprise — the client discovering the wrong thing is being built — or drift, where the definition of done keeps moving.

Do not ask for a brief; ask questions. Thirty minutes about the problem, the users, what exists today and where the deadline came from produces a better scope than any document a client writes unprompted. Then put deliverables, exclusions, assumptions, timeline and price on two pages before anything gets built.

Make progress visible continuously rather than reporting it. A preview deploy on every push turns status into something the client can open, and it catches misunderstanding within a day. Keep pull requests small so the work stays legible and mistakes stay revertible, and put the eight-item baseline in at the start rather than before launch.

Demo weekly on the real thing, show the unfinished version, ask specific questions rather than open ones, and write down what was agreed. Separate feedback from scope changes explicitly, estimate every change before agreeing to it, and offer the trade rather than only the cost.

Then launch as a rehearsed promotion rather than a first attempt, work through a written checklist, stay available for a few days, and hand over so the client owns their product. Skip the ceremonies that coordinate between people you do not have — and add them the moment the team grows enough to need them. If that way of working suits you, that is how I run projects.