The First 30 Days
Client onboarding process
Six phases, ending in a checkpoint where walking away is easy.
What we do, what we need from you, and what each phase produces. Written down so you can hold us to it, and so you know what a well-run start looks like from anyone.
Quick Answer
Updated August 22, 2026
What does onboarding a software development agency look like?
A well-run onboarding takes about thirty days and has six phases. Days 0–2 settle the NDA, IP assignment, named engineers, and access. Days 3–7 are spent reading — getting the project running reproducibly, mapping the data model, and writing a risk list — because changing code you do not understand is how expensive mistakes happen. Days 5–10 ship one small real change end to end, which proves the whole pipeline works. Days 8–15 produce an agreed delivery sequence with the assumptions written down. Days 15–30 establish a sprint rhythm with weekly written reporting. Day 30 is an honest go/no-go checkpoint with a revised estimate based on real velocity rather than a sales call.
Access and paperwork
Days 0–2
First shipped change
Days 5–10
Go/no-go checkpoint
Day 30
Best for
- Buyers who want to know what a good start looks like before signing
- Teams that have had an engagement drift for months without a checkpoint
- Anyone benchmarking our process against another agency’s
Not best for
- Engagements under two weeks, where this is disproportionate
- Emergency incident response, which has a different shape entirely
- Fully specified fixed-scope work with no discovery needed
Phase By Phase
What happens, and who does it
- Days 0–2
1. Paperwork and access
What we do
- Mutual NDA and IP assignment signed before any technical detail moves
- Named engineers confirmed in writing, with the seniority you agreed
- We join your Slack, ticket tracker, and calendar
What we need from you
- Repository access under your organisation, with least-privilege scopes
- A named decision-maker available inside the overlap window
- Any environment, design, or third-party credentials we will need
Outcome: Contracts settled and everyone in the same channels. Nothing technical is blocked.
- Days 3–7
2. Read before writing
What we do
- We get the project running locally and reproducibly, and record what that took
- We map the data model, the deployment path, and the parts nobody documented
- We write down a risk list: dependency health, test coverage, security findings
What we need from you
- A walkthrough with whoever knows the system best, even if that is one hour
- Answers to the questions our risk list raises
- Confirmation of what is genuinely a priority versus what is a wish
Outcome: A written picture of what actually exists, which is frequently different from what everyone believed.
- Days 5–10
3. First shipped change
What we do
- Something small, real, and useful goes to production or to a review environment
- Deliberately chosen to exercise the whole path: branch, review, CI, deploy
- Any friction in that path gets fixed now rather than in month three
What we need from you
- Review and merge approval
- Sign-off on the deployment path being correct
Outcome: Proof that the pipeline works end to end, and the first evidence of how we write code.
- Days 8–15
4. Plan and sequence
What we do
- A delivery sequence with the assumptions written next to each item
- Architecture decisions that cannot be deferred, raised with the trade-offs
- An honest view on anything in scope we think should be cut or postponed
What we need from you
- Prioritisation calls — what is first, what can wait, what is out
- Decisions on the architecture questions we surface
Outcome: An agreed plan you could hand to a different team and have it make sense.
- Days 15–30
5. Delivery rhythm
What we do
- Sprints producing something demonstrable, not a status update
- A weekly written report: what shipped, what slipped, and why
- Blockers raised the day they appear rather than at the end of a sprint
What we need from you
- Weekly availability for review and decisions
- Telling us early when priorities change — that costs a conversation, not a contract
Outcome: A predictable cadence you can plan a roadmap against.
- Day 30
6. The checkpoint
What we do
- An honest review of velocity, quality, and communication — ours and yours
- A revised estimate for the remaining scope, based on real data rather than the sales call
- A recommendation, including when that recommendation is to stop or reduce
What we need from you
- A decision: continue, adjust, or end with two weeks notice
Outcome: A deliberate go/no-go while switching is still cheap, rather than a drift into month six.
Why Day 30 Exists
The checkpoint is for your benefit, not ours
Most engagements that end badly did not go wrong in month six — they went wrong in month one and nobody said so. A scheduled, honest review at day thirty, on a contract you can end with two weeks notice, makes it cheap to correct course or to stop. It also means our estimate for the remaining work is based on a month of real velocity rather than on optimism from a sales call, which is the only kind of estimate worth planning against.
FAQ
Onboarding questions
How long does onboarding take?
Paperwork and access take one to two days. First shipped change is usually within a week to ten days. A full delivery rhythm is established by the end of week two, and the first honest checkpoint is at day thirty.
What do you need from us to start?
Signed NDA and IP assignment, repository access under your organisation, credentials for the environments and third-party services we will touch, and — most importantly — a named person who can make product decisions inside the overlap window. That last one is the biggest determinant of whether a remote engagement works.
Why do you spend the first week reading rather than building?
Because changing code you do not understand is how expensive mistakes happen. On inherited codebases the first week routinely turns up things nobody knew — a build that is not reproducible, secrets committed to the repository, a data model that does not match the documentation. Finding those in week one is far cheaper than in month three.
What if the first thirty days do not go well?
That is what the day-thirty checkpoint is for. The contract is monthly rolling with two weeks notice, so ending is straightforward and you have paid only for work done. We would rather have an honest conversation at day thirty than a resentful one at month six.
Can we onboard faster than this?
The paperwork and access steps can compress into a day if you move quickly. The reading week is compressible on a greenfield project, where there is nothing to read. On an inherited codebase we would push back on skipping it, because that week is what makes the estimates afterwards worth anything.
Do you charge for onboarding?
It is part of the engagement, not a separate line item. Days three to seven are billed as normal working days because they are real work — the output is a written risk list and an architecture picture you own, whether or not you continue with us.
Who is our point of contact?
On a pod engagement, a named delivery owner who can change the plan rather than only report on it. On a single-seat engagement, the engineer directly, with one of the founders as escalation. No account managers in between.
Day Zero
Send the brief and the clock starts
A senior engineer replies within one working day, and qualified briefs get a written proposal within 24 hours. Kick-off readiness is 48 hours once scope, access, and commercials are agreed.
Before you sign anything, the security and compliance page covers NDA and IP terms, and the FAQ covers contracts, payment, and handover.
Quick Brief
Start the conversation here
Send the brief, the codebase, or the bottleneck. We reply within one working day.
Your Name
Work Email
What do you need help with?
Reference
The rest of the reference material
How we build, what we commit to, and the facts behind the company.