Levels doing things that don't scale

In the world of tech startups, conventional wisdom suggests that to build a successful platform serving millions of users, you need sophisticated infrastructure: databases, APIs, servers, and a team of engineers to maintain it all. But what if you could bypass all of that complexity and still build something that scales? This is exactly what Zuhayeer Musa and Zaheer Mohiuddin did with Levels.fyi, creating a platform that would eventually serve 1-2 million monthly users using nothing more than Google Sheets as their database.

The Origin Story: A Problem of Career Transparency

The story of Levels.fyi begins in 2017 when Zaheer Mohiuddin was transitioning from his job at LinkedIn to a new role at Amazon. During this process, he encountered a frustrating problem: the lack of transparency around career levels and compensation across different tech companies. Each company had its own leveling system, making it difficult to compare positions and ensure fair compensation.

Mohiuddin shared this frustration with his friend Zuhayeer Musa, whom he had met through a mutual connection. The two had similar-sounding names and shared an interest in side projects. They recognized that this lack of transparency was a widespread issue in the tech industry, affecting countless professionals trying to navigate their careers and negotiate fair compensation.

“Our vision was to help professionals get paid, not played,” the founders would later explain. They wanted to create a resource that would demystify the opaque world of tech compensation and career progression, empowering individuals with the information they needed to make informed career decisions.

The Minimum Viable Product: Google Forms and Sheets

Instead of immediately diving into building a complex platform with a traditional backend, Musa and Mohiuddin took an unconventional approach. They created a simple system using tools that were readily available and required minimal technical setup: Google Forms and Google Sheets.

Their initial version was remarkably basic. They set up a Google Form where users could submit information about their job titles, levels, and compensation. This data would automatically feed into a Google Sheet, which served as their makeshift database. The frontend was a simple static website that displayed the information from the Google Sheet.

This approach allowed them to launch quickly and focus on validating their concept rather than getting bogged down in technical implementation details. It was the epitome of the startup mantra “do things that don’t scale” – they chose a solution that was quick to implement and good enough to test their hypothesis, even though it wouldn’t be sustainable in the long run.

“It seems like a pretty counterintuitive idea for a site with our traffic volume to not have a backend or any fancy infrastructure,” the founders would later write on their blog, “but our philosophy to building products has always been, start simple and iterate. This allows us to move fast and focus on what’s important.”

The Architecture: Building Without a Backend

As Levels.fyi began to gain traction, the founders refined their approach while still avoiding the complexity of a traditional backend. Their architecture evolved to include:

1. Google Forms: Serving as the user interface for data collection
2. Google Sheets: Acting as their database for storing all submitted information
3. AWS Lambda: Processing data from Google Sheets and creating JSON files
4. AWS API Gateway: Providing endpoints for their frontend to access data
5. AWS S3: Storing the processed JSON files
6. AWS CloudFront: Caching the JSON files to improve performance

This serverless architecture allowed them to handle increasing traffic without managing servers or databases. When a user submitted information through their form, it would be stored in Google Sheets. AWS Lambda functions would periodically process this data, creating JSON files that were stored on S3 and cached through CloudFront.

The frontend would download these JSON files on initial page load, and all further processing would happen in the user’s browser. This approach shifted the computational burden from their servers to the users’ devices, allowing them to scale without proportionally increasing their infrastructure costs.

The Growth Phase: Coffee Shops and Bootstrapping

While building Levels.fyi, Musa and Mohiuddin maintained their day jobs, working on the platform during evenings and weekends. They would often meet in coffee shops around the Bay Area, coding and strategizing how to grow their platform.

Their growth strategy was as scrappy as their technical approach. Instead of spending money on marketing, they focused on creating valuable content that would naturally attract their target audience. They wrote articles about compensation trends, created visualizations of career ladders at different companies, and engaged with tech communities on platforms like Reddit and Hacker News.

Word of mouth became their most powerful growth driver. As tech professionals found value in the platform, they would share it with colleagues, especially during job transitions or salary negotiations. The site became particularly popular during performance review seasons when employees were evaluating their compensation relative to the market.

The founders also leveraged their personal networks, reaching out to friends and former colleagues at major tech companies to contribute data and spread the word. This grassroots approach allowed them to build a critical mass of data, which in turn attracted more users.

The Challenges: Scaling Without a Traditional Backend

As Levels.fyi grew from hundreds to thousands to millions of users, their unconventional architecture began to show its limitations. Some of the challenges they faced included:

1. Data Size: The JSON files grew to several megabytes, creating a significant penalty for users on initial page load or cache misses.
2. Processing Time: Their Lambda functions started timing out due to the amount of data that needed to be processed in a single execution.
3. Analysis Limitations: Without a SQL database, they lacked robust tools for data analysis, making it difficult to derive insights from their growing dataset.
4. API Rate Limiting: Google Sheets has strict rate limits for its API, which became problematic as their write operations scaled.
5. Data Security: With all their data downloaded as JSON files, it was relatively easy for competitors to scrape and plagiarize their content.

Despite these challenges, the founders maintained their approach for over two years, serving millions of users with what was essentially a spreadsheet-based backend. This allowed them to focus on building their user base and refining their product without the distraction of managing complex infrastructure.

The Evolution: Gradual Migration to a Traditional Backend

Eventually, the limitations of their Google Sheets-based architecture became too significant to ignore. Rather than attempting a risky “big bang” migration, the founders took a gradual approach to transitioning to a more traditional backend:

1. Duplicating Writes: They began by duplicating all write operations to both Google Sheets and their new database, ensuring they could maintain their existing functionality while building out the new system.
2. Splitting JSON Files: They broke their large JSON files into smaller chunks and gradually replaced each chunk with a new API endpoint.
3. Migrating Read and Write Paths: Over time, they moved all read and write operations from their Google Sheets-based system to their new API-based architecture.

This careful, incremental approach allowed them to maintain service continuity while addressing the limitations of their initial architecture. By January 2024, they had fully migrated to a Postgres database, though they continued to use Google Sheets for various operational tasks.

The Philosophy: Avoiding Premature Optimization

Throughout their journey, Musa and Mohiuddin were guided by a simple philosophy: avoid premature optimization. They recognized that many startups fail not because their technology isn’t sophisticated enough, but because they don’t focus enough on validating their idea and building something people want.

“Our philosophy to scaling is simple, avoiding premature optimization,” they explained. Even after transitioning to a more traditional backend, they maintained this approach, noting that “one of our most trafficked services today still has a single node.js instance serving 60K requests per hour.”

This philosophy allowed them to allocate their limited resources (time, money, and attention) to the areas that would drive the most value for their users. Instead of spending months building a sophisticated backend before launching, they were able to get their product in front of users quickly, gather feedback, and iterate based on real-world usage.

The Impact: Democratizing Compensation Information

The impact of Levels.fyi has been profound. By providing transparency around career levels and compensation, they’ve helped countless professionals negotiate better salaries and make more informed career decisions. The platform has become a go-to resource for tech workers, particularly during job transitions and salary negotiations.

Beyond individual impact, Levels.fyi has contributed to broader industry changes. As compensation data has become more transparent, companies have been forced to address inequities and ensure their compensation packages are competitive. This has led to a more level playing field for tech workers, particularly those from underrepresented groups who historically have had less access to compensation information.

The Lessons: What We Can Learn from Levels.fyi

The Levels.fyi story offers several valuable lessons for entrepreneurs:

1. Start Simple: Instead of building a complex system from the beginning, start with the simplest solution that can validate your idea.
2. Focus on Product/Market Fit: Use readily available tools to quickly test your hypothesis and iterate based on user feedback.
3. Leverage Existing Tools: Tools like Google Forms and Sheets, combined with serverless architecture, can take you surprisingly far without the need for custom infrastructure.
4. Gradual Evolution: As you grow, evolve your architecture incrementally rather than attempting risky complete rewrites.
5. Avoid Premature Optimization: Don’t optimize for scale until you’ve validated that your product is worth scaling.
6. Resourcefulness Over Resources: With creativity and resourcefulness, you can accomplish a lot with limited resources.

The Legacy: A New Model for Startup Development

Today, Levels.fyi stands as a testament to the power of starting simple and focusing on user value over technical sophistication. While they’ve since evolved to a more traditional architecture to support their continued growth, their journey demonstrates that you don’t need a complex backend or significant infrastructure investment to build a product that serves millions of users.

Their approach has inspired other entrepreneurs to question conventional wisdom about what’s required to launch a successful tech platform. By showing that a Google Sheet can serve as a database for a platform with millions of users, they’ve lowered the perceived barriers to entry for aspiring founders.

In an industry often obsessed with cutting-edge technology and sophisticated architecture, Levels.fyi reminds us that the most important thing is building something people want. Sometimes, the most innovative approach isn’t using the latest technology, but finding creative ways to use simple, existing tools to solve real problems.

As Musa and Mohiuddin continue to grow Levels.fyi, they carry forward the lessons from their unconventional beginning: start simple, focus on user value, and only add complexity when absolutely necessary. It’s a philosophy that has served them well, taking them from a Google Sheet to a platform that’s changing how the tech industry thinks about compensation and career progression.