BBMM Technologies
← All articles
6 min readprocess, product-development, small-teams, engineering-culture

A Disciplined Product Development Process for a Two-Person Studio

By Mykhailo Boichuk · Co-founder & Vice-President

In short

A two-person studio cannot rely on the process machinery that larger teams use, but it does not need to. Discipline at small scale comes from ruthlessly limiting work in progress, writing down decisions so shared understanding does not depend on memory, and finishing one thing before starting the next. The constraint of being small becomes an advantage when focus replaces coordination overhead.

Small teams need different process

Most published software process is designed for teams large enough that coordination is the central problem. A two-person studio has almost no coordination cost and almost no slack. Copying the ceremonies of a large team adds overhead without solving a problem the small team actually has.

The right question is not how to scale down a big process but what discipline a small team genuinely needs. The answer is narrower than it first appears: a few habits, applied consistently, do most of the work that elaborate process does for larger groups.

Limit work in progress

The most valuable discipline for a tiny team is limiting how much is underway at once. With two people, starting several things in parallel means everything advances slowly and nothing reaches a finished state. Finishing one thing before starting the next keeps quality high and makes progress visible.

  • Keep the number of active efforts very small, ideally one significant thing per person.
  • Finish and ship before opening new work.
  • Treat a long list of half-done features as a warning sign, not a sign of productivity.

Write decisions down

When a team is two people, it is tempting to keep everything in conversation and memory. That works until it does not. Decisions get forgotten, the reasons behind them are lost, and the same questions get reargued. Writing down decisions, briefly, is cheap insurance against this.

A short written record of what was decided and why does not need to be formal. A few sentences captured at the time prevents the slow erosion of shared understanding that otherwise affects even the smallest team.

Protect focus and quality

The advantage of being small is the ability to focus deeply without coordination overhead, and the discipline is to protect that advantage. This means saying no to scope that does not serve the core of the product, and refusing to let unfinished, low-quality work accumulate as debt.

At BBMM the process is intentionally light: agree on what to build and why, build one thing at a time to a finished standard, write down the decisions that matter, and ship. The discipline is not in the volume of process but in the consistency of these habits. A small team that finishes what it starts and remembers why it made its choices can produce work that larger, busier teams struggle to match.

Key takeaways

  • A two-person studio needs discipline, not the process machinery built for large teams.
  • Limiting work in progress keeps quality high and progress visible.
  • Finish and ship one thing before starting the next.
  • Writing decisions down briefly prevents the loss of shared understanding.
  • Protecting focus and refusing low-quality work is the small team’s main advantage.

Frequently asked questions

Does a two-person team need a formal development process?
No. It needs a few disciplined habits rather than the coordination-heavy process built for large teams, because coordination is not its main constraint.
What is the most important discipline for a small studio?
Limiting work in progress. With only two people, finishing one thing before starting the next keeps quality high and makes progress visible.
Why write decisions down in such a small team?
Because relying on memory leads to forgotten decisions and reargued questions. A brief written record preserves shared understanding cheaply.

About the author

Mykhailo Boichuk

Co-founder & Vice-President

Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.