Most early-stage founders think about scaling as a future problem — something to solve after product-market fit, after the first significant revenue milestone, after the team is bigger. The founders who build companies that actually scale think about it differently: scaling is a design constraint from day one, not a phase that comes later.
Fritz Lanman's trajectory across ClassPass and Mindbodyoffers one of the clearest illustrations of this principle in practice. ClassPass didn't just grow — it grew into a category it helped define, across thousands of fitness partners and millions of members, without the backend becoming the thing that held it back. That kind of growth is not accidental. It reflects a set of deliberate product decisions made early and consistently.
Key Takeaway
Scalable products share three design properties: infrastructure that handles load without degradation, architecture that evolves without full rebuilds, and processes that stay efficient as the team grows. All three are decisions made at the beginning — not problems solved after the fact.
“By prioritizing a robust backend and flexible design from the start, ClassPass could rapidly expand its services without the infrastructure becoming the constraint on growth. Scalability isn't a phase — it's a design decision.”
Fritz Lanman — CEO, ClassPass & Mindbody · Gildre Member
What Does "Scalable" Actually Mean for an Early-Stage Product?
Scaling is a word that gets used loosely. In product terms, it means something specific: your product maintains its efficiency, reliability, and user value as demand grows. More users, more transactions, more data — none of it should degrade the experience or require a complete rebuild to accommodate.
That definition has three practical dimensions.
Infrastructure
A backend that handles load without cracking
Servers, databases, and networks that can absorb increased traffic and data volume without performance degradation. For products with global ambitions, this means distributed infrastructure with regional nodes, load balancing to spread traffic evenly, and auto-scaling policies that add capacity before users feel the ceiling. ClassPass's ability to expand into new cities without rebuilding its backend each time was a direct result of infrastructure decisions made before that growth started.
Architecture
A codebase that can evolve without collapsing
Modular design and well-documented APIs allow new features and third-party integrations to be added without breaking existing functionality. Microservices architecture — where discrete parts of the product run as independent services — is particularly effective for scaling because failures in one area don't cascade across the system, and teams can deploy updates to individual services without coordinating full-stack releases.
Operations
Processes that scale with the team, not against it
As the product grows, so do the teams building it. Operational processes — development workflows, QA processes, deployment pipelines, communication structures — need to stay lean and clear even as headcount increases. Agile methodologies, automated testing, and continuous integration pipelines exist precisely to prevent the operational overhead of growth from eating the speed advantage that made a startup fast in the first place.
The ClassPass pattern
When ClassPass entered a new city, it wasn't rebuilding the product — it was extending a system already designed to accommodate new partners, new markets, and new inventory types. That's what scalable architecture looks like in practice: the hard engineering work is done upfront so that growth becomes a configuration change, not an engineering project.
How Should Founders Use the MVP Approach to Build for Scale?
Key Takeaway
A Minimum Viable Product should test your single riskiest assumption, not showcase your full product vision. The goal is to generate real behavioral data from real users on the smallest possible build — not to demonstrate how much you've built or how complete the product feels.
A Minimum Viable Product is not a stripped-down version of your full vision. It's a deliberately scoped version of the core value proposition — the smallest thing you can build that lets a real user solve a real problem. The goal isn't to launch something cheap. It's to learn before you build things that don't matter.
The MVP discipline is what separates founders who scale from founders who rebuild. When you know exactly what your users value — because you watched them use a minimal version of it — you invest your engineering resources in the right places. Here's how to run an MVP process that produces real signal:
Define the core value, not the full feature set
Start with the primary problem. What is the one thing your product does that users can't easily do otherwise? Strip everything else. The features that feel essential at the whiteboard stage are often the ones nobody misses in the first week of actual use.
Build something tangible, not theoretical
Whether it's a working prototype, a clickable mockup, or a manually-operated service that appears automated, the goal is something users can actually interact with. Feedback on a concept is opinion. Feedback on a real interaction is data.
Launch to a small, honest group
Early adopters who will tell you what doesn't work are more valuable than enthusiastic supporters who won't. Release to a group willing to be critical — early customers, a founder community, or a niche audience where your product either solves the problem or clearly doesn't.
Gather feedback on behavior, not just opinion
Watch how people actually use the product, not just what they say about it. Usage patterns, drop-off points, and which features get ignored tell you more than survey responses. Qualitative interviews add the "why" behind the behavioral data.
Iterate on the signal, ignore the noise
Not all feedback deserves a feature. The signal is feedback that appears repeatedly, from multiple users with similar contexts. A single user's preference is not a roadmap item. A pattern across ten users is.
Track the metrics that measure the core value
Define success metrics before you launch, not after. Engagement rate, retention at Day 7 and Day 30, time-to-value for new users — whatever measures whether the core problem is actually being solved. Vanity metrics (signups, page views) tell you about marketing. Retention tells you about product.
Pivot when the data says to, not when pride says not to
The hardest MVP lesson is that a negative result is still a result. If users aren't retaining, the product isn't solving the problem — and the answer is to change something meaningful, not to acquire more users into a leaky bucket.
What Is Customer-Centric Design and Why Does It Drive Long-Term Scale?
Key Takeaway
The most durable competitive advantage in product is a deep, accurate understanding of the specific job your best customers hire your product to do. Build for that job first, resist feature expansion until the core experience is bulletproof, and let everything else follow from there.
Scalable architecture gets you the capacity to grow. Customer-centric design is what gives you the reason to. The products that achieve long-term scale aren't just technically capable of handling more users — they become more valuable as they grow because they were designed around real human needs from the start.
Start with the user's job to be done
Users don't buy products — they hire them to do something. ClassPass wasn't hired because users wanted a fitness membership; it was hired because they wanted variety and flexibility without commitment. Understanding the job precisely determines what you build, what you deprioritize, and what "done" looks like for your user.
Build feedback loops into the product itself
The best products are designed to surface user signal continuously — through NPS prompts, usage analytics, in-app feedback mechanisms, and structured customer interviews. Don't treat user research as a phase. Treat it as an ongoing function of the product team.
Reduce time-to-value relentlessly
The fastest path from signup to the moment a user experiences the product's core value is one of the most important metrics you can optimize. Onboarding friction, mandatory profile completion, and delayed "aha moments" all reduce retention before users even decide whether they like the product.
Design for the 80%, not the power user
Power users are vocal and their feedback is easy to act on. But most users will never use advanced features. Scalable products optimize the core experience for the majority use case, and surface advanced functionality without cluttering the path for users who just need the basics.
The compounding advantage
When infrastructure, MVP discipline, and customer-centric design work together, the result compounds: you build faster because you're building less, you iterate better because your feedback loops are tight, and you scale without rebuilding because the architecture was designed to accommodate growth from the start. This is how ClassPass expanded from one city to a global platform — not through brute-force engineering effort, but through early decisions that made each subsequent expansion cheaper and faster.
How Can Peer Founders Help You Make Better Product Decisions?
Principles for building scalable products are widely available. What's harder to find is judgment — the ability to apply those principles to your specific situation, market, and team. That kind of judgment comes from people who've made the decisions before you.
Fritz Lanman is part of the Gildre community precisely because of what he can offer founders working through these questions: not just what ClassPass did, but why, and what he would do differently. The same is true of the other seasoned operators and executives in the Gildre network — founders who've navigated the transition from early product to scaled platform and can tell you where the standard advice breaks down.
Frequently Asked Questions
What makes a product scalable?
A scalable product has three properties: infrastructure that handles increased load without performance degradation (horizontal scaling, caching, database optimization), a modular architecture that accommodates new features and integrations without full rebuilds, and operational processes that stay efficient as the team grows. All three are design decisions made early — not retrofits applied after growth reveals the problem.
What is an MVP in startup product development?
A Minimum Viable Product (MVP) is the smallest version of a product that delivers enough value for real users to experience its core proposition. The goal is not to build the cheapest version of your full vision — it is to generate real behavioral data from real users that validates or invalidates your key assumptions before you invest further. An MVP that nobody uses is not an MVP; it is a prototype.
What is customer-centric product design?
Customer-centric product design means building around the specific job your best customers hire your product to do, rather than around roadmap completeness or feature parity with competitors. It requires continuous feedback loops, relentless optimization of time-to-value for new users, and prioritizing the core use case for the majority before adding power-user functionality.
How did ClassPass scale its product?
ClassPass, led by CEO Fritz Lanman, scaled by investing in a robust, modular backend architecture early rather than building fast and refactoring later. This allowed the platform to onboard new fitness partners, expand into new markets, and introduce new inventory types (gym access, spa, beauty services) without requiring full rebuilds — a key enabler of the company's global expansion and $285M Series E.
What is the biggest product mistake early-stage founders make?
The most common mistake is building features instead of validating assumptions. Founders frequently build what they think users want rather than what behavioral data shows users actually need. The result is a product with many features and low retention — a sign that the core job-to-be-done was never clearly identified. Delay any feature beyond your core value proposition until at least 50–100 users demonstrate consistent, unprompted return usage.
Gildre Founder Community
Get product judgment from founders who've scaled.
The Gildre community includes operators like Fritz Lanman who have built products from zero to global scale. When you're making the decisions that determine whether your product can grow, that's the room to be in.
Join Gildre →