Processes - Embedded Software Development - Onboarding & Delivery Process
A clear walkthrough of how a team moves from initial interest to embedded delivery on an existing product or system.
Overview
This process is for teams that already have an active product, backlog, or internal system and want experienced development capacity added quickly.
The goal is simple: reduce uncertainty early, make sure the engagement is a fit, then get useful work moving fast without adding management drag.
1 - Interest and intake
The process starts with the dedicated service intake form.
The intake captures:
- What product or system you need help with
- The team and stakeholders involved
- The current technical context
- What outcomes you need
- What constraints, urgency, and blockers exist
- The intro call slot that works for you from the currently available options
2 - Fit review, rate confirmation, and intro call
After the intake is submitted:
- The engagement is assessed for fit, timing, and likely delivery shape
- I confirm whether I have current capacity to support the work
- If it looks like a fit, I reply with the appropriate rate and confirm the intro call
- If it is not a fit, or the timing is wrong, we'll let you know and suggest the most useful next step
3 - Agreement and kickoff
If we both want to proceed, the next step is operational setup.
That usually includes:
- Confirming the retainer rate (Β£5,200/mo) and the initial onboarding period (typically 2β4 weeks)
- Agreeing communication expectations, preferred channels, and response SLA
- Finalising the contract and any procurement steps
- Exchanging repo, hosting, tooling, or documentation access
- Defining the first batch of work to start with
4 - First delivery cycle
The first cycle is about becoming useful quickly.
Typical early work includes:
- Understanding the current architecture and delivery setup
- Identifying the highest-value near-term work
- Resolving obvious blockers or risks
- Taking ownership of implementation work that relieves pressure on the team
5 - Ongoing operating rhythm
Once delivery is underway, the engagement runs in a structured weekly rhythm.
Daily β every working day: A morning touchpoint (planned focus, any blockers, what I need from you) and an afternoon or end-of-day touchpoint (progress made, decisions taken, what's next). These happen via your preferred channel β Slack, WhatsApp, or equivalent. They do not require a meeting unless that is what you prefer.
Weekly β three structured touches:
- Monday planning note β what is committed this week, expected outputs, any risks
- Midweek delivery β a visibly shipped artifact, decision, or retired risk
- Friday status note β Done / In Progress / Waiting on you / Next week
Monthly β retainer review: A short review covering wins and outcomes delivered, anything that slowed delivery, and whether the retainer should be maintained, adjusted, or closed.
This rhythm means you always know what is happening and what is coming next, without needing to chase for updates.
6 - Decision points during the engagement
As the work progresses, a few decisions tend to come up at the monthly review or earlier if the situation changes:
- Continue the retainer at the current intensity
- Add a launch / go-live supplement for a high-intensity release window β this is priced separately and covers deployment, rapid triage, and founder-facing communication support
- Expand into a full rebuild or new-system-build engagement
- Wrap the engagement after the key delivery goal has been reached
7 - Offboarding or extension
At the end of a phase, we either continue with the next priority or close cleanly.
Closeout normally includes:
- Handover on current work and context
- Documentation or notes where needed
- Clear status of in-flight tasks
- Recommendations for what should happen next