Software development as a service, with a squad you can hold to account

The proposal defines the squad, skills, monthly capacity and delivery responsibilities. It should also identify specialist work, infrastructure charges and third-party subscriptions that are excluded. We agree the review cadence and how changes are approved. Capacity buys a defined team commitment, not unlimited features; the backlog is prioritised within that commitment.

We plan onboarding in weeks rather than assume the team can ship on day one. Timing depends on repository access, environment readiness, documentation and the state of the code. The initial review produces an onboarding plan and first backlog. Where those foundations are missing, setting them up becomes explicit work, not a hidden delay.

It is managed delivery: the engagement includes coordination, engineering review and a visible release process, not just individual developers. Your organisation still appoints a product owner to set priorities and accept business outcomes. We agree who approves architecture, access and production changes so responsibility is not blurred between the squad and your internal teams.

Ownership is written into the contract. We structure the engagement so your organisation owns the commissioned code and project IP under the agreed terms, with access to repositories and delivery documentation. Existing tools, third-party libraries and their licences need separate treatment. Those exclusions should be listed before work begins, alongside any payment-related transfer conditions.

Weekly reviews cover working software, acceptance criteria, blockers and decisions. Monthly governance reviews cover capacity, spend, delivery risks and upcoming priorities. We distinguish a completed development task from a production-ready release. That lets you see whether a dependency, a technical issue or an outstanding business decision is limiting progress, rather than relying on ticket counts alone.

Yes. We agree changes to monthly capacity, skills and notice periods before scaling up or down. Changing priorities also changes what fits in that capacity. We assess the effect on work in progress, dependencies and release dates before moving items. Urgent production work needs an agreed triage route. If demand consistently exceeds capacity, we discuss a revised team commitment rather than quietly accumulating unfinished work.

Yes. We agree repository conventions, review responsibilities, access boundaries and deployment permissions with your engineers. Existing architecture and tooling are reviewed before changes are proposed. Shared documentation and joint technical reviews help keep knowledge within your organisation; a managed squad should not create a parallel delivery process that your own team cannot inspect.

Notice periods, final billing and handover duties belong in the agreement. A planned exit should include current source, backlog status, architecture notes, deployment instructions and a review of supplier access. Any ongoing support is scoped separately. Keeping those records current during delivery makes a pause more manageable than trying to reconstruct them at the end.