An engineering team that stays, ships, and remembers

The client is a UK software product company selling to business customers. Its roadmap outgrew its in-house engineering capacity, and for years it filled the gap the way most product companies do: freelance marketplaces, short contracts, referrals from other founders. That worked while the product was small and the codebase fit in a few heads.

Then it stopped working. Every contractor arrived with their own conventions and left with the context. Handovers were verbal or nonexistent. Review discipline eroded because nobody stayed long enough to own a module, and testing depended on whoever happened to be around, so regressions surfaced in production rather than in review. The founders spent their weeks sourcing, vetting, and re-explaining the same architecture to new hires instead of making product decisions.

The client engaged Kentro to stand up a dedicated engineering pod: backend, frontend, and QA engineers who operate as a stable unit inside the client's own repositories, tools, and delivery process, with overlap hours aligned to UK working time and explicit standards for code ownership and knowledge continuity.

Freelance hiring gave the client flexibility on paper and instability in practice. Each problem fed the next.

• Knowledge left with every contract.: Departing freelancers took undocumented context about the codebase, the deployment setup, and past decisions with them. The next hire started from a verbal briefing and a stale README.
• No consistent ownership of the code.: Modules had no long-term owner, so conventions drifted and review standards varied with whoever was available. Nobody felt responsible for the health of the system as a whole.
• Hiring consumed the product leadership.: Sourcing, vetting, and onboarding replacements became a permanent background task for the founders, pulling attention away from customers and the roadmap.
• Quality depended on who was around.: Testing was manual and tied to individuals rather than a process, so defects reached production and eroded trust in every release.

Kentro stood up a cross-functional pod (backend, frontend, QA) that operates as a unit inside the client's own environment: their GitHub repositories, their Jira board, their Slack, their CI/CD pipelines. The pod follows the client's delivery process rather than imposing its own, with contractual overlap hours aligned to UK business time and engineering standards designed so knowledge lives in the system, not in individuals.

• A stable pod, not a staffing list.: Named engineers across backend, frontend, and QA stay with the account, with deliberate cross-training inside the pod so cover exists for leave and attrition without a restart.
• Shipping inside the client's process.: The pod works in the client's repositories and branching strategy, joins standups, sprint planning, and retrospectives, and picks up tickets from the same Jira backlog as the in-house team. Pull requests, reviews, and releases follow the client's existing workflow.
• Code ownership made explicit.: CODEOWNERS files route reviews to accountable engineers, architecture decision records capture why choices were made, and a shared definition of done covers tests, documentation, and review before anything merges.
• QA built into the pipeline.: The pod added automated regression coverage with Playwright and API-level test suites wired into the CI pipeline, so releases gate on green builds rather than on whoever had time to click through the product.
• Knowledge continuity as a working practice.: Onboarding runbooks, recorded walkthroughs of core modules, and rotation of engineers across areas of the codebase keep context inside the team, so a departure is a handover, not an emergency.

The client now treats the pod as its engineering team rather than as external capacity. The change shows up in how the company spends its time.

• The roadmap moved back to the center.: The founders stopped sourcing and re-briefing contractors and returned to product decisions and customers. Hiring stopped being a permanent background task.
• Releases became routine.: With regression suites gating the pipeline and a consistent review standard, shipping stopped depending on individual availability and started following a predictable cadence.
• Context stopped leaking.: Decisions live in architecture decision records and runbooks, ownership is visible in the repository, and new engineers join through a documented path instead of a verbal handover.
• Planning horizons extended.: A stable team with known capacity let the client commit to customer-facing delivery dates it previously would not put in writing.