Methodology

We write specs before we write code.

Every engagement starts with a spec — the contract between humans and models. The spec is also the durable artifact you keep after we leave: a document your team edits, not a stack of prompts only we can read.

Why spec-first

Clarity scales. Ambiguity scales faster.

AI agents amplify intent. Hand a model a vague brief and you get a vague codebase, faster. Hand it a spec — what should be true when this is done — and the model becomes the most patient engineer on the team.

A spec is also the only artifact a human and a model can both read, critique, and modify in the same way. Code is for machines. Prompts are for the moment. Specs are for the next engineer who has to change something six months from now.

The spec is what we leave behind. After three weeks, your team owns the spec — they edit it, regenerate against it, and use it to onboard the next person. The workflow keeps working because the spec keeps existing.

The four methods

We pick the lightest method that fits the work.

01

Spec Kit

Greenfield, multi-feature projects.

When we reach for it

When you're starting from a blank repo with several interconnected features and systems thinking matters more than speed. Spec Kit's per-feature specs let us reason about how features interact before any of them ship.

What you get

Per-feature spec files, a structured /specify → /plan → /tasks flow, and cross-feature analysis baked into the methodology.

02

OpenSpec

Brownfield, incremental modernization.

When we reach for it

When the repo already exists and the work is a series of focused changes. OpenSpec's single living spec stays aligned with reality through Propose → Apply → Archive cycles, so the spec never drifts from what shipped.

What you get

A unified living specification, delta-based change proposals, and a fast iteration loop tuned for AI agents.

03

Superpowers

Smaller, well-scoped tasks.

When we reach for it

When the work is contained — a feature, a bug, a refactor — and a skill-driven workflow gets us to a tested change without the overhead of a full spec lifecycle.

What you get

A reusable skill invocation, TDD by default, and a clean commit. The skill itself becomes part of the toolchain you keep.

04

Plan mode

Quick, contained changes.

When we reach for it

When the change is small enough that a written spec is overkill, but large enough that vibe-coding it would be reckless. Plan mode forces a reviewed plan before any edit happens.

What you get

A reviewed plan, then a focused execution. No artifact to maintain — the value is in the discipline.

Decision lens

How we choose, in one chart.

Two axes. Pick the lightest method that lands in the right quadrant for the work in front of us. The further from the origin, the more spec ceremony pays for itself.

Bigger scope earns more ceremony. Smaller scope earns less. The spec is the constant — only its weight changes.

The model layer

The spec is constant. The model is the variable.

We're model-agnostic. We watch the frontier and pick the best model per task — spec stays the same, the engine swaps. That's how we keep up without rewriting the methodology every quarter.

Anthropic
OpenAI
Google
Mistral
Moonshot
Ready?

Three weeks. One engineer.
Your stack, our hands.

Tell us what you are building and we will tell you if we can help. No pitch deck required.