The Bottleneck That No Longer Exists
Internal tooling backlogs used to wait on dev resources. With standardised foundations and AI agents, teams can build what they need without the queue.
Listen to under 2-min AI recap •TL;DR ↓
Join the conversation
Read and Join discussion
The Bottleneck That No Longer Exists
I've been observing how companies handle internal tooling for years now. The pattern is always the same: teams need tools, dev resources are stretched thin, and internal projects sit in a backlog behind higher-priority work.
That bottleneck is gone — with one condition.
One Condition: Standardise Everything
You need to standardise your development lifecycle. Establish a project foundation template — a baseline everything starts from. Embed SSO. Follow the same patterns. Enforce the same structure.
Once that's in place, you don't need developers for every new internal tool. You connect something like Claude Code to the repo, prompt every new feature, and initiate the software development lifecycle again and again from the same starting point.
No dev queue. No sprint negotiations. Just kick it off.
The Three-Level Documentation System That Writes Itself
This only works if you keep track of decisions, features, and development progress. I use a three-level documentation system — and the critical part is that it documents itself.
L1 — Constitution. Defines product purpose, domain model, architectural boundaries, constraints, and tech stack. The why.
L2 — Contracts. Per-module and per-domain specifications: data schemas, acceptance criteria, dependencies. The what.
L3 — Implementation Notes. File maps, algorithms, known deviations, TODOs, and decision logs. The how.
Each level feeds into the next. Together they create a self-developing, self-maintaining ecosystem where context is never lost and AI agents always have what they need to operate effectively.
What I'm Building
I've been building this under the codename Backflip, and I'm open-sourcing it in the coming days.
The premise is simple: when teams need integrated tools with specific capabilities — automation, traceability, history, optimisation — they shouldn't have to wait on dev bandwidth. With a standardised foundation, they can develop projects and tooling via AI while maintaining quality, documentation, and SDLC integration at corp-grade standards.
Fork it. Set it up (or ask your DevOps team to). Kick off what you need to solve.
The Point
I'm building Backflip to unlock productivity by removing the dependency on developer effort for internal tooling. People can build independently while sticking to a proposed standard — every new initiative starts from the same baseline foundation.
Or don't use it at all. Build your own, tailored to your specific stack. Use this as proof that it's doable.
The era of "we need a dev for that" is shrinking fast. The question is whether your organisation is set up to take advantage of it.
What's the internal tool your team has been waiting months for — and what would change if someone could just spin it up tomorrow?
TL;DR
- Internal tooling backlogs exist because dev teams are gatekeepers, not because the work is hard — standardised foundations eliminate that dependency entirely.
- The key prerequisite is ruthless standardisation: one project template, consistent patterns, embedded SSO, same structure every time.
- A three-level documentation system (Constitution → Contracts → Implementation Notes) keeps AI agents effective by ensuring context is never lost.
- The author is open-sourcing a framework called Backflip that lets non-developers spin up corp-grade internal tools via AI prompting against a standardised baseline.
- You don't need to adopt someone else's framework — the real insight is that this approach works, and you can build your own version for your stack.
The "we need a dev for that" era is ending — but only if you standardise first.
Geddy
Senior Web Engineer / Lead
Engineering leadership • AI innovation • Product thinking. 20+ years of web engineering, from independent contractor to engineering leader. Passionate about developer experience and product engineering.