The companies that matter most are the ones most likely to fail on delivery

I've spent 15 years building and running software companies. Across that time, I've watched a pattern repeat itself with uncomfortable consistency: the most interesting companies — the ones with a real mission, a differentiated product, a genuine shot at changing something — are often the ones that struggle most with software delivery.

Not because the founders aren't smart. Not because the engineers aren't capable. But because nobody ever installed the operating model that lets a small team ship reliably at speed. The gap between a great idea and a functioning delivery system is not filled automatically. It has to be built. And for most startups, nobody builds it.

I believe startups and scale-ups are critical to innovation in a way that large organisations simply cannot replicate. They take the risks that matter. They move at the speed that creates change. Helping them succeed isn't just a business opportunity — it's the work that actually moves things forward.

Software development is faster than ever. Delivery is not.

Something important has shifted in the last two years. AI coding tools have transformed the raw speed at which software can be written. A developer with the right tools can produce in a day what once took a week. The acceleration is real and it's not slowing down.

But here's what hasn't changed: the execution framework that sits around the code. Sprint governance. CI/CD pipelines. Code review standards. Documentation systems. Stakeholder visibility. These aren't things AI builds for you. And without them, faster code generation doesn't produce faster delivery — it produces faster accumulation of debt, risk, and confusion.

The bottleneck has moved. It's no longer writing the code. It's governing what gets written, why, and whether it actually ships.

This is the gap Runbaze was built to close. Not the gap in development speed — that's been solved. The gap in delivery infrastructure: the operational layer that turns fast code into reliable, predictable software delivery.

Why a product, not a consultancy

When I started thinking seriously about this, the obvious move would have been to expand Itsavirus into a delivery consultancy. We already had the expertise. We already had the track record. But consultancies leave slide decks. They leave dependencies. They don't leave systems.

I wanted to build something that installs a running system and then steps back. Something with a defined scope, a fixed price, and a clear end state: an operating model that the founder owns outright, that runs without us, and that compounds in value over time.

That's Runbaze. Three layers — strategy, execution, intelligence — installed over nine months. After that, the Pulse Kit runs autonomously. We're not in the critical path. That was always the point.

What we're building towards

We launched in March 2026. We're working with our first clients now. The ambition is straightforward: become the delivery operating system that ambitious startups and scale-ups in the Netherlands, Belgium, and Southeast Asia install when they're serious about shipping.

Not the biggest. Not the most expensive. The most useful — to the companies that are doing work that actually matters.

If that sounds like your company, I'd like to talk.

A mission worth building properly

Food traceability is one of those problems that sounds technical but is fundamentally about trust. Can a retailer verify where a product came from? Can a brand prove its sustainability claims? Can a regulator audit a supply chain in real time rather than after the fact?

Open Food Chain is building the infrastructure layer that makes all of this possible — connecting the entire supply chain from farm to fork, with real-time data sharing, ESG compliance tooling, and verifiable provenance. It's exactly the kind of mission-driven, technically ambitious product that we built Runbaze to support.

When we first spoke with the Open Food Chain founders, the product was already live and working. The ambition was clear. What they wanted was a structured delivery foundation that could scale with them — a system that would let a small, focused team ship reliably without the overhead of a large engineering organisation.

What the engagement covers

We're running a focused three-month foundation engagement, structured around two components.

The first is the Foundation Toolkit — a one-time installation that establishes the delivery infrastructure Open Food Chain needs to operate at the next level. This includes sprint governance and ceremonies, a CI/CD pipeline, version control standards, a documentation baseline, and a Notion workspace with a live roadmap and backlog. By the end of month three, the team has a complete operating model they own outright.

The second component is ongoing part-time developer support: a dedicated Itsavirus developer embedded in the Open Food Chain team one day per week, working within the sprint structure we install. Bug fixes, feature work, technical debt — whatever the backlog demands, moving within a proper process from day one.

Three months, three phases

The foundation is installed sequentially across three months, each building on the last.

Month one focuses on baseline and setup: assessing the current state of the codebase and tooling, establishing the Notion workspace, defining access and licence management, and running the first sprint kick-off.

Month two installs the governance and pipeline layer: sprint ceremonies, Definition of Done and Ready, backlog ownership, branching strategy, CI/CD pipeline, environment management, and basic error tracking.

Month three completes the foundation with documentation and handover: architecture overview, developer onboarding guide, runbooks, API documentation baseline, and a roadmap aligned with MoSCoW prioritisation.

The toolkit installed during this engagement remains in place after month three. Open Food Chain owns the operating model outright.

Why this model works for early-stage companies

For companies like Open Food Chain — where every decision about where to spend engineering time is consequential — having a delivery foundation means more of that time goes into the product. Less into coordination, firefighting, and working out what happened to last sprint's priorities.

We're proud to be building alongside them. This is exactly what Runbaze is for.

A familiar starting point

Open Food Chain is a Dutch food transparency platform — blockchain-based traceability infrastructure connecting farms, suppliers, and retailers in a single verifiable chain. The product vision is clear. The team is motivated. The codebase exists, built rapidly using Lovable, an AI-powered code generation tool.

On paper, they were ahead of most startups at this stage.

In practice, they had a delivery problem. The code was running — but nobody had installed the system around the code. Every week, work happened. But it wasn't predictable, it wasn't visible, and it wasn't building toward anything with a clear endpoint. The founders had no reliable way to know what was shipping, when, or why something was delayed.

This is the pattern we see in almost every scale-up we talk to. The product moves fast in the beginning because there are no constraints. Then it slows down — and nobody can explain exactly why.

What we found

When Runbaze came in at the end of March 2026, the delivery setup looked like this:

The codebase was generated via Lovable and hosted on Supabase — functional, but not structured for a team to work in collaboratively. There was no branching strategy and no agreed Git workflow. Deployments happened manually, whenever someone remembered to push. There were no sprint ceremonies, no backlog with clear acceptance criteria, and no definition of done. There was no documentation — a new developer joining had no reference point for architecture, past decisions, or how to handle common issues. And the founders had no reliable visibility into what the team was actually doing week to week.

None of this was a developer problem. The developer was capable. It was a delivery infrastructure problem — and delivery infrastructure doesn't build itself.

What we're installing

Runbaze is implementing its Foundation Toolkit over three months, March through June 2026. The engagement runs on two tracks simultaneously.

The first track is the Foundation Setup: sprint governance (weekly ceremonies, a live backlog, a clear definition of done), a CI/CD pipeline that makes deployments automatic and boring, a Git branching strategy the whole team follows, a Notion workspace with roadmap and sprint board, and documentation — an architecture overview, a developer onboarding guide, and runbooks. By the end of month three, Open Food Chain owns this operating model outright.

The second track is part-time developer support: a Runbaze developer embedded in the team at one to two days per week, working inside the sprint structure being established, taking on defined backlog items each week. Continuity without key-person dependency.

How the engagement runs

Two standups per week with the client PO. Friday includes a sprint demo — working software only, no half-finished features shown. A written sprint summary goes into the Notion workspace the same day: what shipped, what didn't, why. Every Monday morning the founders receive a Founder Pulse — one paragraph on what's in flight, what shipped last week, and any escalations that need their attention.

No status update meetings. No chasing for progress. The information is in the system.

The pattern behind this

Open Food Chain is not an unusual situation. It's the default state of most startups that move fast on product.

AI tools like Lovable, Cursor, and Copilot have made it faster than ever to generate working code. But they haven't made delivery easier — they've made the gap between "code exists" and "team ships predictably" wider. You can generate a codebase in days. You cannot generate a delivery system. That still has to be installed.

A delivery system is a sprint rhythm your team actually follows. A backlog that reflects real priorities. A CI/CD pipeline that makes deployment boring. Documentation that lets a new developer onboard without depending on the person next to them. Founder visibility that doesn't require a meeting to obtain.

None of that comes from a code generator. All of it can be installed — in three months.

The engagement kicked off April 1, 2026. We're currently in the Foundation Setup phase. This case study will be updated as results come in.

If your team is shipping — but not predictably — book a call. This is exactly what Runbaze is for.

The rush to add AI is understandable. The sequencing is usually wrong.

In the last two years, almost every software team has started experimenting with AI development tools. Copilot, Cursor, Claude Code — the tools are good, they're getting better, and they genuinely do make individual engineers faster. The problem isn't the tools. The problem is what happens when you point fast tools at a slow, disorganised process.

What we see consistently is this: a team adopts an AI coding assistant, output increases for a few weeks, and then the problems start. More code gets generated than anyone can review. PRs pile up. Documentation falls further behind because the AI wrote the code but nobody wrote the explanation. Security debt accumulates because the AI doesn't know your compliance requirements. And because there was no structured workflow to begin with, the AI just made the existing chaos move faster.

AI accelerates what's already there. If what's already there is disorder, AI accelerates disorder.

What BMAD actually is

BMAD stands for Break it down, Make it work, Architect, Deliver. It's an open, production-validated framework for AI-assisted software development — not a single tool, but a method that structures how work gets planned, designed, and built when AI agents are involved.

The core idea is that different phases of software development require different kinds of thinking, and AI agents are much better at some phases than others. An LLM is excellent at generating code from a well-specified task. It's much less reliable at deciding what to build, why, and in what order. BMAD separates those responsibilities explicitly: specialist agents handle each phase, and human engineers review and approve before the next phase begins.

There are four phases. In the first, a PM Agent and Analyst Agent work together to produce a PRD — a product requirements document that becomes the single source of truth for everything downstream. In the second, an Architect Agent produces a technical spec: system design, risk assessment, a task breakdown. The third phase validates before committing: a UX Agent and Test Architect Agent define acceptance criteria and a QA plan, so that when implementation starts, done has a clear definition. The fourth phase is implementation — Dev Agents for frontend, backend, and API work, a Code Review Agent checking every PR, and the CI/CD gate enforcing quality before anything ships.

Between phase two and phase three, there's a mandatory human review gate. Engineers review the architecture, the approach, and the task breakdown. Nothing gets built until that sign-off happens.

AI proposes. Engineers decide. Always. This is what makes agentic development trustworthy at scale — not just fast.

Why the foundation has to come first

BMAD requires things to already be in place before it can run properly. A CI/CD pipeline that will actually enforce the quality gate. A documentation baseline that agents can reference for architecture context. A clear branching and PR workflow so the Code Review Agent's output goes somewhere useful. Sprint governance that means the PRD actually reflects real priorities, not last month's backlog.

Without those things, BMAD doesn't fail gracefully — it fails confusingly. The agents produce output that has nowhere to go. The review gates have nothing to enforce against. The specs get written, approved, and then ignored because there's no process that actually runs them into production.

This is why we spend the first six months of every engagement installing the foundation before touching BMAD. Sprint discipline, CI/CD, security hardening, documentation — the fundamentals that every team agrees are important and almost no growing team has properly installed. Once those are in place, BMAD goes live at month seven and actually runs inside a process that can handle it.

What this looks like in practice

We validated BMAD on a real client engagement before making it a core part of the Runbaze model. The results were clear enough that we built it into the standard nine-month arc.

In practice, running BMAD changes what engineering meetings look like. The standup stops being "what did you work on yesterday" and becomes "what did the agents produce, what did engineers approve, what's blocked." The PRD review gate — where engineers sign off on architecture before implementation starts — is the moment where the most expensive mistakes get caught. An AI agent proposing a technically plausible but fundamentally wrong approach is a common failure mode. Catching it before code gets written costs almost nothing. Catching it after costs a sprint.

The Founder Pulse at the end of the engagement reflects BMAD activity automatically: which agents ran, what PRs were reviewed, what shipped. No one writes it. The system produces it.

The honest limitation

BMAD is not a shortcut to a smaller engineering team. It makes engineers more effective — it doesn't replace the need for engineers to make decisions. The human review gates are not optional steps that can be automated away later. They're the reason the whole system is trustworthy.

What BMAD does do is change the ratio of human time to output. Engineers spend more time reviewing, approving, and directing — and less time on implementation tasks that agents can handle reliably. That's a genuine productivity shift. But it requires engineers who can work that way, in an organisation that has the process structure to support it.

Foundation first. Then BMAD. In that order, it works. In the other order, it doesn't.

What we're building toward

The longer-term direction is a delivery system where the Runbaze operating model — the sprint governance, the CI/CD pipeline, the BMAD workflow, the Pulse reporting layer — runs with minimal human overhead. Not zero humans, but a small team capable of managing delivery across multiple clients because the infrastructure is doing most of the coordination work.

We're currently running this on two live client engagements. The method is validated. The sequencing is clear. If your team is ready to move toward agentic development and wants to do it properly — starting with the foundation audit — book a discovery call.