Continuing our exploration through episodes 5–10 of “Clojure in Product. Would you do it again?” podcast, we encountered teams facing the realities of growth, evolving requirements, and the long-term implications of their technology choices. These conversations with leaders from HolidayPirates, CyCognito, Red Planet Labs, Mobot, JustOn, and Metabase reveal how Clojure performs not just in the honeymoon phase, but when systems mature and teams scale.
Scaling challenges and honest reflections
As our conversations progressed, we met teams dealing with the complexities that come with success. The picture that emerged wasn’t uniformly rosy — these were honest discussions about real challenges alongside genuine achievements.
When growth brings different perspectives
At CyCognito, Yehonathan Sharvit’s team built their cybersecurity platform almost entirely in Clojure, handling millions of events per second while mapping digital assets for major enterprises. But success brought unexpected team dynamics.
“I think the majority of the developers don’t really like Clojure,” Sharvit admits candidly. The issue wasn’t technical capability — it was career anxiety. Some developers worried about marketability: “If I want to join another company, I won’t be aware of the latest JavaScript, React, Webpack modules.”
It highlights a reality many Clojure teams face: the very stability that makes the language attractive to experienced developers can create anxiety about staying current with mainstream trends.
The migration question
Several teams found themselves considering moves away from Clojure, offering valuable insights into when and why such decisions emerge. CyCognito migrated parts of its system to TypeScript, not due to technical limitations, but rather due to organizational concerns about hiring and expertise retention.
Jereme Corrado at Mobot faced similar pressures during their Series A funding round: “Should we hang up the ClojureScript-based front end and just move to TypeScript and more widely embraced solutions?” Their decision to stick with Clojure was based on demonstrated results rather than theoretical benefits.
The pattern is clear: these pressures rarely stem from technical inadequacy, but rather from business considerations surrounding team building and long-term maintenance.
Architecture at scale
The most ambitious projects in our series showcased Clojure’s ability to support complex, long-term development efforts.
Building new paradigms
Nathan Marz’s decade-long journey developing Rama illustrates how Clojure enables fundamental innovation. Starting as research in 2013, Rama became a platform that generalizes event sourcing and materialized views – something Marz believes wouldn’t have been practical in other languages.
“I don’t think Rama really would have been practical to do in any other language,” he explains. The ability to define new programming paradigms within Clojure using macros, combined with the discipline of immutability, made a 10-year R&D effort manageable with a small team.
Their implementation ultimately consisted of 200,000 lines of Clojure source code, plus 250,000 lines of tests, yet it remained maintainable and comprehensible to their five-person team.
Managing complexity and freedom
Alexander Johannes at JustOn describes their evolution from a Salesforce-only company to building their own Clojure platform. The transition revealed both Clojure’s power and its potential pitfalls.
“You are in an open field. You have no boundaries, but you need those boundaries again, to do meaningful work,” Johannes observes. Without proper structure, teams can end up with what he calls “a mess.”
Their solution involved developing clear architectural guidelines and rigorous code review processes, designed explicitly for Clojure’s flexibility — the key insight being that freedom requires discipline.
The teaching and learning
One of the most encouraging patterns across all conversations was how teams successfully grow their Clojure expertise, often starting from zero.
Practical onboarding
At JustOn, they developed a systematic approach: “The most important thing to learn Clojure is to read Clojure code.” Rather than lengthy training programs, they pair new developers with experienced team members and get them working on real problems immediately.
The results speak for themselves — they had one developer who learned Clojure as his first professional language while working as a student, and he’s still with the company years later.
Collaborative learning
Jereme Corrado’s team at Mobot took this further, creating a standing “Clojure Learning” meeting where the entire squad explored the language together. This collaborative approach normalized the learning process and created shared understanding across the organization.
“We hired two developers at once… There were like 40 applicants, which was a lot. And like quality, like…” The filter effect of Clojure attracted motivated candidates who were genuinely interested in functional programming.
The ecosystem in practice
Our conversations revealed how teams navigate Clojure’s ecosystem and the broader question of language stability versus innovation.
Stability as a feature
The common complaint about “stagnant” libraries takes on a different meaning when you understand how successful teams work. Cam Saul from Metabase puts it perfectly:
“In Clojure, you’ll go and you’ll find something that no one’s touched in two years. And you’re like, I guess it just works really well.”
This stability extends beyond individual libraries. Metabase has been successfully using Ring and Compojure for years – not because they’re stuck in the past, but because these tools continue to solve their problems effectively.
Building on solid foundations
Alexander Johannes appreciates this stability from a business perspective: “I like it a lot because the stability is always good because you know what you can expect.” For a company maintaining software over many years, this predictability has real value.
The contrast with JavaScript’s ecosystem is stark. As Cam Saul notes: “It’s honestly kinda exhausting with languages like JavaScript, keeping up with whatever the framework of the week is.”
Open source and community
Metabase’s journey as a major open-source Clojure project provides unique insights into how the language performs in public, collaborative development.
Quality through visibility
“It’s not just us looking at our code, it’s potentially anyone in the world looking at it,” Saul explains. This visibility creates positive pressure for code quality and documentation.
The self-selecting nature of Clojure contributors became apparent: “We don’t have to deal with that as much in Clojure. Some people come try to write Python code in Clojure or whatever, but not as many as if we had a Python project.”
From contributors to colleagues
Metabase has successfully hired several contributors who started by submitting pull requests. This creates a natural pipeline for finding developers who not only understand Clojure but have already demonstrated their ability to work with the specific codebase.
Long-term sustainability
The most compelling insights come from teams with years of experience in Clojure, illustrating how early decisions compound over time.
Competitive advantages
At JustOn, Alexander Johannes discovered an unexpected benefit: “When I’m bringing Clojure to the table as a company, I’m attractive again for a certain part of the developers out there.” Rather than limiting their hiring pool, Clojure became a competitive advantage in attracting motivated developers.
This seems to reflect the character of other companies — Clojure is a filter that draws in developers interested in their work and willing to pay the price of learning new methods.
The productivity payoff
Metabase’s growth story exemplifies how Clojure’s productivity advantages compound.
Starting with four people, they maintained a small team for years while building a product that competes with enterprise solutions built by much larger teams.
“Clojure really lets us do a lot with a tiny team,” Saul reflects. “We didn’t have that pressure to expand out to 500 people early. We were able to ship a lot of stuff with a small team.”
Looking forward
The final conversations in our series painted a realistic but optimistic picture of Clojure’s trajectory. Rather than explosive growth, we see steady adoption by teams that understand its value proposition.
What emerges isn’t just a collection of success stories, but a pattern of how thoughtful technology choices create sustainable competitive advantages. Teams that choose Clojure don’t just get a programming language — they get a development philosophy that emphasizes simplicity, composability, and long-term maintainability.
The question “Would you do it again?” receives a consistent answer across all our guests. As Cam Saul summarizes: “Just how quickly a few people can get stuff done and just all the power it kind of gives you… It really lets a small team get stuff done really quickly.”
These ten conversations reveal that Clojure’s true value lies not in any single feature, but in how it enables teams to build sustainable, scalable systems with fewer people, less complexity, and more focus on solving actual problems. In an industry often obsessed with the latest trends, these teams found something more valuable: a stable foundation for building great software.
