Case study · 2024–2026

How I shipped a product after a vendor burned $300k and a year doing nothing.

A case study. Names withheld; the numbers are real.

Thirty years of the same problem

In the mid-1990s, Cemex — the Mexican cement major, then on its way to becoming one of the largest building-materials companies in the world — had a $1M+ failed accounting build on its hands. The internal program was stuck, the vendor relationship was past saving, and the business needed the system to work. I came in, took the wreckage, and made it ship. I then led the technology Cemex used worldwide for the next fifteen years.

That pattern — somebody tries, somebody fails, the business is left holding the cost, and then someone has to walk in and finish the job — hasn't changed in thirty years. The languages change, the frameworks change, the buzzwords change. The pattern is the same. Here is the most recent example, from 2024–2026: a Sydney startup with active client contracts on the line, where every week without working product was lost revenue.

What I walked into

In late 2024 I was brought into a Sydney startup, structured as a joint venture between an Australian professional body and a Sydney technology lab. The venture's job is to build software for skills and credential recognition and continuing professional-development workflows — the parent body needed it for its own members and intended to license the same product to other organisations. Active client contracts were on the line, and the parent body itself was the anchor customer.

Here is what had happened before I arrived:

• A vendor had been engaged for roughly twelve months.
• The venture had spent north of $300,000.
• Nothing had shipped. There was no working product. There was no plausible date.
• The parent professional body — the anchor customer — was waiting. Client contract obligations were going unmet. Patience was running out.
• The codebase was a half-finished low-code build, dependent on a vendor platform the venture didn't control.
• The contracts and licensing arrangements around that platform were unclear. Nobody internally could tell me, on day one, what we owned, what we rented, and what we could not legally take with us if the vendor walked.
• The internal tech staff was one person. Good engineer, completely overloaded, no leverage.

12 months. $300,000+. Zero working product.

That was the situation. Twelve months gone, $300k+ gone, an anchor customer waiting with contract obligations going unmet, an exhausted in-house engineer, and a codebase nobody on the inside could fully reason about.

The first two weeks: diagnosis before action

The temptation in a situation like this is to start rebuilding immediately. I don't do that. The first two weeks were diagnosis, and the diagnosis was about the business, not the tech.

I did four things in parallel:

I talked to the business. What is the venture actually trying to sell? Who is the first paying customer? What does the anchor customer need this quarter versus what they need eventually? I needed to know the difference between the product roadmap on the slide deck and the one or two things that would unblock revenue.

I audited the inherited code. I read it end to end. I sat with the one internal engineer and asked them to walk me through every assumption. Not to judge it — to understand what was load-bearing and what was scaffolding.

I mapped the licensing. I read every contract with the prior vendor and every licence agreement attached to the low-code platform. I needed to know which pieces of the inherited tech the venture actually owned, which it could keep using, and which would die the moment the relationship with the vendor ended.

I figured out why the vendor had failed. Not as a blame exercise — as a forensic exercise. If I didn't understand the failure mode, I'd repeat it.

The diagnosis, in plain language: the vendor had built the wrong thing the wrong way. They had treated a complex domain — credential recognition has real depth — as a generic forms-and-workflow problem. They had locked the venture into a low-code platform that could prototype quickly but couldn't carry production load or evolve the data model as the business learned. And they had no engineering discipline: no specs, no tests, no deployment rhythm. Twelve months of slipping deadlines and no shipping artefact was the natural result.

Three to five specific blockers were in the way of shipping anything: an unstable data model, a missing identity / authentication layer the parent customer required, a licensing question that needed a clean answer before any client demo, and a workflow that the inherited platform genuinely could not express.

The plan: two tracks, one head

The strategic call I made was deliberately ugly: keep the low-code version one alive while building a proper full-stack version two in parallel.

Why ugly: most engineers would have told the venture to kill version one and start clean. That would have been more elegant. It also would have been wrong. The anchor customer needed something shipping now. The board needed to see motion. The $300k of sunk cost had at least produced something — a partial version one that could be patched into a usable state for a narrow first use case while we built the durable thing behind it.

So I ran two tracks:

Track one — stabilise and ship version one. Patch the low-code build to the point where it could carry the first real customer workflow. Stop adding to it. Treat it as a bridge, not a destination.

Track two — build version two full-stack. Real codebase, real data model, real tests, real deployment pipeline. No dependency on the low-code platform. Owned outright.

One head running both tracks meant the decisions were coherent — what we learned shipping version one fed directly into the version two design. No telephone-game between two teams.

The software factory

The thing I built underneath the two tracks is what I call a software factory. It's the same operating model I now run at Civic Voice. The point of a factory is predictable throughput. Every cycle ships. No bespoke heroics, no rescue weekends, no late-night saves. If a cycle doesn't ship, something is wrong with the process, not with the people.

The factory has four parts.

Spec-driven work. Nothing gets built without a written spec. The spec gets reviewed before code is written. This sounds obvious and almost no shop I've ever audited actually does it. It is the single highest-leverage discipline in software.

LLM-augmented build. I use AI tooling aggressively to compress the boring parts of the build — boilerplate, test scaffolding, schema migrations, documentation. The human attention goes to the parts that need judgement: the domain model, the user experience, the security boundary.

CI/CD discipline. Every change goes through automated tests and a deployment pipeline. We can ship to production safely on any working day. That's not a goal, it's a baseline.

Alliance with the internal team. I did not replace the in-house engineer. I gave them leverage. They knew the business; I knew how to organise the work. We paired. The factory is something they now run with me, not something I run instead of them.

That last point matters. A consultant who builds a black box and leaves is worse than no consultant. The factory is owned by the venture, documented by the venture, and operable by the venture's own people. I am force-multiplier, not single-point-of-failure.

What's shipped

Eighteen months in, here is the state:

• Version one stabilised. The anchor customer is using it for the workflow it needed to be using it for.
• Version two — the full-stack rebuild — is built and in production. The venture owns the code, the data, and the deployment.
• Internal tools live and in daily use. Admin consoles, reporting, onboarding flows for new customer organisations.
• New tooling now ships on a regular cadence, not as one-off projects. The factory produces.
• The company is shipping product continuously and is meeting client contract obligations it had been missing. Strategy plus software factory turned client risk into client wins.
• My engagement is roughly half-time. The venture's output is full-time. That ratio is the whole point.

The vendor-failure pattern — twelve months of nothing, money disappearing — has been replaced with a continuous-delivery rhythm. The board sees motion. The anchor customer sees value. The internal engineer is no longer the bottleneck.

Why this is repeatable

I want to be careful not to dress the Sydney venture up as a one-off. It isn't. It's the latest instance of a pattern I have been running for thirty years.

Cemex (mid-1990s onward). Failed $1M+ accounting build inherited. Fixed it, then led the technology used across the company's worldwide operations for fifteen years. Scale of evidence: durability. That technology didn't get replaced in a panic two years later. It carried the business.

Apps.co (2014). Colombia's national tech-entrepreneurship programme. I helped scale it from five cities to seventeen, and from seventy-five companies per cohort to over two hundred, on a minimal public-sector budget. Scale of evidence: systems design under real resource constraints, in a country that doesn't tolerate American consulting prices.

Sydney startup (2024–2026). This case study. Scale of evidence: stuck product, half-time engagement, continuous shipping, client contract obligations now being met.

The common thread isn't a methodology I invented. It's strategy and execution as one capability: walking into stuck situations with both the strategic call and the execution capacity, building the right thing with the right approach, and leaving behind an ongoing factory rather than a one-off project. Most consultants do strategy. Most engineers do execution. The pattern I run does both, so the strategic decision and the build that follows it stay aligned. In the kinds of situations I'm called into, neither one alone is enough.

What this means for you

If you are running a $5–50M Australian product business and your technology product delivery is stuck — for the reasons you recognise in this story or for entirely different ones — the same approach is available to you.

It does not start with a six-month engagement. It does not start with a proposal full of phases and workstreams. It starts with one week.

Strategic Tech Assessment. $5,000. One week.

A couple of days of focused, high-yield strategic work. At the end of the week you have a strategic tech audit of where you are now, a 90-day prioritised roadmap you can act on Monday morning, a strategy-aligned technology framework specified for your business, and an honest read on whether continued engagement makes sense.

You keep everything regardless. If you don't continue with me, the audit, roadmap, and framework are yours to act on with anyone, including your existing team. Five thousand dollars buys you a defensible direction either way.

Book a 30-minute strategic call. No slides, no pitch deck, a conversation.