Planning Thoughts
Working document, updated as thinking develops
Purpose
Agentic development tools reduce the time needed to build well-defined software. A small team of experienced engineers uses them to build systems for public bodies, charities and community organisations. The client owns everything we build.
This depends on the engineering practice around the tools: engineers decide what is built, review what the tools produce, and are responsible for whether it is fit for live use. Taking a working prototype to a production system relies on knowing how systems fail in live use; the team has around thirty years of that experience.
Principles
Engineering
The tools write and test code under an engineer’s direction. Engineers decide what is built and judge whether it is ready for production.
Ownership
The client receives the source code, deployment scripts, documentation and version history. We arrange hosting, on our own infrastructure, with a hosting partner or on the client’s servers. The software does not depend on proprietary platforms or API keys we control, so the client can move it to another host. We do not charge licence fees.
Support
We support every system we build for as long as the client needs us. We document the system and train the client’s staff so that they can take on more of the day-to-day support over time, which reduces the client’s costs, at a pace the client chooses.
Handover and support
Handover is the point at which a named person on the client’s side can run the system day to day. It is not the end of our support. Proposals and contracts should not use wording such as “we walk away” or describe handover as the point at which we leave.
How long handover takes depends on the size of the system and on whether the client already has technical staff. A larger system that needs a new internal team can take years. Staff and requirements change, and the client’s staff usually gain confidence in extending the system gradually. We provide training, refresher sessions and help recruiting a maintainer, and for larger clients we help recruit and set up an internal team that can manage the whole system. As the client’s staff take on more, our work moves towards training and occasional advice.
Each system is built so that the client’s staff can run, modify and extend it themselves. Whether and when they do so is the client’s decision, and we continue to support the system for as long as they need us.
What handover includes
- Source code, deployment scripts, version history and runbook, held in the client’s repositories.
- A named maintainer on the client side who has been walked through the system and has confirmed they can run it day to day.
- Documentation and video walkthroughs from which a future replacement maintainer can learn the system.
- A support channel for questions, troubleshooting, retraining and advice on extending the system, available for as long as the client needs it.
- How the client gets on with the system after handover counts towards our own performance measures.
Open questions
Which client should come first? Early on, a reference from a public body will carry more weight with later clients than one from a commercial client, so a health body or council is preferred.
How tightly must a project be scoped to be delivered in two weeks? Most of the scoping should happen at intake. If a project cannot be described clearly in two minutes, it is not ready to start.
How should ongoing support be priced? The price has to cover our costs, because support sold below cost would eventually leave us unable to support clients. It should also not become a retainer that the client pays whether or not they use it. The current preference is a published day rate that the client draws on as needed, without a large fixed commitment.
What balance of grant funding and fee income should we aim for in the first year? Grant support would let us take on useful projects whose clients cannot pay full rates. The risk is that it reduces the pressure to price and deliver work on a commercial basis. The funding plan is an initial seed of £15–50k for January to April 2027, the main £250k seed in place from September 2027 (a target, not yet secured), and self-sustaining operation from late 2028.
Do we need a physical office? A base in a regional centre would help with credibility and with meeting clients and partners. Against that, it adds a fixed cost before there is income to cover it.
How should intellectual property be handled? The default is that the client owns everything we build for them. We keep no licence or reuse rights, and we do not list the work in our portfolio without the client’s permission.
Not yet in the proposal
Testing and handover criteria
We need a consistent definition of “working” for handover. The minimum is automated tests, deployment documentation, a training period with the client’s staff, a named maintainer on the client side, and an open support channel. The 90 days after go-live are a period of intensive support, after which normal support continues. The contract should say so explicitly.
Pricing
The proposed approach is cost-plus pricing at a published day rate for delivery, with ongoing support as a separate draw-down arrangement at a published rate, so that the client knows what an hour of our time costs and uses as much of it as they need. Indicative sprint costs and support rates should go on the public site once one or two engagements have tested the numbers.
Loose ideas
- An annual public report on what was built, for whom, at what cost, and what happened to it, including how clients are getting on with their solutions a year later.
- A small advisory panel drawn from potential client organisations (health bodies, councils, blue-light services) that meets quarterly and advises on which problems to work on.
- A published “not this” list: categories of project we will not take on. It would set expectations and reduce the number of intake conversations about work we would decline.
- Partner relationship with a nearby university for anything requiring specialist domain knowledge we do not carry in-house.
- A simple project registry, public and searchable, showing completed projects, the problem they solved, and (where permitted) the solution. Over time it would form a public record of our work.
- An alumni-style network of past client maintainers: people we have worked with before, who know our methods, can ask each other questions, and can tell prospective clients what working with us is like.
Documents
The Agent-Native Manifesto & Infrastructure Architecture — Engineering principles for building software with and for agents, and a minimal, portable infrastructure for deploying it.
Operating budget — Internal budget for the CIC: Phase One operating breakdown, steady-state shape, sensitivity scenarios, and the working assumptions behind the numbers.
Engineer budget tool — Interactive workforce-and-revenue planner for modelling specific client × developer scenarios at the engagement level.
Landscape survey — Sector-by-sector view of UK public-sector digital spend, vendor dependency, and where moving to client-owned software looks feasible.
Landscape database — Searchable suppliers, products, customers and contracts behind the survey, with sourced spend figures and a review queue for corrections.
Graph explorer — Zoomable map of who supplies what to whom, sized by known spend, with systems that could be replaced highlighted.
Brainstorm summary — Notes from the March 2026 session at which the CIC’s founding ideas were first set out.
Next steps
Suggested steps from the planning material (the architecture note, the operating budget, the engineer budget tool and the landscape survey), grouped by theme and roughly in priority order.
Commercial
- Identify three candidate first clients and start informal conversations about their problem backlog before pitching. A council or health body as the first client would give more early credibility than a commercial client.
- Turn the landscape survey’s recommendations into a shortlist of three to five target sectors, each with specific entry points.
- Draft the intake questionnaire so that a project can be scoped tightly enough to deliver in weeks. If a project cannot be described clearly in two minutes, it is not ready to start.
Financial model
- Re-derive the operating-budget sensitivity scenarios from the £1,200 client day rate. Decide first whether the higher rate flows through to margin (same delivery, more surplus) or is held to cost-plus (same revenue need, fewer billable days), because the two give very different scenario numbers.
- Adopt the pay spine before setting director pay, and minute the decision. Confirm with the accountant how donated days and grant-funded days are treated in the accounts, and keep the two in separate lines.
- Price ongoing support as a published draw-down day rate without a large fixed commitment. Publish indicative sprint and support rates on the public site once one or two engagements have validated the numbers.
Delivery and engineering
- Implement the SQLite backup method now specified in the architecture note (the online backup command or
VACUUM INTO, with the snapshot collecting the export) in the backup scripts, and confirm it in the first restore drill. - Write the handover acceptance criteria: automated tests, deployment documentation, a named client-side maintainer who confirms they can run the system day to day, and an open support channel that continues after handover.
Governance and legal
- Get a legal view on the standard engagement contract: IP assignment, confidentiality, liability cap, and the support draw-down arrangement. Keep it short and in plain English.
- Decide the balance of grant funding and fee income for the first year, and whether a physical base is worth its cost yet.