The Continuous Quality Platform

Building Quality Into the Developer Platform — Instead of Testing It at the End

Over the years, while working with startups and enterprise teams across different organizations, I’ve seen very different approaches to developer experience.

Some teams invested early in strong developer platforms that made local development and testing almost effortless.

Others chose not to invest much in local developer environments—often for a perfectly reasonable reason: “We’re building an MVP. We need to show value to the business now, not spend weeks building internal tooling.”

I’ve seen this trade-off play out across many teams. The problem is that it rarely stays small. What you save in platform investment today, you often pay back in developer waiting time tomorrow.

Developers started deploying to cloud environments just to test a change, often without the confidence that it will behave the same way when it reaches production. So during my conversations with teams the MVP moved fast but everyone crossed their fingers and prayed before deploying it to prod. Not to a surprise but the untested bugs lived in the product for a long time and in some cases it came as an escalation reported by customers.

That’s the developer productivity debt that I have seen quietly building up—and becoming increasingly expensive as the product and engineering team scale.

In my previous project, I explored how an Internal Developer Platform can remove engineering friction.

The principle was simple:

Good platforms don’t enforce the right way. They make the right way the easiest way.

That led to capabilities around self-service environments, production-like test data, API contract validation, standardized workflows, observability, and AI-ready repository context.

But while building this, I kept coming back to another question:

What happens after we make it easy for developers to build and deploy software?

How do we make it equally easy for them to prove that the software works?

That’s where the Continuous Quality Platform comes in.

This isn’t a separate QA platform sitting beside the Internal Developer Platform. It is a quality layer built into the same developer experience.

The goal is to move from:

“Developers build. QA tests. Production/Customers tells us what we missed.”

to:

“Everyone contributes to quality, and the platform continuously helps us validate it.”

The pattern I have seen across multiple teams

A feature is developed/Bug is fixed —> The developer tests what they can locally. —> Then the code moves through CI —> QA starts testing —> Something doesn’t work.

The conversation becomes:

“QA found a bug.”

Or worse, when it reaches production:

“Why didn’t QA catch this?”

But the root cause is often somewhere else.

Maybe:

• The developer couldn’t reproduce the scenario locally.
• The required test data wasn’t available.
• The API contract wasn’t defined.
• The consumer and provider evolved independently.
• Unit tests covered the code but not the behavior.
• Integration tests were missing.
• The local environment behaved differently from production.
• A performance regression wasn’t tested.
• The requirement itself wasn’t precise enough.

The problem isn’t that QA didn’t test hard enough.

The problem is that quality was treated as a phase instead of a property of the entire engineering system.

That’s the problem I wanted to solve.

My Shift in Thinking

Once the IDP provides the paved road for developers, quality should become part of that road.

Instead of:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Developer
    ↓
Write Code
    ↓
CI
    ↓
QA
    ↓
Production
    ↓
Hope

The workflow becomes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Developer
    ↓
Understand the Change
    ↓
Define Expected Behavior
    ↓
Develop Locally
    ↓
Seed Realistic Test Data
    ↓
Validate Locally
    ↓
Unit Tests
    ↓
API Tests
    ↓
Contract Tests
    ↓
Integration Tests
    ↓
Performance / SLA Validation
    ↓
CI Quality Gates
    ↓
Deploy
    ↓
Observe
    ↓
Learn
    ↓
Improve Tests & Platform

The important change is that quality isn’t added at the end.

It is continuously built into the workflow.

1. Start with the Developer, not the QA Environment

One of the first things I wanted to address was a simple question:

Can a developer test their change before opening a PR?

Not just compile the code.

Actually test it.

That means the IDP should make it possible to:

• Start the required services.
• Run dependencies locally or through controlled environments.
• Seed realistic test data.
• Reset test data.
• Exercise APIs.
• Run relevant tests with one command.
• Reproduce important production scenarios.

The developer shouldn’t have to say:

“I need to deploy this to QA to find out if it works.”

The platform should make the feedback loop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Code Change
    ↓
Run Locally
    ↓
Seed Data
    ↓
Test
    ↓
Fix
    ↓
Repeat

The earlier the feedback, the cheaper the fix.

This builds directly on the Environment Gap and Data Gap identified in my IDP project, but now the focus is different:

The goal isn’t just to make development easier.

The goal is to make validation part of development.

2. Move from “Test Coverage” to “Risk Coverage”

A common question is:

“What’s our test coverage?”

But percentage coverage alone doesn’t tell me whether a system is safe.

A service can have high unit test coverage and still fail because its API contract changed.

A report can pass every functional test and still take 30 seconds to load for a customer.

A data pipeline can process every test record correctly and fail when the real production volume arrives.

So I look at quality across multiple layers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

              Specification
                    ↓
                Unit Tests
                    ↓
              Functional Tests
                    ↓
                 API Tests
                    ↓
              Contract Tests
                    ↓
            Integration Tests
                    ↓
                E2E Tests
                    ↓
          Performance / SLA Tests
                    ↓
            Production Signals

Each layer answers a different question.

Unit

Does this piece of logic work?

API

Does this service behave correctly?

Contract

Can my consumers and providers safely evolve independently?

Integration

Do these components work together?

E2E

Does the customer workflow actually work?

Performance

Can we deliver the expected experience at scale?

Production validation

Is the system behaving as expected in reality?

The objective isn’t to run every test everywhere.

It’s to ensure that the risk introduced by a change is validated at the right layer.

3. Make customer SLAs part of Testing

A customer-facing report isn’t “done” because it returns the correct data.

If the report takes 30 seconds to load, the feature may still be failing the customer.

So functional correctness and performance need to be treated together.

For critical APIs, reports, and workflows, the platform should help validate:

• Response time
• Throughput
• Error rate
• Availability
• Resource consumption
• SLA/SLO expectations

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Customer Report

Functional Test        ✓
API Test               ✓
Contract Test          ✓
Integration Test       ✓
Performance Test       ✗
SLA Validation         ✗

Result:

Functionally correct
Operationally unsafe

This changes the definition of “done.”

Working software isn’t enough.

The software must also meet the expectations under which the customer uses it.

4. Follow the Data through the Entire Product

One thing that becomes increasingly important as systems become distributed is understanding the full data journey.

A customer may see a report.

But the report might depend on:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Customer
    ↓
Frontend
    ↓
API
    ↓
ECS Service
    ↓
Queue
    ↓
Data Pipeline
    ↓
Database
    ↓
Transformation
    ↓
Report

A defect could occur anywhere along that path.

So testing only the API isn’t enough.

The Continuous Quality Platform should help engineers understand:

• Where the data originates.
• How it is transformed.
• Which services are involved.
• Which contracts exist.
• Where data can be lost or corrupted.
• What the customer ultimately sees.

This is where the IDP’s service discovery, observability, and data capabilities become important quality primitives.

The platform connects:

Test → Data → Service → Dependency → Production Behavior

Instead of testing individual components in isolation, we can start reasoning about customer outcomes.

5. Turn every Hotfix Into a permanent Test

This is one of the most important principles in the platform.

When a production bug requires a hotfix, the work shouldn’t end when the deployment succeeds.

The next question should be:

Why did our engineering system allow this defect to reach production?

The investigation becomes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Production Bug
      ↓
Root Cause
      ↓
Where Should We Have Caught It?
      ↓
Missing Test / Contract / Specification / Data
      ↓
Add the Missing Safety Net
      ↓
Automate It
      ↓
Prevent Recurrence

For example:

A production API bug might reveal a missing API test.

A breaking integration might reveal a missing contract test.

A data issue might reveal unrealistic test data.

A performance incident might reveal missing SLA validation.

A recurring AI-generated regression might reveal missing repository guidance or an incomplete specification.

The output of the incident isn’t just:

“Bug fixed.”

It becomes:

“The system is now better at preventing this class of bug.”

That is the difference between fixing defects and improving engineering quality.

6. Quality Is Everyone’s Responsibility

This is perhaps the biggest cultural change I owned in my experience where I got an opportunity to drive it.

Developers are responsible for the quality of the code they write.

SDETs and QA engineers are responsible for building effective quality strategies, automation, and feedback mechanisms.

Platform engineers are responsible for making those capabilities easy to consume.

Product teams are responsible for defining expected customer behavior.

Operations teams provide production feedback.

Nobody owns quality alone.

The traditional model often puts QA at the end of the process:

1
2
3

Developer → QA → Production
                 ↑
              Blame QA

The model I always promoted:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

                 Quality
                    │
        ┌───────────┼───────────┐
        │           │           │
    Developer      SDET      Platform
        │           │           │
        └───────────┼───────────┘
                    │
                Production
                    │
                    ▼
                 Feedback
                    │
                    └──────→ Continuous Improvement

When a bug escapes, the question shouldn’t be:

“Who missed it?”

It should be:

“What capability was missing from our engineering system?”

That’s a much healthier and more productive way to build quality.

7. Bring AI Coding Agents into the quality loop

The IDP already provides structured context for AI coding agents through things like:

• AGENTS.md
• Repository conventions
• Architecture decisions
• API contracts
• Deployment rules

The next step is to make quality context equally accessible.

An AI agent shouldn’t just know:

“How do I write this code?”

It should also know:

“How do we prove this code works?”

For a microservice, that might mean giving the agent access to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

Service Specification
        ↓
API Contract
        ↓
Test Data Strategy
        ↓
Unit Test Pattern
        ↓
API Test Pattern
        ↓
Contract Test Pattern
        ↓
Performance Expectations
        ↓
AGENTS.md
        ↓
Hooks / Agent Skills

This creates a much stronger development loop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Human defines intent
        ↓
Specification / Contract
        ↓
AI Agent
        ↓
Implementation
        ↓
Tests
        ↓
Automated Validation
        ↓
Human Review
        ↓
Deploy

The principle is simple:

AI accelerates implementation.

Specifications define intent.

Tests provide evidence.

The platform provides the guardrails.

What you can start implementing “Tomorrow”

A Continuous Quality Platform doesn’t need to start as a massive initiative.

I would start with five practical capabilities.

1. One-command local validation

1

./start.sh validate

Run the relevant tests and checks without developers remembering 20 commands.

2. Reproducible test data

1
2

./start.sh seed-test-data
./start.sh reset-test-data

Every developer and CI pipeline starts from a known state.

3. API + Contract testing

Every service should have an explicit contract.

Every contract should be automatically validated.

4. Production bug → regression test

Every escaped defect should result in a permanent automated check wherever practical.

5. Quality signals in the developer workflow

Don’t hide quality metrics in a QA dashboard.

Make them visible where developers work:

• PRs
• CI
• Developer portal
• Service catalog

Start measuring:

• Test execution time
• Test failure rate
• Flaky tests
• API contract violations
• Escaped defects
• Regression rate
• Performance/SLA violations
• Mean time to detect
• Mean time to resolve

You don’t need to implement everything on day one.

Pick one painful quality gap and remove it from the paved road.

Then repeat.

The outcome I’m driving toward

The Internal Developer Platform I described in my previous project focused on reducing the friction between:

Clone → Develop → Validate → Ship

The Continuous Quality Platform extends that idea.

It asks:

What if “Validate” wasn’t a single step before shipping?

What if validation happened continuously?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

                DEVELOP
                   ↓
              SPECIFY
                   ↓
               VALIDATE
                   ↓
                 SHIP
                   ↓
               OBSERVE
                   ↓
                LEARN
                   ↓
               IMPROVE
                   │
                   └──────────→ DEVELOP

That’s the loop.

The platform doesn’t replace developers.

It doesn’t replace SDETs.

It doesn’t replace QA.

It doesn’t eliminate the need for engineering judgment.

It does something more useful:

It makes the right engineering behavior easier to repeat.

After spending more than decade in engineering, I’ve learned that the biggest improvements rarely come from telling people to “be more careful.”

They come from changing the system so that doing the right thing becomes the easiest thing to do.

That’s what I want the Continuous Quality Platform to achieve.

Not more testing for the sake of testing.

Not blaming QA for every escaped defect.

Not another dashboard.

A platform where quality is built into the path from specification to production—and where every failure makes that path stronger.

Quality isn’t owned by QA.

Quality is owned by everyone who builds the product.

The platform’s job is to make that ownership practical.