How we work

Principles.

The day-to-day operating rules that complement the manifesto. Most of them were earned the hard way.

The nine tenets

I.
Ship the smallest useful thing
Every release answers one question. We cut scope until the remaining change is small enough to merge with full attention. The roadmap stays public so users see what's next and what's intentionally not yet.
II.
Public by default
Specs, decisions, and tradeoffs live in the open. We document in the file, not in a wiki. Decisions are recorded in the docs they affect, with their context, so a future reader can rebuild the choice from first principles.
III.
Two-way door first
Reversible changes ship fast. Irreversible ones earn design docs, second reviews, and a runbook. We bias toward options we can walk back from, and we name the few we cannot.
IV.
Templates are test fixtures
Every DeesseJS template is built once, smoke-tested, versioned, and reused. If a template needs custom logic that doesn't generalize, it stays a private fork. The registry earns its name by curating what survives contact with production.
V.
The CLI is the contract
Anything users do often lives in the CLI. The web surface explains; the terminal ships. When the two diverge, the terminal wins. That's where time accumulates.
VI.
Modular before clever
We split until each file has one job, then we stop. Reusable primitives live in packages/* with their own tests, their own version, their own release cadence. Cross-package coupling is a smell.
VII.
Defaults over configuration
We ship defaults that work for 80% of cases. Configuration exists for the 20%; we don't apologize for hiding it under a flag. Every option we expose is a future option someone has to maintain.
VIII.
Observability is a feature
If we can't see it, we can't ship it. Logs, traces, and metrics land with the feature, not after. Internal tools get the same telemetry treatment as user-facing ones.
IX.
Pause before adding
We add things on purpose. The default answer to a new dependency, a new endpoint, a new env var, a new product surface is *not yet*. If the case grows louder after a week of waiting, we revisit. Otherwise, we let it go.

Principles

Put it on your team.

A senior engineer can scaffold your first template, wire your auth and DB, and ship a production-ready codebase on your own infrastructure.

Talk to delivery Read the manifesto

The nine tenets

Ship the smallest useful thing

Every release answers one question. We cut scope until the remaining change is small enough to merge with full attention. The roadmap stays public so users see what's next and what's intentionally not yet.

II.

Public by default

Specs, decisions, and tradeoffs live in the open. We document in the file, not in a wiki. Decisions are recorded in the docs they affect, with their context, so a future reader can rebuild the choice from first principles.

III.

Two-way door first

Reversible changes ship fast. Irreversible ones earn design docs, second reviews, and a runbook. We bias toward options we can walk back from, and we name the few we cannot.

IV.

Templates are test fixtures

Every DeesseJS template is built once, smoke-tested, versioned, and reused. If a template needs custom logic that doesn't generalize, it stays a private fork. The registry earns its name by curating what survives contact with production.

The CLI is the contract

Anything users do often lives in the CLI. The web surface explains; the terminal ships. When the two diverge, the terminal wins. That's where time accumulates.

VI.

Modular before clever

We split until each file has one job, then we stop. Reusable primitives live in packages/* with their own tests, their own version, their own release cadence. Cross-package coupling is a smell.

VII.

Defaults over configuration

We ship defaults that work for 80% of cases. Configuration exists for the 20%; we don't apologize for hiding it under a flag. Every option we expose is a future option someone has to maintain.

VIII.

Observability is a feature

If we can't see it, we can't ship it. Logs, traces, and metrics land with the feature, not after. Internal tools get the same telemetry treatment as user-facing ones.

IX.

Pause before adding

We add things on purpose. The default answer to a new dependency, a new endpoint, a new env var, a new product surface is *not yet*. If the case grows louder after a week of waiting, we revisit. Otherwise, we let it go.