How we work

A fixed weekly rhythm, from first access to every release.

This is the process every development subscription follows. It's the same whether we're building your first version or maintaining an app that's been live for years.

Talk to our team

Your first 30 days

The first month sets up everything the rest of the subscription depends on: access, a shared understanding of the product, a working release pipeline and a roadmap you've agreed to.

For a brand-new product, week one replaces the code audit with a review of your notes, designs and the products your customers compare you to.

Week 1
Access and audit
You invite us to your repositories, cloud accounts and tools, with accounts created for our staff. We set up your shared Slack channel and request workspace, confirm who approves releases, and read through the codebase or your product notes.
By the end: A written audit: how the app is built, what's risky, what's missing, and what we'd fix first.
Week 2
Roadmap and first release
On a kickoff call we walk through the audit and agree the first requests in your queue, in order. We fix the deploy pipeline if it needs it, set up staging if there isn't one, and ship the first small change.
By the end: An agreed roadmap, a working staging environment and a first release with notes.
Week 3
Steady cadence
Requests move from spec to staging on the normal weekly rhythm. Monitoring and error tracking are connected so problems reach us before your customers report them.
By the end: Two weekly reports in hand and a queue that's ahead of the team, not behind it.
Week 4
First review
Your engagement lead runs a short review of the first month: what shipped, what took longer than expected, whether the plan is the right size, and what to change about how we work together.
By the end: A written one-month review and an updated roadmap for the next quarter.

The life of a request

Every request moves through the same five states. Your plan sets how many can be in progress at the same time; the rest wait in your queue, in the order you choose.

01
Queued
Owner: You
You add a request in the workspace: a feature, a bug, an integration or a design task. Write it however you like; a few sentences and a screenshot is enough. You can reorder the queue at any time.
02
Spec
Owner: Lead engineer, then you
When a request reaches the top of the queue and a slot is free, your lead engineer writes a short spec: what will change, how it will be tested, and anything we need from you. Work starts when you approve it.
03
In progress
Owner: Our team
Engineers and the designer build it in a branch in your repository. Larger requests are split so that something reviewable ships every week. Questions go to your Slack channel, not a ticket you have to chase.
04
Review
Owner: Our team, then you
The change goes through code review and automated tests, then deploys to staging. You get a preview link and a short demo video, and either approve it or leave comments.
05
Shipped
Owner: Our team
Approved work is released to production in the weekly release, with written notes. If something goes wrong after release, the fix goes to the top of the queue at no extra cost.

A typical week

Releases happen on Fridays. A request that needs more than a week ships in reviewable parts rather than disappearing for a month.

Monday: Queue check. Your lead engineer confirms which requests are in progress, posts specs for anything starting this week and flags anything waiting on you.
Tuesday: Building. Questions go to your shared channel as they come up, so a missing detail doesn't hold a request until the next call.
Wednesday: Mid-week check. Work in progress is reviewed internally, and anything at risk of slipping past Friday is raised with you the same day.
Thursday: Review and staging. Finished changes go through code review and tests and are deployed to staging with preview links for you to try.
Friday: Release day. Approved work goes to production. You get the weekly report and a short demo video; Growth and higher plans also have a 30-minute call.

What a weekly report contains

Every Friday your engagement lead sends a one-page report. It's written for someone who wasn't in any of the week's conversations, so you can forward it to a co-founder or your board as is.

SummaryThree sentences on the week.
ShippedWhat reached production, in plain language.
Ready for reviewWhat's on staging and needs your approval.
Waiting on youDecisions, content or access holding work up.
Next weekWhat's starting, in queue order.
RisksAnything that could affect dates, cost or users.

Weekly report: week 12

Sample

Client: Example Co.
Plan: Growth, 2 active requests
Release: Production release, Friday

Summary

Saved payment methods shipped to production. Order history export is on staging and needs your approval. The shipping-rates integration is blocked on API credentials from your provider.

Shipped to production

Saved payment methods on the checkout page, with tests for add, remove and default card
Fixed: order confirmation email showed the wrong time zone for West Coast customers
Dependency upgrades, including a security patch for the image library

Ready for your review

Order history export to CSV: preview link and demo video attached

Waiting on you

API credentials for the shipping-rates provider (requested Tuesday)

Next week

Shipping-rates integration, once credentials arrive
Spec for the account deletion flow, for your approval Monday

Risks

None new. Error rate after the release is in line with the previous week.

Illustrative example, not a client's report. Real reports also link each item to its pull request, preview and demo video.

Where we talk

Four channels, each with a clear job, so decisions don't get lost between them.

Shared Slack channel

A channel in your workspace or ours, with the people doing the work in it. Use it for questions and quick decisions. We reply during support hours.

Request workspace

Where the queue lives. Every request has its spec, status, preview links and history in one place, so nothing depends on scrolling back through chat.

Weekly call on Growth and above

A 30-minute demo and planning call with your lead engineer and designer. On the Starter plan, the written release notes and demo video replace the call.

Email

For billing, contracts and anything that needs a paper trail. Support and billing have their own addresses listed on the contact page.

Tools we use with you

These are the tools we typically use. If your company already has its own, we work in yours instead; the accounts stay in your name.

Typical collaboration tools
For	Typically	How we use it
Source control	GitHub or GitLab	Your organization, your repositories. We commit through pull requests that you can read at any time.
Chat	Slack	A shared channel in your workspace or ours. Microsoft Teams works too if that's what your company uses.
Request tracking	Linear or Jira	Your queue, specs, statuses and history. We can use your existing tracker or set one up for you.
Design	Figma	Flows, screens and the design system, in a file your team owns and can comment on.
Demos	Loom	A short recorded walkthrough of each release, so people who missed the call can catch up in a few minutes.
Documents	Your repository, Notion or Google Docs	Audits, architecture decisions and runbooks. Technical decisions live next to the code.

Quality checks on every change

These steps apply to every request on every plan. They're why we release weekly with confidence instead of batching risk into big launches.

Code review on every change

Nothing merges without review by a second engineer. Reviews check correctness, security and whether the code will be easy for the next person to change.

Automated tests

New code ships with tests at the level that fits it: unit tests for logic, integration tests for APIs, end-to-end tests for critical flows. Tests run on every pull request in CI.

Staging before production

Every change is deployed to a staging environment you can click through before it reaches your users. Production deploys are repeatable and can be rolled back.

Written notes

Each release has notes describing what changed, why, and anything you need to tell your own customers. Architecture decisions are recorded in your repository.

Definition of done

A request is only marked delivered when every item on this list is true. If one can't be met, the release notes say which and why.

The change matches the approved spec, or the spec was updated and re-approved
Code reviewed and approved by a second engineer
Automated tests added or updated, and the full suite passes in CI
No new errors or warnings from linting, type checks or dependency audits
Checked against the accessibility target (WCAG 2.2 AA) for new or changed screens
Deployed to staging and tested on the browsers and devices in your support list
Preview link and demo video sent, and approved by you
Release notes written, including anything you need to tell your own customers
Monitoring and error tracking cover the new code paths
Rollback plan known before the production deploy

What counts as a request

A request is any piece of software work we can do in your codebase or infrastructure. Size doesn't matter: a large request is split into parts, and each part ships on its own.

Included in your plan

New features and screens in your web or mobile app
Bug fixes, performance work and dependency upgrades
Integrations with third-party APIs and services
UX flows, interface design and design system work
Infrastructure, CI/CD and deploy pipeline changes
AI features built on Anthropic's Claude
Technical writing: API docs, runbooks, handover notes

Out of scope

Purchasing third-party licenses, hosting or paid APIs on your behalf (you hold those accounts)
Content writing, marketing copy, SEO campaigns and paid ads
Hardware, firmware and embedded systems
24/7 on-call coverage, unless your plan includes it
Legal, tax or compliance advice
Work that breaks our Acceptable Use Policy

Not sure where something falls? Ask in your channel before adding it to the queue. We'll tell you plainly.

If something isn't working

Most problems are solved in the shared channel. When they aren't, this is the escalation path. You can skip a step whenever you need to.

For outages and urgent production issues, follow the incident steps in the support center instead.

Your lead engineer
First stop for anything about a specific request: quality, timing, approach.
How: In your shared channel.
Your engagement lead
When something is still not right, or the issue is about priorities, capacity or the plan itself.
How: Direct message or the weekly call. Expect a written response with a plan by the next business day.
Company leadership
When the first two steps haven't resolved it, or you'd rather not raise it with the team directly.
How: Email [email protected] with “Escalation” in the subject line. It goes to company leadership, not the account team.
Formal notice
For a contract dispute. Our Terms set out a 30-day good-faith resolution period before any claim.
How: Written notice to our legal address, as described in the Terms of Service.

Pausing and cancelling

You can pause a monthly development subscription once a year, for up to 60 days, when you don't have work queued, for example while you gather user feedback. Your queue, repositories and notes stay where they are, and work picks up from the top of the queue when you resume.

You can cancel at any time. Cancellation takes effect at the end of the current billing period, and work in progress is wrapped up or handed over with notes before then. Your code is already in your repositories, so there's nothing to transfer.

How billing works during a pause, notice periods and refunds are covered in our Refund and Cancellation Policy.

Ready to fill your first queue?

Book a call and we'll walk through your first week: what we'll need access to, what the audit covers and when the first release can land.

Book a call See pricing

A fixed weekly rhythm, from first access to every release.

Your first 30 days

Access and audit

Roadmap and first release

Steady cadence

First review