How we work
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
Step 01
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 is rewritten before the design starts.
Step 02
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.
Step 03
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.
Frequently asked
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.
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.
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.
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.
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.
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.