When Should You Replace Open-Source Real-Time Infrastructure? Lessons from Building LO

Nikita Chirov — Sat, 31 Oct 2026 01:26:59 +0000

After eight years of building a social platform, we learned that the hardest infrastructure decision isn't choosing a technology. It's knowing when that technology no longer fits your product.

My name is Nikita Chirov, and I'm the founder of LO (LiveOnce), a social platform combining messaging, calls, communities, entertainment, and digital services.

We've been developing LO for eight years. During that time, we've redesigned major parts of our architecture, replaced some existing technologies with proprietary solutions, and continued using open-source software wherever it makes sense.

One of the most significant changes has been the evolution of our real-time communication infrastructure.

For years, we relied on established technologies, including Centrifugo and, for certain communication-related tasks, mediasoup.

Eventually, we began transitioning toward our own real-time system and developed ConnectX, our proprietary communication protocol.

This wasn't a decision driven by a desire to build everything ourselves.

It came from a more practical question:

At what point does adapting your product to an existing technology become more expensive than adapting the technology to your product?

Why We Started with Existing Solutions

When you're building a new product with a small team, your most valuable resources are time and engineering capacity.

Developing every infrastructure component from scratch is rarely the most efficient way to use either.

At the beginning of LO, our priority was to build a functioning platform, release features, and validate ideas.

We didn't need to invent a new database.

We didn't need to build our own orchestration system.

And we didn't need to develop every communication component ourselves.

Existing technologies allowed us to move faster.

This is one of the greatest advantages of open source.

Today, a relatively small engineering team can build infrastructure that would have required a much larger organization years ago.

But there's an important architectural distinction:

Choosing an existing technology should accelerate your product's development without permanently determining its future.

The Hidden Cost of Architectural Workarounds

Most infrastructure technologies are designed to solve problems for a wide range of products.

That general-purpose approach is exactly what makes them useful.

However, your product's requirements may eventually become more specific than the assumptions built into the technology.

Imagine an existing solution satisfies 90% of your requirements.

The remaining 10% can usually be handled through configuration, additional components, or architectural workarounds.

At an early stage, this is often the right trade-off.

But as the product evolves, new requirements appear.

The workarounds become more complicated.

Additional layers introduce new dependencies.

And eventually, your engineering team starts discussing how to implement a feature within the limitations of the existing infrastructure rather than how the feature should work for users.

That's an important warning sign.

The real cost of a technology isn't limited to licensing, hosting, or maintenance.

It also includes the engineering decisions you're forced to make because of its limitations.

At some point, those limitations can become more expensive than the original technology was intended to save.

How Real-Time Communication Became Critical to LO

In LO's early architecture, real-time technologies supported specific communication features.

As the platform evolved, their role became much more significant.

Real-time communication now supports multiple parts of the product:

Messaging and chats
Calls
User presence and status updates
Application events
Synchronization across devices

These aren't isolated features anymore.

They're fundamental components of the overall platform experience.

This changed how we evaluated our infrastructure.

We needed greater control over connection establishment, recovery after interruptions, behavior under unstable network conditions, and the future development of the communication layer.

We could continue adapting our architecture around existing technologies.

Or we could begin developing a system designed around LO's specific requirements.

We chose the second approach.

Why We Moved Beyond Our Previous Stack

For a long time, we used Centrifugo in our real-time infrastructure and mediasoup for certain communication-related tasks.

Both technologies helped us accelerate development.

They allowed us to focus on building the product instead of spending years implementing communication infrastructure from scratch.

I want to emphasize something important here:

Replacing a technology doesn't necessarily mean the original choice was wrong.

A solution can be excellent for your product at one stage and become less suitable later.

The requirements change.

The architecture evolves.

And the trade-offs that once made sense may no longer be optimal.

That's what happened as LO's communication requirements became more complex.

We began transitioning toward our own real-time infrastructure to gain greater control over a critical part of the platform.

This wasn't about rejecting open source.

It was about aligning the infrastructure with the direction of the product.

ConnectX: Why We Developed Our Own Protocol

One result of this evolution was ConnectX, LO's proprietary communication protocol.

Developing a custom protocol can sound excessive, particularly for a platform that hasn't yet reached millions of users.

But the motivation was practical.

We wanted greater control over how clients interact with LO's infrastructure.

That includes connection establishment, connection recovery, handling unstable networks, and the ability to evolve communication behavior as the platform develops.

In one of our updates, ConnectX optimizations improved connection establishment speed by approximately 20%.

This figure refers to a specific optimization we implemented. It shouldn't be interpreted as a universal benchmark against other communication technologies.

For us, the result demonstrated something important:

Having control over a critical technology can create measurable improvements in the product.

Most users will never know what ConnectX is.

And that's perfectly fine.

Users don't care which protocol operates behind an application.

They care whether messaging works, whether calls connect, and whether the app responds quickly.

Infrastructure should serve those expectations.

When Does Building Your Own Technology Make Sense?

Developing proprietary infrastructure creates new responsibilities.

You become responsible for maintaining the implementation, fixing bugs, testing changes, documenting behavior, and ensuring compatibility as the rest of your system evolves.

The initial development effort is only part of the cost.

This is why we don't believe every critical component should automatically be rewritten internally.

Instead, we evaluate several questions.

1. Is the technology limiting product development?

If your team repeatedly has to redesign product features around infrastructure limitations, it may be time to reconsider the technology.

A few workarounds are normal.

A growing architecture built primarily around workarounds is a different situation.

2. Would greater control improve the user experience?

Building proprietary technology should create a meaningful advantage.

That might involve performance, flexibility, reliability, or the ability to support new product requirements.

For LO, improving control over the communication layer was directly related to the experience we wanted to deliver.

3. Can the team maintain the technology long-term?

A proprietary system requires ongoing investment.

It needs maintenance, security updates, testing, documentation, and engineers who understand how it works.

If your team cannot sustain those responsibilities, building an internal replacement may introduce more risk than it removes.

4. Can the existing solution be adapted instead?

Sometimes the best approach isn't replacing a technology.

It may be possible to modify an open-source project, maintain a fork, or extend the existing architecture.

Building from scratch should be a considered decision, not the default response to every limitation.

5. Will the architecture remain flexible afterward?

Replacing an external dependency with a proprietary component doesn't automatically make your architecture better.

A custom system can also become a source of lock-in.

The goal should be to maintain the ability to evolve the architecture as requirements change.

These questions aren't a universal formula. They're a way to evaluate whether the benefits of greater control justify the long-term engineering cost.

Why We Still Use PostgreSQL and Kubernetes

Despite developing ConnectX and moving toward our own real-time infrastructure, we continue using PostgreSQL, Kubernetes, and many other open-source technologies.

We have no plans to replace them simply to increase the percentage of code written internally.

A mature database or infrastructure project represents years of engineering work.

Maintaining an equivalent system requires continuous effort in areas such as security, testing, performance, documentation, and compatibility.

Open-source communities distribute much of that work across developers and organizations around the world.

Giving up those advantages without a compelling product reason would be inefficient.

For us, technological maturity isn't measured by how many proprietary systems we've created.

It's measured by whether we're making the right architectural decisions for the product.

Open Source and Vendor Dependency Are Different Problems

There's a fundamental difference between using open-source software and relying entirely on a closed external service.

With open source, the code is available.

Depending on the license, you can inspect it, modify it, maintain a particular version, or create your own fork.

You may also be able to replace the technology with another solution.

That doesn't mean migration will always be easy.

Even open-source components can become deeply embedded in an architecture.

But access to the code provides additional options.

With a closed third-party service, the situation can be different.

A provider can change pricing, modify an API, discontinue a feature, or introduce new restrictions.

If a critical part of your product depends on that provider, its decisions may directly affect your roadmap.

This is the kind of dependency we try to avoid.

Our goal isn't independence from code written by others.

It's independence from decisions made by others that could prevent our product from evolving.

Design for the Ability to Replace Technologies

One of the most important lessons from eight years of developing LO is that technologies shouldn't be treated as permanent architectural commitments.

A solution that works perfectly today may no longer fit your requirements five years from now.

Your product will change.

New technologies will appear.

User expectations will evolve.

And your architecture needs to be able to evolve as well.

The mistake isn't choosing a third-party technology.

The mistake is designing a system in which replacing that technology becomes practically impossible.

We've changed major architectural decisions several times throughout LO's development.

Those changes don't mean the previous decisions were failures.

They helped us build the product at the time.

But the product evolved, and the architecture needed to evolve with it.

For us, the ability to replace a component is an important part of long-term technological independence.

Why We Invested in Infrastructure Before Reaching Millions of Users

Today, LO has more than 110,000 registered users.

Compared with the world's largest social platforms, that's still a relatively small audience.

So why invest so much effort into infrastructure at this stage?

We could have allocated more resources to marketing and less to technology.

Perhaps our registered user count would be higher today.

But we might also have attracted a larger audience to an architecture that would eventually require significant rebuilding.

For much of LO's eight-year history, we invested primarily in the product and its technological foundation.

Now the challenge is changing.

Previously, we needed to demonstrate that we could build and continuously develop a complex platform.

The next stage is about scaling it.

Our plans also extend beyond a single application.

LO already includes messaging, Flows, communities, music, places, and events. We're developing mapping capabilities and planning mini-apps and opportunities for third-party developers.

When external developers begin building services on top of your infrastructure, that infrastructure becomes part of the product itself.

At that point, controlling critical technologies becomes even more important.

This doesn't mean every startup should build its own real-time system before reaching a certain user count.

For many products, established technologies will remain the better choice for years.

Our decision was based on LO's particular architecture and long-term direction.

The Three Principles We Follow Today

After eight years of building LO, our approach can be summarized in three principles.

Use established open-source technologies when they meet the product's requirements.

There's no reason to rebuild something that already works exceptionally well.

Adapt existing solutions when customization is more efficient than replacement.

A fork, extension, or architectural adjustment may solve the problem without introducing the maintenance burden of a completely new system.

Build proprietary technology when controlling a critical component creates a meaningful advantage.

This is where internal development can become a strategic investment rather than unnecessary engineering complexity.

And above all, keep the architecture flexible enough to reconsider those decisions as the product evolves.

Final Thoughts

Developing ConnectX taught us that building proprietary infrastructure can make sense when it solves a real product problem.

Continuing to use PostgreSQL, Kubernetes, and other open-source technologies reminds us that building everything ourselves would be neither practical nor efficient.

These approaches aren't contradictory.

They're complementary.

Open source allows us to benefit from technologies developed by the global engineering community.

Proprietary systems give us greater control where that control genuinely matters.

And a flexible architecture allows us to choose between them.

Technological independence isn't about owning every line of code. It's about maintaining the freedom to decide how your product evolves.

DEV Community: Nikita Chirov