Skip to content

All articles

Finish the stalled build

Restart without a second greenfield. Name the stall, triage before git, lock one slice, finish a path someone can open.

22Atlas

Product studio

4 min read

A stalled build is almost never a code problem first. It is a missing owner, a missing date, or a missing definition of done.
A stalled build is almost never a code problem first. It is a missing owner, a missing date, or a missing definition of done.
Grainy illustration of an operator and a cobalt studio agent writing a restart brief while a stalled repo sits on the desk and a blank greenfield canvas is pushed aside.

The repo is still there. The Slack channel is quiet. Nobody can say what “done” meant six months ago.

Most “restart” conversations begin with a tour of the codebase. That is the wrong first meeting. The code is usually salvageable. What died was the contract around it: who decides, what ships next, and which proof counts as finished.

This playbook is how we run Custom Software when the work already exists and the momentum does not. It also applies when AI or mobile sits on top of that core. The shape is the same. You do not buy a second greenfield to feel clean. You finish a path someone can open.

Name what actually stalled

Write one sentence you would defend in a room that has not read the tickets.

  • Who was supposed to use this, by name of role, not “users.”
  • What job they finish when it works.
  • What date someone once named, even if it slipped.
  • What proof would have counted as shipped (openable build, one operator path, one API consumers already call).

If you cannot fill those four, you do not have a restart brief. You have nostalgia about a repo. Stop coding until the sentence exists. Discovery that only inventories modules is how stalls get a second year.

Diagram of a four-line stall diagnosis: role, job, date, and proof of shipped.
Write one sentence you would defend: who (by role), what job, what date, and what proof counted as shipped. If you cannot fill those four, you do not have a restart brief.

Triage before you touch git

Open the last honest artifacts, not the pitch deck.

  1. Last working path. What could a stranger finish on a real environment the last time anyone tried? If the answer is “nothing outside the pod,” you are restarting from a demo. Treat it that way.
  2. Owner gap. Who can say no to scope today? If that person left, or “the committee,” freeze new features until a single named owner sits on the date.
  3. Dependency rot. Secrets only one laptop holds. A vendor account nobody renews. A staging database that diverged from prod. List the blockers that are not code. Half of stalled restarts die on keys and environments.
  4. Fake progress. Open PRs with no reviewer. Specs newer than the binary. A redesign that never replaced the screens operators still use. Cut those from the restart scope on purpose.

You are looking for the thinnest true path, not a forensic novel. An afternoon of triage beats a month of polite archaeology.

Lock a restart slice, not a resurrection

A stalled product wants to be the whole company again. Refuse that. Restart on one job, one audience, one date someone will defend.

Write the lock as an outcome, not a backlog. Example shape: “By DATE, ROLE can complete JOB on ENVIRONMENT without a builder hovering.” That sentence is the filter. Features that do not serve it wait. Refactors that do not unblock it wait. A second platform waits unless the audience only lives there.

If the calendar cannot carry the dream, shrink the dream. Shipping a thin path on a real date beats promising the original roadmap with a new logo on the README.

Pair the slice with Services only where the work actually sits: Custom Software for the core path, AI Development when the verb needs a model inside that path, Mobile App Development when the proof is a device, Staff Augmentation when your team already owns the lock and needs hands on that slice. Do not staff an orchestra for a sentence you have not written.

Diagram of a restart-slice lock: one date, role, job, and environment, with non-serving work waiting outside.
Restart on one job, one audience, one date someone will defend. Write the lock as an outcome: by date, role can complete job on environment without a builder hovering. Everything else waits.

Keep what works; quarantine what lies

Stalled builds collect parallel truths: the “new” app, the old admin, the spreadsheet that actually runs Friday.

  • Keep the system of record that operators already trust.
  • Quarantine dead UIs and half-migrated services behind clear kill dates or delete them.
  • Prefer a thin adapter over a rewrite when the data is fine and the interface is not.
  • If two paths write the same row, pick one writer before you add a third.

Greenfield feels cleaner. It also recreates the stall with newer dependencies. Rescue the path that already holds the records unless those records are wrong.

Ownership and keys on day one of the restart

Repos, CI, cloud accounts, signing keys, vendor seats, crash reporting, analytics. Those belong to the operator, not the studio’s memory. If a prior vendor still sits in the middle, write the exit in the restart brief. A finished slice you cannot rebuild is another stall with better lighting.

Same rule for decision rights. One owner for scope. One channel for change requests. One definition of done that matches the locked sentence. How we filter that on studio work lives under How we work.

Order of work

  1. Write the four-line stall diagnosis (role, job, date, proof).
  2. Triage last working path, owner, keys, and fake progress.
  3. Lock the restart slice and refuse everything else for v-next.
  4. Put a build on environments that are not only the builders’ machines.
  5. Harden the unhappy path for that one job. Ship. Watch the first week of real use.
  6. Only then reopen the backlog that waited.

Buy that as a dated slice, not a standing retainer of “fix the old project.” Bring the repo, the last date that mattered, and the person who can say no. Start your build if you want that path openable again, hello@mail.22atlas.com.

Get our Articles and posts by email.

Up to one email a day with new Articles and posts from 22atlas.com and sean-weldon.com, plus occasional news about 22Atlas services.