Why I'm Building the Same Product Three Times

Chris Brown

— 3 min read
Why I'm Building the Same Product Three Times
Prototype. Production. Platform.

The deliberate path from throwaway code to production platform

Most founders pick a tech stack, start building, and hope for the best. I'm building VenueLinQ, a compliance and operations platform for UK hospitality venues, and I'm building it three times. Deliberately. Not because I got it wrong. Because getting it "wrong" first is the only way to get it right.

The Three Phases

Phase 1: Proof of Concept (React)

The fastest way to validate whether the UI makes sense and the user flows work. This is throwaway code, intentionally. I'm not building for scale. I'm building for learning.
Can venue managers actually navigate this? Does the incident logging flow make sense at 11pm after a busy Saturday? Does the compliance dashboard tell them what they need to know without training?
You can't answer these questions with wireframes. You need something you can click.

Phase 2: MVP (C# .NET Monolith)

Once the user experience is validated, I rebuild properly. Single deployable application. Proven stack I've used for 20+ years. Gets to market fastest while maintaining code I can actually maintain solo.

This is the version that gets real users. Real feedback. Real edge cases I couldn't have anticipated.

Phase 3: Platform (UnifyLinQ - Microservices + Microfrontends)

Here's where it gets interesting. I'm not waiting until Phase 2 is "done" before starting Phase 3.

UnifyLinQ, the platform that VenueLinQ runs on, is already in development. While the monolith serves real users, I'm simultaneously strangling out components and functionality to the platform architecture.

Authentication? Moving to UnifyLinQ. Shared UI components? Migrating now. Core services that will power future applications? Being extracted as I build them.
This is the strangler fig pattern in action. The monolith doesn't get replaced in one big bang migration. It gets gradually hollowed out, component by component, until what remains is a thin shell calling platform services.

The Build Paradox

This approach embodies what I call the Build Paradox:

The pressure to ship fast often prevents you from building anything that lasts.

Quick fixes become permanent. Architectural compromises compound. By the time you notice, you're maintaining a system that fights you at every turn.
But the opposite failure mode is equally deadly: perfect architecture, no product, no customers. Analysis paralysis kills as many companies as technical debt. Just more quietly.

The solution isn't to avoid technical debt. It's to *choose* which debt to take on, and start repaying it before the interest compounds.
Right now, VenueLinQ is a monolith serving users. But every week, another piece migrates to UnifyLinQ. The debt is being repaid in parallel with the build, not deferred to some mythical future refactoring sprint that never comes.

What This Means in Practice

I will launch the new VenueLinQ website soon. It's the result of Phase 2: the MVP, built properly, ready for real users.

Here's what's going live:

  • Procedures and policies with full version control- Staff acknowledgements that actually prove someone read something (time spent, scroll completion, digital signature)
  • Daily checklists that work on any device- Incident logging with 47 categories and RIDDOR support
  • Compliance frameworks, including Martyn's Law requirements, are mapped and trackable
  • Multi-venue support from day one

It's not feature-complete. But it's real. It works. And venue operators can start using it.

Meanwhile, UnifyLinQ grows underneath it. The platform that will power VenueLinQ and whatever comes next.

Why I'm Telling You This

I run The Build Paradox consultancy alongside building UnifyLinQ. When I advise clients on architecture decisions, platform migrations, or technical debt strategies, I'm not theorising.

Every trade-off I recommend to clients, I'm making myself right now.
Want to know if a monolith-first strategy makes sense? I can show you mine.
Want to understand how to run a strangler migration while still shipping features? I'm doing it this week.

Want to see what "good enough for now" looks like while actively building "good enough forever"?

Those who build AND advise aren't less focused. They're more credible.

VenueLinQ is now accepting founding members. If you run a UK hospitality venue and Martyn's Law is on your radar, [take a look](https://venuelinq.com).

The Build Paradox offers fractional CTO services, technical due diligence, and architecture reviews. If your platform is fighting you, [let's talk](https://buildparadox.com/contact).

Chris Brown is the founder of UnifyLinQ and The Build Paradox. 28 years building enterprise software across insurance, emergency services, and e-commerce. Currently proving that consultants who build their own products give better advice.

Read more