The Varstatt Principles

The principles that separate work that ships from work that drifts

Most software projects fail the same way. Unclear scope turns six weeks into six months. A $15K budget becomes $50K. Developers build the wrong thing beautifully, on time, exactly as specified.

After building software since 2011, five areas separate work that ships from work that drifts: Discovery, Delivery, Diligence, Partnership, and Philosophy.

Discovery

Not everything that could be built should be. Discovery answers the question nobody wants to slow down for: what's actually worth building?

The developer finds the core feature — the one thing without which nothing else matters. Appetite-based boundaries replace estimates. Estimates are guesses dressed up as commitments. Appetite is honest: this is how much the client is willing to spend on this problem.

Technology choices follow context, not trends. Business constraints trump technical purity every time. The developer shapes scope to fit the appetite — and says no when a project isn't the right fit.

Delivery

Delivery is continuous flow, not sprint theater. One WIP limit: one thing in progress at a time. "Done" means deployed to production, not merged, not reviewed, not demoed.

The developer refactors as they go. Leave the code better than it was found. Feature flags keep the main branch production-ready so there's no release anxiety, no freeze periods, no coordination overhead.

Regular async updates replace meetings. No meetings unless a strategic decision genuinely requires one. Most decisions don't. Quality comes from safe-to-fail design, not from preventing every bug. And a default stack means compounding expertise, not starting from scratch each time.

Diligence

Software evolves or dies. There's no finish line, no handoff moment where development ends and maintenance begins. Diligence rejects that split entirely.

Monitoring starts on day one. The developer observes actual behavior, analyzes real patterns, and improves based on what's happening — not what anyone assumed would happen during the build.

The client can pause when work slows and resume when it picks up. No lock-in, no retainer theater. When production breaks, the developer responds immediately — patch, fix, update. Documentation happens automatically through transparent process, not as a separate deliverable.

Partnership

None of this works without the right relationship model. The relationship starts with a week zero — a mutual audition before real money changes hands. The price is public, the model self-selects.

The client sees everything — the task board, the repository, the messy commits. Full transparency, not curated updates.

Weekly billing creates accountability without lock-in. Four natural exit points every month. Easy cancellation forces quality. There's no scope creep because there's no fixed scope — just a priority queue the client and developer work through together.

Philosophy

Software development is a business cost. Like paper in the office. Not special, not art. That means it should be predictable, low-friction, and cost-effective.

Hours are the wrong metric. Platform consolidation beats integration complexity. The solo developer model — one person, full stack, AI-augmented — is a competitive advantage, not a limitation. The client owns everything: the repo, the services, the infrastructure. Zero lock-in by design. The client decides when something is done — not the developer.

Read online

All 33 principles are available right here — scroll down to the table of contents and start reading.

Jump to contents

Get the PDF

Subscribe to get the full handbook as a PDF. You'll also receive new posts when they're published.

Table of contents: