← Back to home

How we work

A short loop, repeated until the work reads cleanly.

Three steps, in order, for every project. We don't run sprints — we run cycles, each ending with a tool that's measurably more honest than the last one. The pace is slow on purpose, and the slowness is the work.

Process

01

Research

Every project opens with a week of listening. Store reviews, support inboxes, threads on the categories we ship in, and analytics from prior releases when partners share them. The brief gets rewritten before the design starts — usually shorter than what came in, and pointed at a different problem than the one originally framed.

02

Design

Wireframes are written, not wireframed. Once the brief survives plain prose, we move to figma and prototypes — but only the screens that earn their place. The kill rate at this step is intentionally high. A screen that can't be summarised in one sentence doesn't survive into build.

03

Ship

TestFlight to a small inner ring first. Public release only after a quiet week without regressions there, and only when the changelog reads cleanly to someone who didn't write the code. Post-release work — bug-fix passes, polish, the small refusals that protect the tool's voice — gets its own dedicated cycles, not afterthought time.

Frequently asked

01

Do you publish under your own brand or white-label?

Both. White-label is the default for partner work; we can also publish under a portfolio identity if the brief requires consistent voice across releases. The choice gets made once, at the start, and is rarely changed mid-project.

02

What is a typical engagement length?

Three to nine months for a single utility, depending on category complexity and the partner's release cadence. We don't take month-by-month retainers — too short to ship anything that lasts, and too short to learn from what we shipped before.

03

Do you commit to specific release dates?

We commit to scope. Dates get revisited at every internal review and shared as ranges, not as fixed promises that compress quality. Partners that need a hard date pick the scope, not the other way around.

04

Can you onboard mid-project?

Yes, after a short audit week. We agree on what stays, what gets rewritten, and what gets shelved before any handover work begins. Partners that skip the audit usually pay for it later in scope discovery.

05

Do you take equity instead of fees?

Rarely, and only with partners we've already shipped one full release with. Equity is not a discount mechanism for us — it's a long-term alignment, and the trust to underwrite it has to be earned first.

06

Will the work be readable by another team afterwards?

Yes. We hand over a codebase another team can read, a brief that explains why decisions were made, and a runbook for the categories we shipped against. Continuity is part of the deliverable.