Skip to content
Selected work
Independent creator2026–presentActive

MockPit

Runtime provenance devtools that show whether interface data is live, mocked, derived, hardcoded, or AI-generated before a prototype is treated as production-ready.

MockPit documentation showing its runtime provenance model and development tools
01Problem

AI-assisted prototypes look finished long before their data and failure paths are real, leaving teams without a shared definition of what is safe to ship.

02Decision

Keep provenance in a framework-neutral TypeScript core, then expose it through React, MSW, custom-element devtools, and a Playwright-aware CLI.

03Evidence

Six public npm packages, an MIT-licensed repository, runnable documentation, redaction controls, and automated tests.

A prototype can look more real than it is

AI-assisted product work compresses the time between an idea and a convincing interface. That is useful, but it also hides an awkward question: which values are coming from a live service, which are fixtures, and which were written only to make the screen look complete? A screenshot cannot answer that.

MockPit records that provenance while the product runs. It gives designers, engineers, and reviewers a shared vocabulary for deciding whether a route is still a prototype, ready for integration, or safe to record as customer-facing proof.

The taxonomy is the product boundary

The core models live API data, mocks, fallbacks, derived values, hardcoded copy, authored empty-state copy, empty responses, unsupported capabilities, errors, and unknown sources. Modes then apply trust policies to those facts: mock, hybrid, live, audit, and capture.

I kept this model in a framework-neutral TypeScript package. The browser client wraps fetch or arbitrary asynchronous work, React adds provider and hook ergonomics, and the MSW adapter decorates handlers without making mocking a dependency of the core.

Architecture decision

Custom elements and Shadow DOM power the devtools, so the same panel can run inside React, another framework, or plain JavaScript without inheriting product styles.

Capture is a policy, not a button

A route can define which resources must be live, the minimum acceptable coverage, and the source categories that block capture. The devtools show that checklist in context; the CLI visits routes with Playwright and can fail CI when the same policy is not met.

Exports are metadata-only by default. Including values requires an explicit redaction policy, keeping the useful audit trail separate from accidental payload collection.

Evidence available today

  • Six composable packages published under the `@mockpit` organisation.
  • Vanilla, React, and MSW integration paths documented with runnable examples.
  • Unit and browser coverage for schemas, modes, adapters, custom elements, and CLI audits.
  • An MIT-licensed repository that exposes the implementation rather than only a demo.

The next useful evidence is adoption outside my own examples. Until that exists, the case study treats package publication and testable behavior as proof—not download counts or imagined team impact.