Start With Good: Where Quality Actually Begins

In my Lister’s Law post, I talked about what happens when teams start with chaos and try to “fix it later.”

Later never comes. The cost always shows up somewhere.

The follow-up question, the one that actually matters, is: where does Good start?

Shift Left Quality taught me the answer.

Good Does Not Begin With Testing

Good begins with understanding.

• Understanding the problem.
• Understanding the user.
• Understanding why the work matters in the first place.

When teams rush past requirements or skip the conversations that create clarity, they are not moving faster. They are moving blind.

What Starting With Good Actually Looks Like

Starting with Good means slowing down just long enough to build the right foundation:

• Clear requirements
• Shared understanding of the “why”
• Well-defined acceptance criteria
• Alignment with business and user goals
• Early conversations about quality and risk

Once those pieces are in place, the team moves faster with less friction:

• Fewer surprises
• Less rework
• Better decisions
• Higher quality
• Real momentum

This is the heart of Shift Left Quality.

Quality is not something you add at the end. Quality is something you build at the beginning.

The Paradox

Starting with Good is not slow.

Starting with Good is what allows a team to go fast without breaking trust, breaking systems, or breaking morale.

The teams that “move fast and break things” eventually spend all their time cleaning up what they broke. The teams that start with Good move slightly slower for the first two weeks, and then leave the fast-and-loose teams behind by month three. This pattern shows up clearly in the DORA research on high-performing engineering teams: investment in quality practices correlates with faster delivery, not slower.

How I Actually Do This

Shift Left Quality is easy to nod at and hard to practice. Here’s what it looks like inside a Wind Walker Studio engagement: the concrete sequence that happens before I write a line of production code.

Understanding first, everything else second.

Before I commit to a scope or a number, I want to understand three things:

• What business problem is the software actually solving? (Not the software problem, the business problem behind it.)
• Who the actual user is, and what a good outcome looks like for them
• Where the constraints come from (regulatory, financial, operational, technical) and which are hard vs. soft

Half of what I learn in these conversations changes what I would have proposed on day zero. The other half confirms it, but with reasoning instead of assumption.

The spec becomes the contract.

I write a spec. Not a proposal. A spec. It describes exactly what will be built, how it behaves in the edge cases, and what “done” means. If the client signs the spec, we’ve reached alignment before anyone starts typing.

Architecture Decision Records (ADRs) go in the same repo. Every non-obvious choice (why this database, why this framework, why this deployment target) gets written down at the time it’s made, with the reasoning that led to it. Six months from now, when a change comes up, we can see why the original decision was made and whether the change respects it.

Quality gates before build.

Before any production code is written, I define:

• What “quality” means for this specific project (test coverage isn’t a universal metric; it depends on the domain)
• What automated checks have to pass before code merges
• What manual review happens before any change reaches the client’s environment
• What the launch checklist actually is (not “we’ll figure it out closer to launch”)

Then build.

Once the understanding is real, the spec is written, the ADRs are committed, and the quality gates are running, building becomes fast. Not “move fast and break things” fast. Predictable fast. Every code change lands in a system that already knows what it’s supposed to be.

Independent review before launch.

Lister Potter, III (my son and a working software QA professional) runs independent review on every project before it ships. Not because I don’t trust my own work. Because Good means two sets of eyes, and the second set can’t be the same set that built the thing.

---

That whole sequence looks slower than a competitor who starts typing on day one. In week 1 of an engagement, a race-to-the-bottom shop has already shipped a template site. I’m still asking questions.

By month three, they’re patching what they shipped. I’m rolling out the next feature on a foundation that doesn’t need patching.

That’s what Shift Left Quality actually costs, and what it actually pays.

Where This Fits

Good is the foundation. Understanding is where it starts.

If you’re building anything that has to coordinate real-time behavior on top of that foundation (payments, inventory, appointments, customer state) the next thing to design for is time itself. That’s the argument in The Three Clocks Framework: every real-time system runs on user time, system time, and business time, and Good means designing for all three.

---

How has clarity at the start of a project improved outcomes for your team?