What we learned from projects that didn't launch
Two projects from our portfolio never made it into production for completely different reasons. What we got out of them is more valuable than what some launched projects deliver.
Most marketing pages of software companies show only the successes — projects that launched, clients that grew, numbers that impress. That's understandable. It's also incomplete.
In our portfolio, two projects never made it into actual production. Rupa, a platform for a billiard club, was built end-to-end — with a native app, a dashboard, a .NET backend, a Keycloak identity system. The club still hasn't opened.
BetPass, a self-service kiosk system, went through concept and a complete UX/UI design. We started development. The client halted the project for market reasons before the system entered production.
Both projects ended differently than planned — and in both cases we took out more than we expect from some projects that did launch.
Lesson 1: Architectural decisions are worth it even without production
Rupa was built with Keycloak for authentication, Seq for centralized logging, and Clean Architecture in .NET. Those are decisions that mean a month of extra work upfront, in exchange for a system that can live for years without large refactors.
When we made those decisions, the club was still planning to open. Later, when it didn't, someone might think those decisions were overkill. They weren't.
The reason: those decisions are now part of how we think about the next projects. The team learned Keycloak on a real project, not a tutorial. The patterns written there are now used in other projects in the portfolio. The reputation is that we build well — and when a project doesn't make it to production, the fact that we built it well still shows.
Lesson 2: Concept and design are independently valuable
For BetPass, before development, we delivered a complete UX/UI design. Our designer worked through every screen, every flow, every edge case. The kiosk from the ad screen through every individual flow — bill payment, credit top-up, vouchers, betting deposits, raffle, classifieds — everything was visually and structurally thought through.
The client then decided not to continue with development. Market conditions changed, calculations changed, the project was halted.
What remained isn't a Figma file with a few slides. What remained is a complete product design that could be built tomorrow if someone else picks up the initiative. Our designer pulled out experience from that work that we now use on every hardware project — how to model flows for a physical device, how to write error states for hardware failures, how to balance information on a screen that stands 24/7.
In other words: design work doesn't vanish when a project is halted. It spills over into the next projects.
Lesson 3: Honest framing matters more than hiding
It's easier to simply drop projects that didn't launch from a portfolio — as if they never happened. Many do that. We deliberately decided otherwise.
The reason: when we talk to clients about process, part of that story is how we think when a project doesn't go to plan. Do we drop the shovel and walk away? Do we keep building to production quality even when we know there's a risk of cancellation? Do we honestly admit what happened?
When a project that didn't launch stands in the portfolio with a clear note "system ready, club didn't open" — that's a signal that says more about us than ten successful launches. It shows how we behave when the situation isn't ideal.
What that means for the next projects
We build every project as if it will live for five years, even when there are signals that it could be cut short. The reason isn't naivete — it's that quality and discipline shouldn't change with project uncertainty.
Quality architectural decisions stay with the team. Quality design stays in the designer's experience. Honest presentation stays in how clients understand who we are.
Launching isn't the only way a project can be valuable.