→ pod --compose
tech_lead: assigned
engineers: assigned
designer: assigned
growth: assigned
qa: assigned
individual_bios: not_published
✓ you get the people who do the work
// team
You get the people who do the work.
This is a small studio. Delivery is organised into pods, and this page describes how a pod is assembled, what seniority we hold people to, and how you interact with them.
How a delivery pod is assembled
A pod is a small group built around one accountable technical decision-maker. Its shape depends on the engagement, not on a template.
Tech lead
The spine of the pod. Owns architecture, writes the scope, reviews the work, and is the person who says whether something is ready. One per pod, always senior, always on the project rather than hovering above it.
Engineers and designer
The people who produce the work. Engineers implement and review each other; the designer produces the interface and holds the accessibility bar. They are the pod, not support staff for it.
Growth and QA
Growth sets up measurement and runs the demand work. QA owns the test plan and defect triage. Both are joined when the engagement needs them, not bolted on at the end.
Pod size follows the work
A focused design system does not need a full pod. A platform with three parallel workstreams does. We size to the scope and tell you what the shape is before you sign, not after.
Continuity on purpose
We keep the same pod on an engagement rather than rotating people in. You should not be re-explaining your product to a new face every fortnight.
Capacity is declared, not assumed
If a pod is committed elsewhere, we say so before taking your work. Understaffing a fixed-fee build to cover another client is how dates slip.
If the fit is wrong, we say so
A pod built around your problem is not the right answer for every problem. If we are the wrong studio for the work, we would rather say so during scoping than quietly produce a mediocre result.
Who does what
Roles, what each one is accountable for, and the thing each is explicitly not doing - because overlapping accountability is how projects stall.
| Role | Owns | Not in scope for them |
|---|---|---|
| Tech lead | Architecture, the written scope, technical risk, code review, and the go or no-go recommendation at each milestone | Writing every line of code. They stay senior precisely because they are not the fastest typist on the pod |
| Engineer | Implementation, automated tests, and reviewing other engineers work before it merges | Deciding the architecture alone. That sits with the tech lead so decisions stay consistent |
| Designer | Interface and UX, the design system, accessibility, and the design and content standards the build is held to | Signing off technical feasibility alone. Every design is checked against build cost before approval |
| Growth strategist | Measurement setup, technical SEO, paid and lifecycle work, and the monthly written read on what moved | Promising rankings, traffic or revenue figures. Anyone who does is not being straight with you |
| QA | The test plan, execution against the acceptance criteria, device and browser coverage, and defect triage | Signing the launch off on their own. Go or no-go is the client decision, informed by the QA result |
| Engagement lead | Your single point of contact. Scheduling, status, commercial questions and escalating when something is stuck | Being a middle layer. You can always reach the tech lead directly |
| Fractional CTO (where the engagement includes it) | Architecture direction, technical hiring, vendor and risk decisions, and written decision records | Delivering code. It is judgement, not capacity, and mixing the two fails on both sides |
The seniority bar
A small studio has one advantage over a large one: the senior person is close to the work. These are the standards we hold ourselves to.
| Expectation | What it means in practice |
|---|---|
| The tech lead is genuinely senior | Architecture and review are not delegated upward to save money. The person who decides is experienced enough to decide. |
| Work is reviewed by someone more senior | Not sideways by a peer for the appearance of a second pair of eyes. The review exists to catch things, not to tick a box. |
| We do not bill junior rates for senior work | Where the pod includes less experienced practitioners, you are told, and they work under review rather than unsupervised. |
| Specialists are identified as such | If a task genuinely needs expertise the studio does not hold in-house, we bring someone in and say so, rather than improvising quietly. |
| The pitch team is the delivery team | A small studio cannot separate the people who sell the work from the people who do it without the gap becoming obvious mid-project. |
How you interact with the pod
The practical mechanics of working with a small studio, stated plainly so you can hold us to them.
One point of contact
A single engagement lead who owns the thread. You will not be passed between four inboxes.
A weekly written status
Four fixed lines: what shipped, what is next, what is blocked, and what we need from you. Written, so it can be forwarded to people who were not in the meeting.
Demos you can attend
Working software, not slides. Recorded on request if the timing does not work.
Decisions are named, not implied
When we need a decision from you we say what it is, why it is needed, what happens if it slips, and by when.
Direct access to the tech lead
No gatekeeping. If you want to talk to whoever owns the architecture, you can.
Shared visibility
A shared board you can see at any time. You should never have to ask what is going on.
AI tooling in delivery
We use it. This is exactly where we use it, where we refuse to, and what that means for you. If a studio hides this, ask why.
Where we use it
Boilerplate, scaffolding, first drafts of documentation, test scaffolding, exploratory research, and helping a reviewer understand unfamiliar code faster.
Where we do not
Architecture decisions, security-sensitive code without review, final claims we publish on your behalf, and anything that has not been read by a human who is accountable for it.
Who reviews it
Every line ships with a human review. The reviewer is accountable for that code. Generated code that does not survive review does not go in.
What we tell you
If AI tooling materially contributed to a deliverable, we say so in the handover rather than letting you assume it was all hand-written.
Who owns the result
You. We do. A tool cannot be held responsible for a defect, so it cannot be your warranty, and we will not present it as one.
→ why: It lets a small studio deliver at the pace of a large one.
→ how: A human writes the code that ships, and is accountable for it.
→ your_data: Your source, credentials and personal data are never pasted into a third-party model as part of delivery. Tooling operates on the project, inside your access model.
→ if_we_get_it_wrong: That is a defect, and defects are ours. See the change request table on the methodology page.
Why there are no names on this page
A deliberate choice, and the honest reason for it.
No individual bios are published
This studio does not publish individual names, photographs or biographies. Nothing on this page is a placeholder for a person who failed to get filled in - the decision not to publish is the policy.
Stock photos and invented biographies are not credibility
A profile page full of people who never touch your project tells you nothing useful. Roles, seniority and review standards are the things you can actually check us on.
Ask, and you get a real answer
Ask who will be on your project, at what seniority, and how much of their time is committed. That is a better question than a bio, and we will answer it in writing before you sign.
Check us on the work, not the CV
We would rather be judged on a demo, a code sample and a reference we can actually produce on request than on a list of adjectives.
Ask who would be on your project
Tell us about the work. We will tell you the pod shape, the seniority and the capacity - in writing, before you commit to anything.