Building a mobile SDK and expanding it into an 8-figure-ARR
portfolio
Jonathan Rhyne grew an audience, then found a compelling problem within his niche — a problem he and his cofounders solved with the first-ever SDK for viewing and annotating PDFs on mobile.
It gained immediate traction and continued to grow over the course of eight years. Then, he got acqui-hired and his ARR quadrupled. Now, Nutrient is bringing in high tens of millions per year.
Here's Jonathan on how he got here. 👇
From computer science to law to startups
I started as a technologist and computer enthusiast at a very young age, with an interest in computer games. This led me to begin my undergraduate studies in computer science, and I quickly decided I wasn't interested in sitting behind a computer all day by myself, solving puzzles. I wanted to do something more people-facing, requiring soft and social skills.
I pivoted to law school, graduated, and practiced law around the financial crash in 2008-2009. It was a tough time to find a job, so I decided to start my own practice, giving financial advice to software engineers and, especially, indie software developers as the iOS SDK launched and the mobile revolution began.
I made a name for myself as the "iPhone Attorney Guy" in North America before I met my cofounder and business partner, Peter Steinberger, at a conference called NSConf. From there, I joined PS PDF Kit, an iOS SDK that aimed to solve the problem of putting magazine apps on iPhone. We continued to scale, building SDKs on Android and ultimately for the web, primarily around PDF viewing and document processing.
We scaled this company for seven years, bootstrapping it until 2021 when a VC private equity firm called Insight Partners acquired us. At that point, I continued to scale the company, now known as Nutrient.io.
We are in the high tens of millions in ARR and scaling sustainably. We quadrupled our ARR in the past four years.
Finding the team
I was motivated by the idea of working remotely with people from around the world who were highly motivated to innovate and change the status quo of software and technology.
The legal industry is not the most innovative or progressive industry. As an attorney, I dealt with digital documents constantly, encountering many frustrations and pains. I kept asking myself, "Personal computing changed so much with the introduction of mobile phones and the iPhone, why are we still using the same digital-document formats from the 1990s and early 2000s?"
When I met Peter and Martin, I found two very technical cofounders who were highly motivated and had very high standards for their work product. The mix of great technical cofounders in Europe with my background in technology in the US, combined with my soft skills and business acumen, created a great match and produced great results.
Getting lucky
We were lucky to stumble upon the initial product.
Peter originally received a contract to consult while he waited to go to California to work for a startup in Silicon Valley. The contract involved putting a magazine app on an iPhone. No one from the digital document space thought mobile would be a thing. Consequently, no frameworks or tools were available for developers to handle what seemed like a simple problem.
We built UI and ported Apple's PDFKit from macOS, which was not yet available on iOS. We ultimately shipped the original SDK that helped people view, annotate, and fill out forms with PDFs.
I say we got lucky because we immediately solved a very pressing need on iOS. Many large companies were investing in mobile, facing a problem not easily solved or addressed by open source. From day one, we had demand. And, as Peter and I were both from the iOS space, we had brand recognition within the tight-knit iOS community of indie developers.
A three-pronged business model
At Nutrient, we aim to evolve how humans interact with and experience documents. We are currently working on developer tools like our SDKs that process documents for tasks like:
Conversion of document file types
Document generation
Document understanding
Document viewing
Signing
Form filling
All these help businesses replace paper, drive digital transformation, and evolve the digital document experience. We have three business lines:
SDKs and Cloud APIs built specifically for software engineers to integrate and build upon when their applications have document-related needs or functionality.
Marketplace integrations for SharePoint and Salesforce, addressing document needs like signing, data extraction, conversion, and generation, which the platforms themselves underserve, despite many businesses building their document workflows on these platforms.
Our own workflow automation platform for document-centric business processes for enterprises with complex workflows requiring high compliance, auditability, and security.
For most of our products, we use a bespoke sales-led motion. We employ this approach because we sell to enterprises including IBM, the US government, and many well-known tech companies, as well as startups, small mid-market companies, etc. The product's value varies based on how customers use it, the scale of its use, and its importance to their operations.
We grow our revenue by selling more products to these larger enterprises and upper mid-market companies because their needs span multiple product lines, and they often prefer one vendor to handle all their document-related needs.
An extensive tech stack
As a developer-tools company, we use a large number of languages and frameworks. The real question is, "What isn't part of our tech stack?"
We primarily use Linux and macOS. At the core of our SDKs, we have a C++ monorepo renderer and a C#/.NET image, PDF parser, and OCR engine. On mobile, we integrate that monorepo using Objective-C, Swift, and SwiftUI for iOS, and Java and Kotlin on Android. We also use hybrid frameworks like Flutter (Dart) and React Native.
On the web, we primarily work in JavaScript, React, and TypeScript, but we also support integrations with many other JavaScript frameworks. We offer both a standalone client-side Wasm Web SDK and an Elixir server and microservice deployment for server-based rendering and document processing. Our workflow automation platform primarily uses JavaScript.
We recently migrated our Marketing and Documentation websites to Astro. We built our internal licensing, invoicing, and metrics application in Ruby.
Word of mouth
In the early days, we attracted users by contributing to their communities.
That meant doing open source. And it meant writing content, especially when we found something useful for other iOS developers. Then, we showed the product to them. But crucially, we allowed them to find it valuable, rather than just telling them its value.
As we've scaled, those users have told their stories, sharing the product's value in their own words, and that has helped a lot. Users can articulate its value in a way that resonates more with other users than if it comes directly from the business.
Now, we attract businesses through paid advertising, partners, system integrators, and conferences. But in the early days, and what still drives most of our top-of-funnel, is word-of-mouth referrals and organic traffic.
Maintaining culture while scaling
I've been doing this for twelve years, and I've faced significant challenges at every stage. But the biggest obstacle I've overcome was probably our most recent scaling effort since 2021, when an investor joined.
As we grew, we started hiring outside managers from different organizations with varied growth paths and processes. Maintaining the culture that built the company while allowing it evolve while scaling from 3 to 15, 50, and then 170 people was challenging.
I found that staying in the weeds was crucial. I try to remain as close as possible to the customer's pains and experience, and to the product from onboarding through usage. But that becomes even more difficult as you grow and management responsibilities increase. You get a false sense of not needing to be in the weeds.
People management also became harder. When you're smaller, it's easier to know who performs well, who is committed, and who isn't. It's also clear who doesn't align with your culture.
You have to understand that:
Some people will outgrow your organization and move to larger ones, which is both okay and beneficial.
Some people don't grow enough or fast enough with the organization, and while it feels bad, that's also okay and normal. Dealing with this emotionally as a founder is extremely taxing.
Set expectations with your team
I've found that humans, especially those you manage, want certainty. They want clarity on expectations — what leads to success and what leads to failure within the organization. When scaling, the tendency is to avoid stating expectations due to fear of disagreements, departures, or being perceived negatively.
This ultimately leads to withholding information and poor communication, resulting in big surprises and worse outcomes. I've found it's much better to clarify your expectations. That allows people to self-select out, ideally as soon as possible, allowing you to quickly identify colleagues aligned with the organization's expectations.
The shoulders of giants
I've found reading and learning from others who have faced similar situations particularly helpful. Here are a few examples that have stuck with me:
Jeff Bezos, in an early Amazon annual shareholder report, discusses type one and type two decisions: reversible and irreversible. He explains that as an organization scales, it tends to apply the same system used for irreversible decisions — involving stakeholders, planning, and meetings — to reversible decisions. This ultimately leads to slowness and a lack of innovation.
Steve Jobs, upon returning to Apple, learned to take a longer viewpoint with his colleagues. In the early days, if he saw a problem, he immediately fixed it. He learned that sometimes, you need to create a system where colleagues learn the problems on their own, rather than immediately solving them.
Snowflake's former CEO emphasizes managers' need to constantly push urgency. He explains that without managers pushing urgency, groups naturally become as slow and dysfunctional as the DMV. He also points out that constantly pushing urgency every day is emotionally taxing, but it's the only way to compete and advance at the necessary pace in a highly competitive market.
Get thirsty for critical feedback
Here's my advice:
Don't get caught up in the argument about whether product is more important than distribution. Both are equally important, and unfortunately, great distribution of a good enough product almost always succeeds more than okay distribution of a great product. That said, most software engineers I've met, when they hit a distribution issue, double down on feature development and building because it's what they know.
Fight confirmation bias. Over the past twelve years, starting from 'I don't know' has helped me most. This is very hard when you truly believe you know. But it means that you search, not to validate what you think you know, but to invalidate it. You become very thirsty for negative, critical feedback. You view this negative, critical feedback as a gift because it's the feedback loop that helps you improve. The faster you get this feedback, the faster you can act on it and improve, moving closer to success.
Talk to your prospective customers, learn their pains, learn the real problem behind what they tell you. Then, care enough about the details of solving it to wow them with small things. A great product is not one grand feature or thing that blows people away. It's almost always a bunch of tiny moments of joy along the way.
Learn to be okay with risk. Stop looking at risk through the lens of probability of outcomes. Start looking at risk through the lens of cost versus potential upside. Look for asymmetrical upside, and you'll find the risks you should love taking.
Lastly, don't be afraid to fail. Failing is just the road to success. The sooner you view failure as a learning opportunity, the sooner you advance on the road to success. Luck is involved, but it typically only presents itself to those who put in the effort. Effort doesn't guarantee success, but if you do not put in the effort, you have no chance of success.
What's next?
Documents have been one of the most crucial tools in humanity's story. We record history with them. We formalize agreements between each other with them. We tell our stories, express our ideas, and communicate through them.
We have a horse in the race to change how humans utilize and interact with documents.
Since the dawn of recorded history, documents have been present during the largest leaps in progress, and advancing documents and empowering more individuals to utilize them in more powerful ways have often preceded those leaps. We are in a lull in document technology advancement, but we are at a very exciting point.
If I had a goal, it would be to be part of the revolution coming to document technology. I don't need to be the hero, but playing a role in progressing such a transformational tool for humanity and helping it advance for future generations would be a meaningful use of my time on Earth.
You can follow me on X and LinkedIn. Or learn more at Nutrient.io:
Leave a Comment
The point about great distribution of a good enough product beating okay distribution of a great product is something I needed to hear. I've been guilty of exactly what you described — hitting a distribution wall and going back to tweaking features instead of figuring out how to get the product in front of people. The advice about getting thirsty for critical feedback is also powerful. It's so tempting to focus on the few people who say nice things about what you've built and ignore the silence from everyone else. The silence is the feedback. How did you balance open source contributions and community building in the early days with actually monetizing? That transition from giving value for free to asking people to pay seems like a tricky line to walk.
I'm currently building a tool that finds SaaS ideas from real user complaints. Seeing how people validate ideas is really helpful.
Developer tools with deep SDK integration are one of the most defensible product categories in software, and PSPDFKit is a textbook example of why. Once engineers integrate a PDF SDK into their codebase — touching file handling, rendering pipeline, annotation data models, and UI components — the cost of replacing it is measured in months of engineering time, not days. Jonathan and Peter didn't just build a PDF library; they built a switching cost that made their customers structurally reluctant to leave even if a competitor appeared.
Being first-ever for mobile PDF viewing in 2009 gave them the initial adoption wave, but the real moat was the depth of integration compounding over years. Enterprises that built PSPDFKit into document management workflows in 2011 were still customers a decade later.
The "iPhone Attorney Guy" positioning is the underrated part of this story. Jonathan built an audience of iOS indie developers — the exact people who would be early adopters of developer tools — before he joined PSPDFKit. That audience gave him credibility and distribution within the iOS developer community when the SDK launched. It's a distribution-first origin story for a B2D (business-to-developer) product.
The 7-year bootstrapped run before the Insight Partners acquisition also matters: when PE acquires a proven, profitable developer tools company, they're not buying a growth bet — they're buying a cash-flowing asset with a proven market and adding sales and enterprise go-to-market infrastructure on top. The ARR quadrupling post-acquisition is the expected result of that playbook applied to a genuinely strong product.
Congrats on the Nutrient milestone — the rebranding signals the continued platform expansion beyond mobile.
What stood out to me is how the opportunity appeared from proximity to pain.
A lawyer constantly dealing with documents meets a developer trying to ship a magazine app on early iOS — and suddenly they hit a problem the entire ecosystem had but nobody had solved yet.
It also feels like a classic dev-tools pattern: start with one painful infrastructure problem (PDF handling), then expand once you become part of companies’ workflows.
Curious: when the SDK started gaining traction, did you already imagine expanding into a broader document platform, or did that emerge later from customer requests?
Hey!
I noticed your checkout flow doesn't have a 'Save' logic. I'm building a tool that automates this for an 11% performance fee. Want to be our first Beta tester?"
The "tiny moments of joy" line is the most underrated advice in this post. Most product decisions happen at the feature level, but what actually builds loyalty in developer tools is operational excellence at the detail level. Documentation that anticipates your next question. Error messages that tell you what to do, not just what went wrong. APIs that behave exactly as expected without edge case surprises.
The point about engineers defaulting to building more features when distribution stalls is also painfully accurate. It's the path of least resistance because it feels like progress. Talking to customers and confronting why they're not converting is harder and less comfortable.
What strikes me most about this story is the eight-year timeline. The SDK had demand from day one, but the 8-figure ARR took a decade. That gap is where most people quit.
The trajectory from "solving a simple problem nobody else was tackling" to 8-figure ARR is a masterclass in developer tool building. What stands out to me is how PSPDFKit (now Nutrient) found a gap that established players had completely overlooked - mobile PDF handling. That's exactly how the best dev tools get started: not by competing head-on with incumbents, but by finding the blind spot.
I'm building in the developer tools space too (codebase intelligence for engineering teams), and the insight about brand recognition within a tight-knit developer community really resonated. In dev tools, your first 100 users aren't just customers - they're evangelists who'll either make or break your word-of-mouth. We've found that developers who genuinely love your tool will talk about it in ways that no marketing budget can replicate.
The three-pronged business model (SDKs, marketplace integrations, and low-code tools) is also a smart expansion strategy. Starting with one core product for developers and then expanding into adjacent use cases seems to be the pattern that works best for dev tool companies. You build deep technical credibility first, then leverage that trust to expand.
The acqui-hire story is interesting too. Curious if the acquisition fundamentally changed the product roadmap, or if the original vision stayed mostly intact?
Nice expansion strategy. When you were under $5k MRR, what channel actually brought the first consistent paying customers?
The audience first then product approach is something I wish someone told me 7 years back when I started.
We been building mobile apps for clients all this time and honestly the SDK idea is fascinating. Jonathan basically solved same problem hundreds of apps needed and packaged it once. We solve same problem hundred times for hundred different clients 😄
The 8 year timeline is also very real. Everyone wants overnight success story but most solid businesses are just boring consistent execution for years.
Your long run at Indie Hackers really shows in how clearly you distill founders wins and failures into practical lessons. I recently adapted a traditional blessing for a family birthday and it felt sincere. Even when sharing birthday wishes for husband from here birthdaywishesmarathi .net, weaving in one specific memory or quality, much like a founder story, makes the message more grounded and meaningful.
This is an incredibly insightful and inspiring case study. The journey from solving a real, under‑served problem in mobile document processing to building an eight‑figure ARR business shows the power of focusing on genuine user pain, consistent execution, and long‑term vision. The balance between product quality and distribution, the emphasis on community‑driven growth, and the lessons on scaling culture while staying close to customers are especially valuable for anyone building developer tools or SaaS products. Thank you for sharing such a detailed and honest story. It’s a great reminder that sustainable success comes from solving real problems, embracing critical feedback, and iterating steadily over time.
As someone building a mobile app, it's so tempting to keep perfecting features instead of spending that time on distribution. The community-first growth through open source contributions and technical content is something I want to experiment with more.
The transition from Law to 'iPhone Attorney Guy' to scaling Nutrient is such a fascinating trajectory. It’s a great reminder that 'soft skills' and domain expertise (like legal document pain points) are often the missing ingredients in purely technical teams. That 'three-pronged' business model is a masterclass in extracting maximum value from a core engine. Thanks for sharing the breakdown!
This one is a great reminder that many of the biggest companies in tech don’t start with an “app idea” — they start with infrastructure nobody notices but everybody depends on.
What I found most interesting is how the opportunity appeared: not from brainstorming, but from proximity to pain. A lawyer constantly dealing with digital documents meets a developer trying to ship a magazine app on early iOS… and suddenly they hit a problem the entire mobile ecosystem had but no tools existed to solve. They didn’t invent a market — they arrived right when the platform shift (mobile) created a missing layer. That’s why the SDK had demand from day one.
There’s also a subtle lesson here about developer tools: distribution looks different. Instead of ads or growth hacks, they earned adoption through community contribution — open source, documentation, and helping developers first. Developers don’t buy because of marketing copy; they buy because something saves them weeks of work and removes risk.
The 3-pronged model is clever too. Starting with an SDK gave them a wedge, but the real scale came from expanding outward: APIs → integrations → full workflow platform. Basically, once you become part of a company’s document infrastructure, switching costs grow naturally and you stop selling a tool — you start becoming a system.
And the advice on feedback really hit: engineers often respond to distribution problems by building more features. But enterprise products win by understanding workflow, reliability, and trust, not feature count. The “many small moments of joy” line explains why mature products feel solid — it’s operational excellence, not a single killer feature.
Big takeaway: consumer startups chase attention, but infrastructure startups compound quietly. If your product sits inside other companies’ workflows and saves real operational cost, growth may be slower at the beginning — but it becomes extremely durable.
What stood out to me most was the statement that distribution is just as important as product, and that strong distribution of a good enough product often beats weak distribution of a great product. While I understand the practical logic behind that, I’m not entirely convinced it applies in the same way to developer tools.
In the case of an SDK that gets deeply embedded into a customer’s application, product quality is foundational. If the tool is unstable, poorly documented, or technically limited, distribution alone will not carry it very far. Integration is a high-commitment decision, and engineers tend to evaluate tools very critically. In that context, “good enough” is rarely enough.
To me, it seems more likely that in their case the technical depth and reliability of the product created the conditions that made distribution effective. Distribution amplified an already strong core. Without that core, especially in enterprise environments, I doubt the same strategy would have worked.
I think there’s sometimes a tendency in startup discussions to overemphasize distribution and underestimate how difficult it is to build a truly robust infrastructure product. In dev tools especially, product quality is not just a differentiator. It’s the baseline requirement for survival.
Great timing story! The fact that nobody in the document space took mobile seriously in 2010 is wild in hindsight. You basically owned an entire category before the big players even showed up.
I'm building several indie apps myself (parking timer, developer tools) and the hardest part is always picking which problem to double down on. You solved that by accident — a consulting gig turned into a product because demand was instant. That's the dream.
One question: after bootstrapping for 7 years, was the Insight Partners acquisition always the plan, or did it just happen to make sense at that point?
Hi everyone! 👋
I help startups and small businesses build professional websites that convert visitors into paying customers. Many great products struggle to get results simply because their websites don’t showcase them effectively or guide users clearly.
If you’d like help improving your website or creating a strong online presence for your startup, feel free to check my profile and contact me through my email there.
Really insightful journey — especially the part about solving a real, immediate need in a fast-growing ecosystem and letting word of mouth drive early traction.
The balance between product and distribution also stands out. Many builders focus heavily on features when growth slows, but your point about being “thirsty for critical feedback” and truly understanding customer pain is powerful.
Also loved the perspective on scaling culture while growing the team — that’s something many early founders underestimate.
Thanks for sharing such a detailed and honest look at building long-term.
Fascinating journey from law to scaling a high-growth tech company. The combination of domain expertise, strong cofounders, and long-term vision really stands out. It’s a great reminder that unconventional paths can lead to exceptional outcomes. Inspiring story!
A while back, I jumped into a global property deal, saying folks like me could cash in on hot foreign housing scenes. Real estate - sure, everyone knows it prints money, a big-time industry worldwide. It looked solid at first - they showed me online walkthroughs of places I partly owned, got me pumped. Still, there was this weird vibe nagging me, hard to explain, just wouldn’t quit bugging me inside. I ignored it, though, brushed it off, kept going anyway. One thing I’d say now? Listen to that inner voice - every single time. I kept picturing the steady cash coming in, which blurred how clearly I saw things. At first, they paid me consistent returns, making it feel legit. Over time, though, I poured more money into it. Before long, I tried pulling out bigger amounts - but then the payouts just vanished. The reasons they gave shifted every week, and not long after, they began asking for added charges to fix the withdrawal issues. Still, I’d spent every dollar - put everything I owned into it, thinking it’d be okay. When things went south, I panicked, then remembered a name: {DIGITAL LIGHT SOLUTION}. Found them through some random post while scrolling late at night. Honestly? Didn’t believe they’d help, but they jumped on it fast, scanning stuff I didn't even know existed. Right away, knew these folks weren’t messing around. Used hidden clues online, tracked down where the cash got moved, and then fought to pull it all back into my hands. I'm happy the hard work brought results - my full investment was back in just 72 hours thanks to the team handling my issue. I reached {DIGITAL LIGHT SOLUTION} through T e l e g r a m -- d i g i t a l l i g h t s o l u t i o n And E m a i l.d i g i t a l l i g h t s o l u t i o n (@) q u a l i t y s e r v i c e.c o m - W hats App +1.9.5.4.8.5.6.8.0.4.5
Impressive milestone building a mobile SDK into an 8-figure ARR portfolio shows strong product-market fit, execution, and long-term vision. Scaling developer-focused products requires not only great technology but also strong ecosystem support and continuous innovation. It’s inspiring to see how focused platform strategy and developer adoption can drive massive business growth
Building a mobile SDK into an 8-figure ARR portfolio requires solving a real developer pain point with a lightweight, scalable, and well-documented product. Focus on performance, seamless integration, and strong API stability to drive adoption. Use a freemium model, developer marketing, and strategic partnerships to scale distribution. Continuously add high-value features, ensure cross-platform support, and prioritize reliability, analytics, and customer success to retain clients and achieve sustainable revenue growth.
A while back, I jumped into a global property deal, saying folks like me could cash in on hot foreign housing scenes. Real estate - sure, everyone knows it prints money, a big-time industry worldwide. It looked solid at first - they showed me online walkthroughs of places I partly owned, got me pumped. Still, there was this weird vibe nagging me, hard to explain, just wouldn’t quit bugging me inside. I ignored it, though, brushed it off, kept going anyway. One thing I’d say now? Listen to that inner voice - every single time. I kept picturing the steady cash coming in, which blurred how clearly I saw things. At first, they paid me consistent returns, making it feel legit. Over time, though, I poured more money into it. Before long, I tried pulling out bigger amounts - but then the payouts just vanished. The reasons they gave shifted every week, and not long after, they began asking for added charges to fix the withdrawal issues. Still, I’d spent every dollar - put everything I owned into it, thinking it’d be okay. When things went south, I panicked, then remembered a name: {DIGITAL LIGHT SOLUTION}. Found them through some random post while scrolling late at night. Honestly? Didn’t believe they’d help, but they jumped on it fast, scanning stuff I didn't even know existed. Right away, knew these folks weren’t messing around. Used hidden clues online, tracked down where the cash got moved, and then fought to pull it all back into my hands. I'm happy the hard work brought results - my full investment was back in just 72 hours thanks to the team handling my issue. I reached {DIGITAL LIGHT SOLUTION} through T e l e g r a m -- d i g i t a l l i g h t s o l u t i o n And E m a i l.d i g i t a l l i g h t s o l u t i o n (@) q u a l i t y s e r v i c e.c o m - W hats App +1.9.5.4.8.5.6.8.0.4.5
The honesty about luck + effort was refreshing. Especially the advice about staying close to customer pain even while scaling, a lot of startups lose that after growth. The “tiny moments of joy” idea explains why some developer tools feel polished while others feel mechanical.
Impressive journey from SDK to scalable ARR. Strong product focus, ecosystem thinking, and long-term monetization strategy show how consistency and developer trust drive sustainable growth.
Great story. What stands out most is how the opportunity came from solving a real, painful problem at exactly the right moment in the mobile shift. Also love the point about distribution vs product — so many builders hide behind features instead of facing the harder problem of getting users. Solid reminder that long-term growth is usually a mix of timing, positioning, and relentless feedback loops.
The part about solving a pressing need on iOS before the ecosystem caught up really stands out. Porting PDFKit and turning it into a production-grade SDK when mobile was still underestimated is the kind of timing + execution combo most founders miss.
Also appreciate the point about distribution vs product. Engineers often default to building more instead of tightening distribution. That tension is real.
Incredible journey.
Love this journey. The pivot from law back into tech through a real, painful problem feels very real. I also love how honest you are about scaling culture and people, that’s the part nobody glamorizes, but it’s the hardest. Thanks for sharing this so openly.
Really enjoyed this story. The focus on solving a painful, real problem instead of chasing trends is powerful.
The part about being thirsty for critical feedback and letting users explain the value in their own words really stood out. That’s something many makers underestimate.
Thanks for sharing such honest lessons from the journey 🙌
Really appreciated the point about distribution being just as important as product. As a solo dev, I keep catching myself adding features instead of actually getting my work in front of people — classic engineer trap.
The "tiny moments of joy" part also hit home. It's easy to chase one big feature thinking that's what will make people love your product, but in reality it's the small, thoughtful details that stick with users.
Curious how you handled the early days of getting the word out when you didn't have a big audience yet. Was contributing to communities and open source enough to get traction, or did you have to do more direct outreach to land those first paying customers?
Amazing insights!
Great story on finding an unglamorous but painful problem (PDFs on mobile) and compounding it for 8 years. The mix of domain expertise (law background) + strong technical co-founders solving a real developer pain, then letting word-of-mouth do the heavy lifting, feels like a blueprint a lot of indie builders miss. Jonathan's point about distribution being as important as product resonates—most engineers keep building when they should be talking to customers.
That’s an impressive background—your long-term work with Indie Hackers and deep exposure to founder stories really shows in how you connect insights across SaaS, AI, and niche markets. That kind of pattern recognition is especially valuable in fast-moving spaces like apps and games, where user behavior and monetization models evolve quickly. I see similar dynamics when working with Mod APK–focused content at
This is inspiring as hell.
Going from law to bootstrapping a PDF SDK to 8-figure ARR while staying technical the whole way is rare.
I'm 7 months into solo building a Python system monitor on a 94°C laptop,
no cofounders, no funding, just me fighting memory leaks at 3 AM.
Your C++/C#/Swift monorepo + Elixir backend stack is goals.
This was an excellent read — especially the emphasis on being thirsty for critical feedback and staying close to real customer pain even as scale increases.
One thing that really stood out is how often the origin story comes back to the same pattern:
That mirrors my own experience at a much smaller scale.
I’m currently building a simple budgeting app, not because I had a novel idea, but because I personally struggled with understanding what money was actually safe to spend day-to-day. No dashboards, no forecasting engines — just clarity. That framing has kept scope tight and decision-making sane.
The part about great products being a collection of tiny moments of joy also resonated. It’s easy to chase a “big feature” narrative, but in practice the feedback that matters most is usually about small things:
“This screen made me feel calmer.”
“I didn’t have to think about what to do next.”
“It felt obvious.”
Those comments are gold.
Also appreciate the honesty around luck. It’s refreshing to see someone at scale openly acknowledge that effort doesn’t guarantee success — it only earns the right to be in the room when luck shows up.
Thanks for sharing such a grounded perspective. Posts like this are incredibly useful for founders in the messy middle who need realism more than hype.
це доволі круто
Congrats, man, I hope it keeps going :)
Really resonated with the section about staying close to customers even as you scale. I'm building FontPreview (a typography tool for developers/designers) and catching myself spending too much time on features instead of talking to users. The 'tiny moments of joy' insight is gold – that's exactly what makes a developer SDK feel polished vs just functional. Thanks for sharing the journey! Afsar
Inspriring
Hey!
Congratulations & All the best for this adventure!
Thanks for sharing
SDK free to use until now?
This is a really insightful post.
I like how you started with an SDK and focused on distribution first, then monetized through usage. The idea of expanding into a portfolio instead of a single product is especially interesting.
As someone building a small product myself, this made me rethink whether I should design for extensibility from the beginning.
Thanks for sharing
will you have sdk beta for testing
Do not be naïve to fall for the fakes, they are lots of them out there, falling for a fake is not the end of the world, i also fell for one of their traps, but Amadeo and his team came through for me, his mail: macprivateinvestigators AT gmail DOT com came around rescuing me from their hands, they helped get the necessary information that made me free.
Is the SDK free to use?
How did you monetize in the beginning, and how do you monetize now?
Very insightful post. As someone who's also building a product as an SDK, I really like the sandbox idea as it allows people to get a good feel for it
Is the SDK free to use?
What's your monetization strategy?
I've built the SDK and it's free to use. My product is in the fintech space and is monetized by transactions, more merchants and volume is what is required to make it work.
Interesting... so you get a percentage of each trade via transaction fees, like Stripe or Fidelity?
How did you decide on this monetization strategy, specifically?
Yep same as Stripe, except Stripe charge higher fees, can block or hold your money etc.
For strategy I looked at what scales in payments, Stripe, Wise, PayPal & other stablecoin companies & they all take a cut per transaction. It aligns incentives (we only earn when customers actually move money) and scales linearly with volume.
That makes a lot of sense.
What made you decide to make a product in the fintech space, specifically?
This comment was deleted a month ago
This comment was deleted a month ago
this isn’t a growth story .... it’s problem depth compounding.
one ugly, unavoidable workflow → owned end-to-end → expanded pricing power.
Really insightful journey from niche problem discovery to building a scalable developer-first business. What stands out most is how early community involvement and solving a very specific technical pain point created long-term traction. The balance between product depth, distribution, and enterprise trust seems to be the real growth driver here, especially with SDKs that integrate into critical workflows. Also appreciated the honesty around scaling culture and the emphasis on critical feedback — that’s something many startups underestimate until much later.
This is a great example of how non-linear careers can compound instead of reset—your technical roots, legal insight, and people skills clearly created unfair advantages once they converged.
The biggest takeaway for founders here is staying close to customers, actively seeking critical feedback, and scaling culture with intent, not nostalgia.
Impressive breakdown of how a focused mobile SDK can evolve into a serious revenue engine. Scaling it into an eight-figure ARR portfolio clearly comes down to strong product-market fit, smart partnerships, continuous innovation, and a well-structured monetization strategy. Great insights on long-term positioning and ecosystem thinking!
Building a mobile SDK and scaling it strategically can grow into an eight-figure ARR portfolio through innovation, partnerships, and strong monetization.
The move from a single SDK to an 8-figure portfolio is the ultimate masterclass in becoming the 'Default Choice.' In the mobile space, developers don't want 10 different vendors; they want one reliable partner that handles the 'boring' infrastructure so they can focus on their UI. The real genius here is the Expansion Revenue—once you’re integrated into their codebase, adding a second or third product from your portfolio becomes a 'frictionless' decision for the CTO. Did you find that your first 100 developers were the hardest to convince, or did the growth come from 'land and expand' with enterprise clients?
Incredible journey, James! 🚀
I love how you combined deep technical expertise with soft skills and legal knowledge to find a real pain point in the market.
The focus on tiny moments of delight in the SDK really resonates — so often software teams prioritize features over the subtle UX wins that actually drive adoption.
Curious: when scaling from a small team to 170 people, how did you prioritize maintaining product quality versus onboarding new engineers efficiently?
What really stood out to me was how you blended deep technical work with soft skills and legal understanding to uncover a real market pain — that’s a rare combo.
The idea of focusing on tiny moments of delight in the SDK resonates a lot. In my experience, teams often over-index on shipping features and underweight the subtle UX decisions that actually drive trust and long-term adoption.
I’m curious about the scaling phase too: when the team grew from a small group to ~170 people, how did you balance maintaining product quality with the need to onboard engineers quickly without slowing momentum?
Asking because I’ve seen similar tradeoffs even outside pure SaaS — we’re applying the same “small UX wins matter” mindset while building digital touchpoints for a local service business (Premier Cooling LLC), and quality tends to slip fastest during growth if systems aren’t intentional early.
Would love to hear what guardrails or processes helped most during that transition.
Love the emphasis on 'tiny moments of joy' over one grand feature. It’s the attention to detail in document processing—or any niche policy tool—that builds long-term word-of-mouth. Starting from 'I don't know' and hunting for critical feedback is a mindset more builders need to adopt.