The School of Hard Knocks: From Cubicle to Code Master — Open Source CXO Ep. 22 | Active Logic
The path from corporate cubicle to running your own technology company is rarely linear — and Alex Savenok’s journey is a testament to that. In this episode of Open Source CXO, Alex, Founder and CEO of Rig Technologies, joins Rob Kehoe to share the hard-won lessons from building Vertigo Media (a social music streaming platform), founding Rig Technologies, and navigating the technical and business challenges that most startup founders face.
This conversation is packed with practical engineering and leadership lessons — from the complexity of music licensing to why you should almost never rewrite your software from scratch.
Key Insight: The Music Licensing Labyrinth
Alex’s experience building Vertigo Media offers a cautionary tale about building products in heavily regulated industries. Music streaming seems straightforward from the outside: play songs, charge subscriptions, pay royalties. In practice, the licensing landscape is a web of publishing rights, performance rights, mechanical rights, synchronization rights, and label agreements — each with different rate structures, reporting requirements, and negotiation processes.
The lesson extends far beyond music: any software product that touches regulated data, licensed content, or complex contractual relationships needs to factor compliance into the architecture from day one. Building the technology is often the easy part. Navigating the business and legal constraints is where products succeed or fail.
Key Insight: Why You Should Almost Never Rewrite Software
One of the strongest opinions Alex shares is about software rewrites — and it’s a position that most experienced engineers agree with. The temptation to “start fresh” with a clean codebase is powerful. The existing code is messy, hard to understand, and accumulated years of shortcuts and patches.
But a rewrite is almost always more expensive and risky than it appears. The existing system, for all its messiness, encodes years of business logic, edge case handling, and hard-won bug fixes. A rewrite throws all of that away and forces you to rediscover every edge case from scratch.
The better approach: incremental modernization. Refactor the worst parts, add tests around the fragile parts, and gradually migrate to better architecture. It’s less exciting than a clean-slate rewrite, but it’s far more likely to succeed. This is a principle that guides how Active Logic approaches legacy modernization projects.
Key Insight: Managing Distributed Engineering Teams
Alex discusses the realities of managing engineering teams split across Kansas City and international locations. The challenges aren’t primarily technical — they’re about communication, culture, and maintaining shared context across time zones.
The practical patterns that work: overlapping work hours for synchronous collaboration, strong documentation practices for asynchronous handoffs, and clear ownership boundaries so that teams can operate independently most of the time. The tools matter less than the habits — Slack and Jira don’t help if people don’t use them consistently.
For organizations considering distributed development teams, the key insight is that distribution adds communication overhead. It’s not free — it’s a trade-off. The cost savings from lower labor markets have to be weighed against the productivity impact of coordination challenges.
Key Insight: Microservices — When They Help and When They Hurt
The conversation includes a pragmatic discussion of microservices architecture. Alex shares both the benefits and the pain points from real implementation experience.
Microservices solve real problems: independent deployment, team autonomy, technology flexibility, and fault isolation. But they also introduce real complexity: service discovery, distributed tracing, data consistency across services, and the operational overhead of managing dozens of deployments instead of one.
The practical takeaway: don’t adopt microservices because it’s trendy. Adopt them when your team is large enough to need independent deployment, when your system has genuinely separate domains that evolve at different rates, and when you’re prepared to invest in the infrastructure that makes distributed systems manageable.
Key Insight: Controlling Product Scope
Feature creep kills products. Alex discusses the discipline required to say “no” to features that don’t directly serve the core user experience. Every feature added is maintenance burden accumulated. Every option exposed is cognitive load on the user.
The best products aren’t the ones with the most features — they’re the ones that do a focused set of things exceptionally well. This is particularly relevant for web applications and CRM systems where stakeholders always want “just one more field” or “just one more report.”
Takeaways
- Understand the regulatory landscape before building. Licensing, compliance, and contractual constraints shape architecture decisions more than technical requirements.
- Resist the urge to rewrite. Incremental modernization is almost always safer and more cost-effective than starting fresh.
- Distributed teams require intentional communication practices. Tools don’t solve coordination problems — habits do.
- Microservices are a trade-off, not an upgrade. Adopt them when the benefits outweigh the operational complexity.
- Scope discipline is a competitive advantage. The best products are focused, not feature-rich.
- Hire learners over specialists. Technology changes too fast for rigid expertise — adaptability matters more.
