Building a mobile SDK and expanding it into an 8-figure-ARR portfolio

Jonathan Rhyne, founder of Nutrient

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:

  1. SDKs and Cloud APIs built specifically for software engineers to integrate and build upon when their applications have document-related needs or functionality.

  2. 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.

  3. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

Indie Hackers Newsletter: Subscribe to get the latest stories, trends, and insights for indie hackers in your inbox 3x/week.

About the Author

Photo of James Fleischmann James Fleischmann

I've been writing for Indie Hackers for the better part of a decade. In that time, I've interviewed hundreds of startup founders about their wins, losses, and lessons. I'm also the cofounder of dbrief (AI interview assistant) and LoomFlows (customer feedback via Loom). And I write two newsletters: SaaS Watch (micro-SaaS acquisition opportunities) and Ancient Beat (archaeo/anthro news).

Support This Post

3

Leave a Comment