Rapid application delivery
Internal tools in days, under enterprise governance
The backlog of small, obviously useful internal software that never clears IT prioritisation. We build it quickly, then register it, document it, and hand it to a named owner.
- Duration
- Five to ten working days per tool
- Ladder stage
- Proof to Product
- Governance
- Classification, register entry, named owner
The situation
The queue that never clears
Every enterprise has thirty to fifty small applications that would each save a team a few hours a week and none of which will ever reach the top of a central development queue. They are individually too small to justify a project and collectively enormous. What fills the gap instead is a spreadsheet with macros, a shared inbox, and a person whose actual job has become copying data between systems.
We clear that queue in short cycles. The discipline is not the speed of the build, it is refusing to let a five-day tool acquire the ambitions of a five-month platform.
Typical tools
- Approval and exception workflows currently run over email.
- Operational dashboards assembled by hand every Monday morning.
- Intake forms that write into an existing system of record.
- Reconciliation views across two systems that will never be merged.
- Internal assistants over documentation, with permission inheritance.
How it runs
One session, one build cycle, one handover
- 01Scoping session: the workflow as it runs today, the data it touches, and the one metric that improves.
- 02Classification: what data class the tool holds, and whether that makes it a candidate at all.
- 03Build cycle: working software in front of the actual users inside a week.
- 04Hardening: authentication, roles, audit trail, error paths, and a rollback.
- 05Handover: runbook, register entry, named owner, and a retirement condition.
What you get, and keep
- The application, deployed in your environment, with source and documentation.
- A register entry describing the data it touches and who owns it.
- A runbook covering support, escalation, and rollback.
- An enablement session for the team that will maintain it.
Prerequisites
- A named business owner who will use the tool weekly.
- Access to the systems it must read from or write to.
- A data classification decision before the first screen.
Not included
- Customer-facing products or public applications.
- Unbounded change requests after handover.
- Replacement of a system of record.
Related engagements
Work that usually sits either side of this
4 to 8 weeks
AI MVP Development
A first product surface with real users, built on evidence rather than on a roadmap slot
Days for a prototype, 6 to 12 weeks for a governed production application
Lovable Delivery and Enablement
Building production applications on Lovable, plus the governance, enablement, and rollout structure enterprises need around it
3 to 5 weeks
Enterprise Vibe Coding Governance
The controls that make AI-generated software safe to ship: code review standards, secret handling, data boundaries, publish permissions, and maintainability handover
One quarter per wave
Build Enablement Programmes
Training non-engineering teams to build their own tools safely, with an intake process and a publishing gate
FAQ
Questions about rapid delivery
- How fast is rapid, honestly?
- A single internal tool with two or three integrations typically takes five to ten working days from a scoped brief. The scoping is the slow part, and we do it in one session rather than three workshops.
- Is this throwaway software?
- No. It ships with authentication, role-based access, an audit trail, and a runbook. Some tools are deliberately short-lived, but they are built so that retiring them is a decision rather than an accident.
- How is this governed?
- Rapidly built software goes through the same controls as anything else: data classification before the first screen, a named owner, and a register entry. Speed comes from tooling and scope discipline, not from skipping the register.
- What should we not build this way?
- Anything that writes to a system of record without a human gate, anything holding regulated data we have not classified, and anything intended to become a customer-facing platform.
Next step
Bring the three tools everyone keeps asking for
We will scope them in one session and tell you which are five-day builds and which are disguised platform projects.