Why We Shelved Two Products and Kept One

We’ve built three products under the Cerberus Labs umbrella. One is live in restaurants across Mexico, processing real orders. Two are shelved.

“Shelved” is a deliberate word choice. Not failed. Not abandoned. Shelved - a decision made with information, not a retreat from difficulty. The engineering on both was sound. The external environments changed in ways that made continued investment irrational.

This post names exactly what changed, and what it taught us about when to stop.

The Cerberus Financial Platform

The Cerberus financial platform was our most technically ambitious internal project. Ten-plus years of NYSE and NASDAQ data. DCF models, comparable company analysis, EV/EBITDA and EV/Revenue multiples. Integrations with Polygon.io for tick-level market data, AlphaVantage for historical pricing, SEC EDGAR for filing data, and FRED for macroeconomic indicators.

The architecture was Clean Architecture in .NET - seven C# projects with proper dependency inversion, MediatR for CQRS, adapters that insulated business logic from external provider changes. We’d written about this structure separately because the engineering decisions themselves were worth documenting. When AlphaVantage changed their rate limiting policy, we updated one adapter. The rest of the platform didn’t know and didn’t care.

Then advanced language models got good at financial analysis.

Not “good enough to replace a seasoned analyst” - but good enough to replace the core value proposition of a self-service platform aimed at individual investors and small funds. The market we were building for started getting what they needed conversationally: ask a model to pull comparable companies, run a rough DCF, identify where the assumptions are sensitive. The output isn’t as rigorous as a purpose-built platform. For most users, it doesn’t need to be.

We were digging a moat. The landscape shifted while we were digging, and the moat was no longer where the value was.

The technical quality of the platform was high. That’s not the variable that matters when the category gets commoditized. We had two choices: narrow the target to institutional users who need auditability and regulatory compliance - a much harder sales motion - or stop. We stopped. The intellectual property from the platform, the valuation logic, the data integrations, continues to inform client work in financial services. The platform itself is shelved.

Boost 'Em

Boost 'Em was a fan engagement platform for NCAA NIL - Name, Image, Likeness. The timing looked good. NIL opened up a real commercial opportunity for college athletes to monetize their audience, and fan communities were hungry for direct-to-athlete engagement mechanics.

We scoped the product against the rules as they existed when we started. We got to early stage - product defined, architecture planned, initial development underway.

Then the regulatory environment changed. Not once. NCAA NIL rules were revised multiple times in a compressed period, with state-level variation layered on top. The compliance surface kept moving. What was permissible at one scope date wasn’t permissible six months later. What was permissible in one state wasn’t permissible in another.

This is different from the Cerberus financial platform situation. That was market displacement - a technological shift made the product category less defensible. Boost 'Em was regulatory displacement - the rules governing what the product could do kept changing faster than we could build to them.

The decision calculus: continue investing in a product whose compliance requirements are a moving target, or stop and redeploy that engineering capacity elsewhere. We stopped. The NIL space may settle. If it does, we’ve already done the architecture thinking. But building to a regulatory environment in flux is a particular kind of risk that’s worth naming clearly, because it’s different from normal product-market-fit risk.

PayTable

PayTable survived because the problem it solves is physical.

Restaurants need to take orders. Restaurants need to process payments. Those facts don’t change because a language model got smarter. They don’t change because a regulatory body issues new guidance. A waiter app, a QR scan that routes to the right table, a thermal printer that fires in the kitchen within two seconds of an order being placed - these are concrete operational requirements that exist every service, every day.

PayTable is live in Mexico. Real transactions, real load testing against the hardware and infrastructure we operate - Star TSP143IV thermal printers via CloudPRNT, dynamic screen stations per table, Elo kitchen displays running our Kotlin app in kiosk mode. The .NET 9 backend and Vue 3 PWA are complex enough. But the product isn’t the software. The product is the system - and the system touches physical reality in every restaurant that runs it.

The distinction matters: we weren’t building technology and looking for a problem to apply it to. We were building toward a concrete, observable, physical need. That’s why the decision to keep building was straightforward. The demand is structural, not trend-dependent.

We’re targeting 2,000 restaurant deployments for the 2026 World Cup cycle. The path from here is operational - scaling device monitoring, field support, the logistics of hardware deployment across hundreds of locations. These are hard problems. They’re also problems with clear success criteria: did the order get to the kitchen, was the ticket printed, did the customer successfully pay.

The Decision Framework

Three products, three different stories. The framework that emerges from looking at them together:

Market displacement - Cerberus financial platform. The core value proposition got absorbed by a technology shift. The signal is: are there now free or near-free substitutes that serve your target user’s primary need adequately? If yes, you’re not fighting competitors - you’re fighting gravity.

Regulatory displacement - Boost 'Em. The rules governing the product kept changing. The signal is: how frequently is the compliance surface moving, and is the rate of change decreasing or increasing? If it’s increasing, building to the current rules means building to the wrong rules.

Concrete, stable demand - PayTable. The problem is structural. The signal is: does this need exist independently of trends, technology cycles, or policy? Restaurants need to take orders and process payments whether or not anything else in the world changes.

None of these is a failure framework. All three were reasonable bets at the time they were scoped. Two of the bets were overtaken by external conditions before the product matured. The third is operating in the environment it was built for.

What the Shelved Products Built

Every line of code we wrote on the Cerberus financial platform and Boost 'Em informed how we build for clients.

The Clean Architecture patterns we refined on the financial platform are the same patterns we use when we build .NET backends for fintech clients. The CQRS structure, the adapter pattern for external data providers, the dependency inversion that made AlphaVantage swappable - these aren’t Cerberus-specific ideas. They’re engineering judgment we developed by building something real.

The regulatory landscape analysis we did for Boost 'Em made us significantly better at scoping products in regulated industries - healthcare, insurance, financial services. Understanding why a product fails to thrive in a shifting compliance environment is directly transferable to telling a client early when their scope has embedded compliance risk.

The lesson isn’t “fail fast.” The lesson is: pay attention to what’s changing around you. The best engineering in the world doesn’t save a product if the market moves.

We’re not precious about the shelved products. We learned from them, extracted what was transferable, and redirected capacity to where the problems are structural.

Two shelved products. One live platform. Zero regrets about any of the three.