Lessons and practices learned in driving Logto’s growth with developers.
Logto is an open-source, developer-focused product. Here’s our go-to-market timeline:
Coming from a background in product-led growth for productivity tools, the teams and I tried different go-to-market strategies for Logto. After two years, I’ve reflected on those efforts and the steps we took. I want to share part of that journey and explain why some things didn’t work at the time. These aren’t “mistakes,” but valuable lessons from our experience. I hope these insights help others working on similar projects or startups.
When you first launch your product, especially with a product growth mindset or some experience, it’s easy to think of all sorts of exciting ideas: fancy onboarding flows, a great demo on the website, cool ways to highlight value to users, and getting them to the “ah-ha” moment quickly. To make our product look polished and ready for commercialization, I implemented two activation strategies:
These strategies had been very successful in my past experience. So when Logto launched its cloud-hosted version, I applied them immediately. However, I encountered some confusion and challenges:
For developer products, it’s difficult to solve a problem in a short time even if it can be truly self-serve. Even for a single developer, the process involves several stages: integrating with the right tech stack, creating a proof of concept, testing in a development environment, and then moving to production. At any point in this journey, users can drop off. The "job-to-be-done" isn’t a simple, one-step task. Developer needs are often complex, requiring a range of features or technical scenarios that need thoughtful design leveraging our existing capabilities. Solving such problems takes time and can’t be rushed.
Looking back, it’s clear why this approach didn’t succeed. When we first launched, our daily sign-ups and organic traffic were quite low. Most of our traffic came from the open-source community, which naturally didn’t bring in larger clients. It’s no surprise we didn’t see bigger clients booking calls during this stage. The low traffic and the source of our users made it unrealistic to expect significant call bookings early on.
Choose the model that fits your product, based on the time needed for user activation. Don’t let industry norms restrict you.
When building a SaaS product, one of the key go-to-market (GTM) questions is whether to choose freemium or a free trial. Common wisdom suggests:
We initially chose a freemium model for a quick launch, placing a hard paywall between the free and paid plans. However, developers couldn’t access advanced features like SSO or Organization in the free tier.
While there’s plenty of debate online about which model is better, it’s crucial to step back and consider your product’s activation timeline. For Logto, we’ve observed that in real world, the testing phase can last up to 6 months. This isn’t due to complexity of Logto but rather the engineer’s work schedule, project planning, team workflows, and other factors we hadn’t anticipated.
Given this long activation period, it’s important to provide developers full access to all features for testing. That’s why we fully utilize the development tenant to unlock the product’s full capabilities. This is common practice for developer tools but worth noting as it explains why traditional freemium or free trial strategies may not work for us.
The choice should align with the nature of your product and its adoption timeline. Understand your product’s unique characteristics, and choose a model that fits—not one that pushes users too quickly through your conversion funnel.
Executing a GTM with a bottom-up strategy often involves SEO, product marketing, and content marketing. We all know it’s important to start early, so we began creating content right after launching the open-source version. But when we first decided to write articles, I had a big question: What should I write?
As a product designer, my instinct was to write about why we designed certain features, explaining the thought process and philosophy behind them.
"In this article, we'll go over the history of Sign-in Experience, including its conception, design decisions, and product tradeoffs. You will also gain a better grasp of how to construct a successful and frictionless sign-in or sign-up experience." - Our blog post 2 years ago The design considerations for a seamless sign-in experience (First Chapter)
I was eager to share my thoughts on our features and design because I put so much effort into them. But looking back, I realize this is what you'd call "self-absorbed" content. It's common in well-established companies with a strong EPD (Engineering, Product, Design) culture.
If you’re doing product-led growth (PLG), especially when your product hasn’t yet reached the stage where "people are talking about you," it’s necessary to ensure your content has clear value and a goal for your audience. Avoid being too self-focused.
For instance, instead of focusing on why a feature was designed, create educational articles that explain specific terms, or tutorials that show how to integrate a cool technology or tool to solve a common technical issue.
As you learn more about your product and customers, you’ll naturally develop strong opinions about what really matters to your audience. Keeping a “customer-centric” approach will help you improve content quality. Over time, you’ll be able to write content that resonates with your audience. Otherwise, your content risks feeling self-absorbed.
Traditional marketing often emphasizes “best practices” or “solutions” when selling to businesses or individuals, based on the idea that SaaS products primarily drive efficiency and productivity. Many strategies focus on numbers, showing financial savings to highlight benefits. While this can work well for mature companies with a broad customer base, it can be off-putting for developers.
Two years ago, I focused heavily on building value propositions and crafting a big-picture narrative for our product. However, this approach didn’t always connect with the developer audience.
Look at the webpage we had 2 years ago—"Shaping the future"… Wow!
When it comes to satisfying developers and solving their problems, you need to be very practical and grounded. Developers aren’t swayed by lofty benefits; they care about feature availability and flexibility—specifically, how easily your product can integrate into their existing tech stack. If it can’t, don’t try to sell it.
Now, our content strategy is much more focused. We highlight the specific features we deliver, allowing users to quickly understand what we offer from the first screen, without relying on buzzwords or high-level messages.
When we first launched our hosted commercial version, there was always a heated discussion within the team: Would open-source hurt our hosted version since it's free, and our target audience is developers? We also debated whether to limit some of our advanced features in the open-source version.
So far, we've kept the core features of both the open-source and hosted versions almost the same. The growth of our open-source community has built significant trust with enterprise leads, and more larger businesses are coming onboard. Interestingly, some of these enterprises started out as developers in our community. This has given us a lot of confidence. As long as we continue to build great products, provide excellent services, and help developers solve their problems, whether it's through self-serve growth or direct enterprise sales, success will come naturally.
In the end, it’s all about solving developer problems, whether through product or service. Stay patient and focused, and everything will fall into place naturally.
Thanks for reading, and feel free to share your experiences and thoughts if you’re working on something similar!