How we actually work.

Every engagement begins with a 20-minute discovery call. Free. No obligation. The job of the call is not to sell — it is to decide, together, whether the project is one we can deliver well.

If it is, the next deliverable is a written scoping document. One page or three, depending on the project. It states the problem, the constraints, the rough decisions already taken, the open questions, the success criteria, and the rough shape of the timeline. We do not start writing code until the scoping document has been signed.

Pricing follows the scope. Fixed-stake for well-defined projects, time-and-materials for the genuinely uncertain ones. We are honest about which category the work falls into; both are valid, but they need different contracts.

We work in TypeScript end-to-end. React or Next.js on the web, React Native on mobile, Node.js on the server, PostgreSQL or MongoDB for storage, Vercel for hosting. The list is short on purpose.

Opinionated stacks compound. The more times we ship the same shape of thing, the better and faster we ship the next one. A new engineer can be productive in a week because the patterns do not change between projects. A client who hires us a second time inherits a team that already knows how their first project works.

We are not religious about the stack. When a project genuinely needs Python or Go or Rust we use it. But the bar to leave the default is high, and we write down — in the decision log — why we left it.

Every project ships with the same four documents in the repo, in plain markdown. The documents are part of the deliverable. A project is not considered shipped until they exist.

• decisions.md — the architectural decision log. Every choice that lasts longer than the conversation it was made in. Three short paragraphs: what we decided, why, and what we considered and rejected.
• onboarding.md — clone to running tests in under an hour. Every step. Including the embarrassing ones.
• why-we-said-no.md — a running list of features, dependencies and integrations we considered and chose not to do, with one line on why. The single most useful document for keeping scope honest over time.
• CHANGELOG.md — a customer-facing changelog in plain prose. One entry per ship. The contract with users that says: this product is being looked after.

These are not nice-to-haves. They are the leverage that lets a small team take on the work of a much larger one without losing coherence as the project ages.

A decision-log entry is short, dated, and follows a fixed shape. We do not change the shape — discipline beats expressiveness.

# DEC-014 · 2026-04-08
## What
We are moving the admin dashboard from CRA to Next.js 14 App Router.

## Why
Server components let us delete the auth-fetching client wrapper that has
caused three production incidents this year. The team is already deeply
familiar with Next 14 from client work.

## Rejected
- Stay on CRA + add server proxy: doesn't solve the hydration issue.
- Migrate to Remix: team has less production experience; switching cost.

## Owner
Happyness · reviewed by Eric.

The number (DEC-014) is monotonic and never reused. The date stays even when the decision is later reversed — we add a new entry referencing the old one rather than editing history.

Once a week, every active project gets a 45-minute internal review. One project per slot, the same four questions every time.

1. What did we ship since last Friday?
2. What did we learn that we did not know last Friday?
3. What is blocking us right now?
4. What is the single most important thing for next week, and what would have to be true for it to actually happen?

The review produces one written paragraph per project, posted internally. Clients receive a shorter version on Mondays — the ship list, the learning, and the next-week commitment. No marketing voice, no padding, no apology.

We aim for a meaningful production deploy every two weeks on every active project, public changelog updated the same day. Two weeks is short enough that scope creep cannot hide and long enough that we are not shipping noise.

When a sprint cannot ship — and that does happen — we ship the changelog entry anyway. Nothing user-visible this fortnight; here is what we worked on, here is when the next ship lands. Silence is more expensive than honesty.

Before a pull request can merge to main, it passes five gates. They are encoded in CI, not in human discretion — we have learned that human discretion drifts.

• TypeScript strict, no any outside generated code.
• Unit tests for any new business logic; integration tests for any new endpoint.
• WCAG 2.2 AA. Accessibility regressions block the merge.
• Performance budget: LCP < 1.5 s, INP < 100 ms, CLS < 0.02. New bundles are reviewed against last week's baseline.
• A decision-log entry exists for any choice the PR introduces that future engineers will reasonably ask about.

We are not interested in tests for their own sake. We are interested in not waking up on a Saturday to a regression that a test would have caught.

Every project ends with a written hand-off. The client owns the repository, the cloud accounts, the domains, the secrets, and every document we wrote along the way. There is no licensing tier that holds anything back.

We offer two post-launch retainers — a maintenance one and an evolution one — but they are optional. Clients who choose to take the work in-house leave with everything they need. That is part of the trade. The reputation it builds is worth more than the lock-in we'd otherwise have.