Skip to content
Sora Labs.
Start a project
Process

We publish how we work.

This is the sequence we run on every project, in the order we run it. It is public for the same reason we publish engagement lengths: a studio that will not describe its own process in advance is asking you to take the most expensive part on faith.

01week 1

Shape

We write the problem down together until it is small enough to build. No estimates before this exists.

We start from the outcome you need, not the feature list you arrived with. By the end of the week there is a document we both agree describes the same product. That is rarer than it sounds, and it is where most projects quietly go wrong.

02week 2

Architect

Data model, system boundaries, and the three decisions that will be expensive to reverse later.

Tenancy, identity and billing are decided here, because retrofitting any of them is a rewrite. You get a diagram, a schema and a written rationale for each choice, including the ones we rejected.

03weeks 3–14

Build

Weekly demos against a working deployment. You have commit access from the first day, not the last.

Every week ends with something deployed that you can use. There is no phase where the work disappears behind a curtain and reappears at the end. That pattern hides bad news until it is expensive.

04ongoing

Hand over

Runbooks, architecture notes and a walkthrough. The goal is that you stop needing us.

We would rather be re-hired than depended upon. Handover means your team can deploy, debug and extend the system without a call, and we write down the failure modes we already hit so you do not have to find them yourself.

Principles

Four rules we don’t break.

No estimate before a spec

Quoting a build from a conversation is guessing, and the person who absorbs a bad guess is usually the client. We write the spec first, and we charge for that separately so there is no incentive to rush it.

Commit access from day one

You should be able to read every line we write as we write it. Work that disappears behind a curtain and reappears at the end hides bad news until it is expensive.

Weekly, deployed, usable

Every week ends with something running that you can click. Demos against a local machine do not count; the deployment is part of the product.

We optimise for leaving

The measure of a good handover is that you do not need to call us. Runbooks, architecture notes, and the failure modes we already hit so you do not have to find them yourself.