Building a $15M+ ARR SaaS from a gap he found at his
brick-and-mortar
Roy van den Broek started an AV rental company when he was 16 years old, and was frustrated by the available software. So, he built his own. Now, Rentman is on its way to $20M ARR.
Here's Roy on how he did it. 👇
On the way to $20M ARR
I'm Roy. My background is in event services and AV production, so I've spent a lot of time on the operational side of live events. That's where I discovered the problem. The tools the industry was using were either spreadsheets held together with tape or software built for other industries and bent into shape for ours.
Today, I'm building Rentman, an operations platform for the event and media industry. It handles the messy middle of running a production company: equipment rental, crew scheduling, quoting, logistics, invoicing. Our goal is to give companies in this space one system that fits how they work, instead of five that sort of do.
We serve rental and production companies, AV, lighting, staging, broadcast, and film. This applies anywhere gear and people need to show up at the right place at the right time.
We're currently between $15M and $20M ARR.
Fixing something that was broken
I started DJing when I was 12, and by 16, I had my own AV rental company. Running it, I repeatedly hit the same wall: the software we used was either built for other industries or was expensive, clunky on-prem stuff that nobody liked. Everyone complained, but nobody had a better option.
So, I built something for my own company. That was my sole goal. I wasn't trying to start a business or sell software. I had a problem to solve, enjoyed building, and it felt natural.
Other rental companies heard about it and asked to use it too. Five of them liked it enough to back the idea early. But even then, I considered it a one-time project: Build it, ship it, go back to renting out speakers.
The opportunity slowly became clear. People kept asking for more, and the product kept growing. Eventually, it was obvious this was bigger than my own rental company and a side project.
That's how Rentman became Rentman. But the starting point wasn't ambition; I just wanted to fix something broken for me.
No grand plan
I didn't have a grand plan. No roadmap, no team, no pitch deck. I just built features as I encountered problems in my own operation.
That became a big advantage. I knew exactly which functions mattered because I used them daily: equipment availability, quoting, crew scheduling, and project planning. I didn't have to guess what rental companies needed. I was one.
Once other companies started using it, the work grew beyond what I could handle alone. I hired programmers to help. We kept the feedback loop tight: I'd talk to rental companies, we'd build, ship, and iterate. The five companies that backed it early were our first design partners. They told us what was broken, what was missing, and what didn't fit their workflow.
Two principles shaped it from day one. Simplicity, because the existing tools were overcomplicated and nobody liked using them. And cloud, because the industry wanted to work from anywhere, and the software at the time forced them to sit at a desk. We were one of the first cloud-based rental tools in the Netherlands, and that became a big part of why it spread.
Tech stack
On the backend, we primarily use modern PHP, with MySQL as the main database and MongoDB for a particular microservice, all running on AWS.
On the frontend, we use Angular with TypeScript.
For infrastructure, we rely heavily on AWS: RDS, S3, CloudFront — the usual suspects.
Bootstrapping for eight years
We're a SaaS business. We have multiple products, and each has its own per-seat subscription. Customers pick the products they need and pay per user for each.
For the first eight years, we were fully bootstrapped. No VC or outside money. We got to tens of thousands of users across 70+ countries before we took outside capital.
Because of that, I was always my own biggest challenge. Bootstrapping meant I played every role as the company grew. I started as the developer. Then I did sales. Then I handled hiring. Then I learned how to lead a team, how to build a management layer, and how to be a CEO. Each of those was a different job I learned on the fly.
Every time the company hit a new stage, my adaptation speed was the bottleneck. The product could scale, the market was there, the team was ready, but I needed to grow into the next version of the role. That took time, mistakes, and a lot of unlearning. If I could have made those transitions faster, we'd be bigger today.
A straightforward flywheel
Growth was mostly organic. These were our initial channels, prior to being funded.
First, community. The AV and event production world is tight-knit. People work with each other, meet at trade shows, and refer jobs back and forth. We've spent years showing up in that world, not as a software vendor, but as part of it. We go to industry events, run webinars, sponsor things, and stay in real conversations with users. When a production company recommends Rentman to another production company, that's worth more than anything we could buy.
Second, word of mouth compounds in this industry. Freelance crews work for multiple rental companies. When someone learns Rentman at one job, they want their next employer to use it too. That's a natural flywheel we lean into, rather than fighting it.
Third, product-led growth. Anyone can start a free trial, set up their own account, and be running real projects within a day. We invest a lot in onboarding, documentation, and making the first experience smooth. Most of our customers find us, try us, and decide on their own. Sales follows — to help, not to push.
Fourth, customer feedback as a growth engine. Every feature request, every support ticket, every user interview feeds the roadmap. When customers see the product evolving around their needs, they stay longer, use more, and tell others. Retention and expansion are the quiet engines of SaaS growth, and we take them seriously.
The flywheel was straightforward: Build something the industry genuinely wants, make it easy to try, let users onboard themselves, and keep the product good enough so they stay and bring others in.
The challenge of growing a team
Growing the team from a handful of people to over 100 was a huge challenge. What worked at 10 didn't work at 50, and what worked at 50 didn't work at 100. Bootstrapping made it harder because we couldn't afford to over-hire. We had to earn every new leader and structure from revenue.
The book Scaling Up gives us a framework with good guidance — I recommend it.
Build for what you love
Here's my advice: Do something you like. Not something you think will make you money, not something that looks good in a pitch, not something trendy. Something you genuinely enjoy working on.
Because it's going to be hard for a long time, and any other motivation will run out before the company does.
And if it didn't work out, at least you had fun while trying it.
What's next?
First, winning the US. We're the worldwide market leader in our category, but we still have a lot of room to grow, specifically in the US.
Second, AI. The world is changing fast, and I want to make sure we turn that into an advantage for our users, not a threat to our business. We have an opportunity to rethink how operations software works. AI in the loop can dramatically improve a lot of what our customers do today: the planning, the quoting, the coordination. If we get that right, we don't just improve the product; we change what the product is.
That will probably mean disrupting ourselves. Our current business model might not be the right one for an AI-native product. Per-seat pricing, how we package things, how we deliver value; all of it is on the table. I'd rather kill our own model and build the next one than protect what we have and let someone else do it to us.
Leave a Comment
Your transition from DJ to CEO is the ultimate career remix, proving that solving your own "messy middle" beats any fancy pitch deck. Bootstrapping for eight years turns you into a total Swiss Army knife before the real scaling even starts. I love your "disrupt yourself" mindset with AI it’s the best way to keep a $20M engine from getting rusty!
What was the most painful "unlearning" moment you faced while moving from developer to CEO?
Reaching $15M+ ARR on modern PHP, MySQL, and Angular is a fantastic reminder that shipping value always beats chasing trendy tech stacks. It's especially interesting that you carved out a specific microservice for MongoDB alongside MySQL—handling complex, highly dynamic data like real-time equipment availability and scheduling logic seems like the perfect use case for that. Did you spin that microservice out early on, or was it born out of scaling bottlenecks as you grew globally across those 70+ countries?
Eight years of bootstrapping into a vertical SaaS is the model nobody talks about because it's not a hero arc. It's grinding, no acquihires, no cap table moves, no cycle of fundraises. We did 19 years bootstrapped at Henson Group before the merger and the lesson is the same: when you actually came from the industry you serve, the customer feedback loop is shorter than any product team can replicate. Curious how Roy thinks about defending against horizontal SaaS players who decide to bolt on AV-rental modules. The usual answer is depth of workflow, but I have seen vertical SaaS get squeezed when generalists get good enough on the 80%.
Wonderful!
What stands out is the focus on a specific niche. Instead of building something generic, he went deep into one industry and solved real operational pain. That’s probably why it scaled so well clear value and clear audience.
Love this — building for your own real problem is what made it work. Seen this myself, the best tools come from “I needed this badly,” not “this might sell.”
nice
Hello, As i m a SAAS developer so I love this community, There are lot of link minded people here from where I can learn and grow and I cant find any other dedicated community like this,
Success for SaaS projects needs so patience and work hard
This is probably one of the strongest ways to build SaaS — solving a problem you experience daily instead of chasing trends.
A lot of great business software seems to come from fixing operational pain points first.
This is the playbook nobody can copy. Roy did not build a SaaS that needed to find customers. He was the customer, he built the tool, and five other rental companies validated it before he had to call it a business. As an angel investor I look hardest at founders who lived the problem before they tried to solve it. No amount of MBA-grade research replaces seven years of operating pain. Vertical SaaS in niche industries (AV, HVAC, dental, restoration) is where the biggest moats are quietly being built right now. Horizontal players cannot cross over without a domain shift that breaks their UX, and operators in those niches do not have time to roll their own. Eight years of bootstrapping is the unsexy part of this story, but the compound on staying lean is doing most of the work.
The "scratch your own itch" origin story is classic, but what stands out here is the discipline to stay focused on one vertical instead of expanding too fast. AV rental software sounds niche until you realize every production company, venue, and event business has the same problem — and none of the generic tools fit.
The lesson that transfers to any bootstrapped business: the more specific the pain, the less competition, the easier the sale. Roy didn't build "rental software" — he built software for a world he already understood from the inside.
This is honestly very inspiring due to the fact of your struggles at first and overcoming a lot of obstacles along the way and still being successful.
Interesting point. In SaaS, I think internal enablement often gets less attention than customer-facing marketing, even though it has a direct impact on activation and retention.
This is actually so goated. starting a whole ass saas at 16 just because the current tools were trash is such a flex. love the "scratch your own itch" energy, those are always the best products. 20M ARR while being bootstrapped for 8 years is insane growth. definitely a reminder to just build stuff you actually care about and let the flywheel do its thing. massive W for Roy!
This resonates a lot. We’re currently building BlackIQ Studio in a very similar way — primarily because we genuinely need it ourselves for private AI workflows and sensitive company data.
And interestingly, our next product solves an even bigger internal problem for us. We strongly believe that long-term, every company will need infrastructure like this to stay competitive and move fast with AI.
BEST RECOVERY HACKER CRYPTOCURRENCY /BANK ACCT RECOVERY/ MARK WIZARD HACKERS RECOVERY
I became a victim of a romance scam that led me to invest $654,000 in Tether USDT on a fake site. After realising I had been scammed, I felt utterly hopeless and desperate for help. I began searching for a hacker online and came across Wizard Hackers Recovery. His professionalism and expertise gave me hope. Wizard Hackers Recovery worked to recover my lost funds, and I’m thrilled to say he succeeded! I am incredibly grateful for their assistance and highly recommend their services to anyone in a similar situation or any issues you can connect with them Thank you,
Email: :Markwizard 23 @ gmailcom
WHATSAPP +4915218465599
TELEGRAM : @ wizardhackersrecovery
BEST RECOVERY HACKER CRYPTOCURRENCY /BANK ACCT RECOVERY/ MARK WIZARD HACKERS RECOVERY
I became a victim of a romance scam that led me to invest $654,000 in Tether USDT on a fake site. After realising I had been scammed, I felt utterly hopeless and desperate for help. I began searching for a hacker online and came across Wizard Hackers Recovery. His professionalism and expertise gave me hope. Wizard Hackers Recovery worked to recover my lost funds, and I’m thrilled to say he succeeded! I am incredibly grateful for their assistance and highly recommend their services to anyone in a similar situation or any issues you can connect with them Thank you,
Email: :Markwizard 23 @ gmailcom
WHATSAPP +4915218465599
TELEGRAM : @ wizardhackersrecovery
BEST RECOVERY HACKER CRYPTOCURRENCY /BANK ACCT RECOVERY/ MARK WIZARD HACKERS RECOVERY
I became a victim of a romance scam that led me to invest $654,000 in Tether USDT on a fake site. After realising I had been scammed, I felt utterly hopeless and desperate for help. I began searching for a hacker online and came across Wizard Hackers Recovery. His professionalism and expertise gave me hope. Wizard Hackers Recovery worked to recover my lost funds, and I’m thrilled to say he succeeded! I am incredibly grateful for their assistance and highly recommend their services to anyone in a similar situation or any issues you can connect with them Thank you,
Email: :Markwizard 23 @ gmailcom
WHATSAPP +4915218465599
TELEGRAM : @ wizardhackersrecovery
This is great advice. I would reiterate keeping things simple. In the last company I started, we provided software to field service companies. My general intent was to build more things. But when I talked to my users, I realised they wanted simplicity and predictibility. My software was core in their business. They did not want to spend time learning every fancy feature. They wanted a job to be done.
This is probably one of the strongest examples of why founder-market fit matters more than “finding startup ideas.”
He didn’t start with trends, market maps, or “10 SaaS ideas to build in 2026.” He started with a painful operational problem he dealt with every single day. That’s why the product feels grounded in reality instead of feature soup.
The underrated part here is that he accidentally followed the ideal SaaS path:
solve your own expensive problem
get a few real users early
iterate directly with them
stay close to workflows
grow from actual usage instead of hype
Also interesting that the moat wasn’t some breakthrough AI or fancy tech stack. It was deep industry understanding. Most outsiders would never think crew scheduling + AV logistics could become a $20M ARR business, which is exactly why opportunities like this exist.
Feels like boring operational software quietly beats “viral startup ideas” far more often than people admit.
This resonates deeply. I'm building multiple products to solve my own problems too — automation tools that I wish existed when I was struggling. Your point about bootstrapping and being your own bottleneck is sobering. I'm currently solo, and I can see how my ability to learn fast will be the limiting factor.
Questions: 1. When did you realize it was time to bring on your first hire? Was it revenue-based or time-based? 2. You mention that 'build for what you love' — did that philosophy guide your product decisions when you had to choose between market demand and what you actually wanted to build? 3. With the AI shift you're planning, how do you balance protecting your current revenue model with disrupting yourself?
Also love the community-first approach. That's more sustainable than chasing vanity metrics.
Great founder story. Rentman start as an SaaS operator solving his own painful workflow problem, that usually produces a stronger product than building from a spreadsheet of market trends. The organic flywheel is interesting too: a tight industry community, freelancers carrying the product from one company to another, self-serve onboarding, and constant feedback loops.
On the AI point, operations software with AI in the loop could move from a system of record into a system that helps plan, quote, schedule, and coordinate work. For a company already trusted by the industry, that creates a real opportunity, and also a test of whether the business model can move beyond per-seat pricing.
The most underrated moat in this story is the 8 years before product-market fit looked like product-market fit. Anyone trying to clone Rentman now would build the same features and lose, because they wouldn't know which 20% of those features actually matter to a working AV operator on Friday night when the truck is loaded wrong. That scar tissue is what makes vertical SaaS from operators almost impossible to displace.
Ran an MSP for ~20 years and saw the same dynamic. The MSPs that survived built their own internal tooling, productized it years later, and ate the market. The ones who tried to bolt vertical features onto generic PSA software are still selling spreadsheets.
Really enjoyed reading this. It is always impressive to see a product come from a real problem someone experienced firsthand. That kind of insight is hard to replicate and it clearly shows in how well this has scaled. Stories like this are a great reminder that strong businesses often start by simply paying attention to what is missing in everyday work
nice sharing
What really stands out here is how founder‑market fit did most of the heavy lifting long before any growth strategy kicked in. You weren’t guessing what the AV world needed you were living the pain daily, which is why the early product decisions around simplicity and cloud-first workflows landed so well .
The other underrated part is the honesty about being your own bottleneck at every stage. Most founders talk about market constraints or hiring challenges, but rarely admit that the real limiter is their own ability to evolve into the next version of the role . That level of self-awareness is probably a big reason Rentman kept scaling instead of stalling.
And the AI section is bold in the best way especially the willingness to rethink (or even kill) the current business model before the market forces it. Most SaaS companies at $15M–$20M ARR cling to per-seat pricing; very few openly acknowledge that AI-native workflows may require a completely different value model .
Overall, this is one of those stories that reminds builders that the real moat isn’t the tech stack — it’s the depth of understanding that comes from actually running the business you’re trying to fix.
The tech detail buried here is worth highlighting: MySQL as the main transactional DB, MongoDB for a microservice layer, on AWS RDS — and presumably migrating heavier analytical queries to a purpose-built store as operational data volume grew. That's exactly the right architectural instinct. The bottleneck that typically shows up between $15M and $20M ARR in a vertical SaaS like Rentman: your transactional queries (equipment availability checks, quoting, crew scheduling) and your analytical queries (equipment ROI by category, quote-to-close rates, crew utilization trends) have fundamentally different access patterns and index strategies, and most companies discover their 'slow dashboard' problem is actually a query design problem — not an infrastructure problem. Tightening that analytical query layer explicitly before the US expansion push will compound cleanly. If SQL query optimization patterns for operational analytics are relevant — the principles translate across MySQL, SQL Server, and Postgres — I put together a handbook covering exactly this: https://growthwithshehroz.gumroad.com/l/gwiow
The interesting part about the AI section is the willingness to cannibalize your own model before the market forces you to.
Most companies talk about AI as an “extra feature,” while the bigger shift is probably economic and behavioral pricing models, workflows, onboarding, even what users expect software to do autonomously.
The part about being your own bottleneck at every stage hits hard. I'm 3 weeks into launching my first SaaS (penroll app) and already feeling it — I built the product fast but distribution is a completely different skill. The 8 years bootstrapped detail is the part most people skip over in these success stories.
Interesting how many strong SaaS businesses come from boring real-world problems rather than flashy startup ideas.
The distribution is already there when the pain is real.
"Roy, this is such a powerful example of why domain expertise is the ultimate unfair advantage.
Many founders spend months looking for 'the perfect idea' in a vacuum, but you found it in the friction of your daily operations. Transitioning from a physical business to a SaaS with >$1.25M/mo revenue is a massive feat of focus.
I'm curious about the early days: how did you handle the mental shift from being a 'service provider' to a 'product builder'? Also, did you use your own rental company as the primary 'lab' for testing before scaling?
Seeing Rentman’s success is incredibly inspiring as I build Esencia SS for the wellness niche—it reinforces the idea that the best software is born from real-world frustration. Thanks for the breakdown!"
The “I’d rather kill our own model and build the next one” line hits hard. Most vertical SaaS founders at $15M–$20M ARR don’t say that. They tend to lock into per-seat pricing, optimize CAC, and end up watching a smaller AI-native competitor slowly eat their category over the next few years.
Question for Roy on the AI side: when you imagine a rebuilt Rentman, where do you see the real wedge?
Is it a workflow LLM that can understand context and actively execute planning, quoting, and coordination tasks end to end? Or is it the underlying data infrastructure the operational graph of equipment, crews, projects, and constraints becoming accessible to any AI runtime through something like MCP?
I’m asking because I increasingly see the operational graph itself as the real moat in vertical AI. Models can be replicated quickly. What can’t be easily rebuilt is years of encoded domain behavior how the industry actually works in practice !
Currently tackling a similar operational nightmare in the hospitality sector with ChefPASS. The platform is live natively on iOS and Android via Bubble to handle short-notice chef cover. The supply side was straightforward to build—30 freelance chefs are fully onboarded. However, the founder-adaptation bottleneck you mentioned is real; the current challenge is entirely focused on cracking the B2B sales motion to acquire the venues.
When Rentman first started spreading among those initial five design partners, did they naturally advocate for the platform to other rental companies, or did that early word-of-mouth require active incentivization?
I’ve been writing for Indie Hackers for nearly a decade, during which I’ve interviewed hundreds of startup founders about their successes, failures, and key lessons learned. Alongside this, I’m the cofounder of dbrief, an AI interview assistant, and LoomFlows, a platform for collecting customer feedback through Loom. I also publish two newsletters: SaaS Watch, which highlights micro-SaaS acquisition opportunities, and Ancient Beat, focused on archaeology and anthropology news wafflemenus .us
This is the kind of SaaS story that stands out because it came from solving a real operational pain instead of chasing trends. Roy building software for his own AV rental business first — then turning it into a $15M+ ARR company — is such a strong reminder that the best SaaS ideas usually come from industries people ignore.
What I liked most was the long-term thinking behind it. Instead of rushing for quick wins, he focused on deeply understanding the workflow, building for an underserved niche, and compounding over years. Also a great example of how “boring” industries can quietly become massive software businesses when the solution genuinely saves time and chaos for customers. 🚀
The "freelance crews demanding the tool at their next employer" growth loop is underrated — basically product-led growth without even trying. You seeded demand in a tight-knit industry where everyone knows everyone.
Curious: at what ARR did you feel the bootstrapped pace was actually a disadvantage vs competitors? You held out 8 years before outside capital — most founders fold much earlier.
Really enjoy platforms like Indie Hackers where founders openly share their journeys, wins, and challenges. Reading real startup stories and growth strategies is always motivating for people building online businesses.
I also run a food and restaurant menu website, where we share updated menu details, prices, deals, and meal guides for food lovers. Communities like this are great for learning how independent websites and niche projects can grow step by step. 🚀
15M is crazy, hope to reach that too
great job bro
Building a $15M+ ARR SaaS from a gap found in a brick-and-mortar business shows the power of innovation and problem-solving. Similarly, Hypic Mod APK helps users enhance creativity through advanced photo editing features, improving digital content and online engagement effectively.
What I love about this kind of origin story is that the insight came from living the problem, not from market research or trend reports. There's something irreplaceable about that — the kind of understanding you only get when you've actually stood behind the counter and felt the friction yourself. Most AI-era products are built top-down: "here's a capability, now find a use case." Yours sounds like it went the other way. Did that ground-level understanding change how you think about product decisions as you scaled?
Nice idea.
Build for what you love! I love this part.
This is such a refreshing story. No grand plan. No pitch deck. Just 'I fixed what was broken for me' and then people kept asking for it.
The part that hit hardest: 'Every time the company hit a new stage, my adaptation speed was the bottleneck.' That's brutally honest. Bootstrapping for 8 years and growing into the role each time , that's the part no one talks about.
Quick question, when you were still solo and just building for yourself, at what point did you realize 'okay, this is actually a business now'? Was there a specific moment or just a slow realization?
I'm building Bexra — Helping entrepreneurs find, build & grow. Still pre-launch. Reading stories like this makes me realize the whole 'overnight success' thing is a myth. It's just years of grinding while the founder grows as much as the product.
Also, the line 'I'd rather kill our own model than protect it and let someone else do it to us' that's going in my notes. Thanks for sharing."
Love this! Seems like serendipity but illustrates the power of just showing up and having a problem solving mindset. More power to you!
Starting an AV rental company at 16 is a wild origin story - curious how early he realized the software was the real business vs the rental side.
Amazing transformation!, I am working on a project also.
"Amazing story! Very inspiring. I'm also building my first SaaS product."
What stood out to me is that this didn’t start as “let’s build SaaS.”
It started as “this workflow is broken and I’m tired of living with it.”
That distinction matters a lot.
When a founder has lived inside the messy middle of an industry, they don’t just understand the feature list. They understand the weird edge cases, the manual workarounds, the moments where people lose time, trust, or money because the workflow is fragmented.
The AV/event example makes that really clear:
equipment, crew, quoting, logistics, invoices — all separate problems, but the real pain is the workflow between them.
I’m building in a very different space, but this part resonates a lot. The more I work on my own product, the more I realize the category isn’t really “more tools” or “more automation.” It’s reducing the chaos between research, decisions, risk checks, and execution.
The second-customer point is also huge. Your own pain validates the problem for one person. The second customer tells you whether it’s actually a market.
This is one of those rare founder stories where every paragraph hits harder than the last
What stands out to me most isn't the $20M ARR trajectory it's the fact that Roy literally was the market before he built the product He wasn't guessing pain points or running surveys he was the frustrated 16-year-old renting out speakers and dealing with broken spreadsheets That level of founder-market fit is almost impossible to replicate artificially and it clearly fuelled the early product decisions especially around simplicity and cloud-first architecture when the rest of the industry was still stuck on-prem
The other gem in this thread that most people will gloss over he clearly states that his own adaptation speed was the bottleneck at every growth stage Not the market not the team him That level of honest self-awareness from a founder who's pushed past $15M ARR is rare If I could have made those transitions faster we'd be bigger today Raw and probably true
Also the underrated growth engine here is the freelance crew flywheel When a crew member learns Rentman on one gig and demands it on the next the product basically distributes itself across companies without a single marketing dollar That's a structural advantage I doubt any amount of VC-funded paid ads could replicate in such a relationship-driven industry
The I'd rather kill our own model stance at the end is bold Per-seat SaaS and AI-native products rarely coexist in the same pricing structure It'll be interesting to see if they unbundle or switch to usage-based or outcome-based pricing as they fold more AI into planning quoting and coordination Most companies at $20M ARR are busy protecting themselves Roy sounds like he's still in building mode
Curious for those building in vertical SaaS today how many of you are starting with genuine personal frustration vs spotting a market gap from the outside Does that distinction still matter as much in 2025
Killed it James. One gap I see with sub-$20M founders: you look small to M&A brokers even after raising.
I build 48hr “Acquisition Optics Packs” — CEO clip + Forbes draft + deck. $2.5K. No intros = refund.
Details in my Twitter pinned. 1 slot left.
Really solid pain point to solve. Thank you for sharing your story!
You didn’t chase a market; you fixed a workflow you deeply understood.
That removed guesswork and replaced it with clarity most founders don’t have.
The outcome isn’t surprising—the foundation was unusually real.
This is a great example of building from real operational pain.
I’ve seen the same thing tools built for one use case being forced into another, which creates friction everywhere.
The tight feedback loop you had early on is probably what made the difference.
At what point did it shift from “internal tool” to “this could be a real company”?
This is the part that stuck with me: "found the gap at his own business first." That's the most reliable validation — your own pain. Currently building an AI accessibility tool after seeing how manually painful WCAG compliance is for web agencies. Following this playbook of solving a problem I understand firsthand.
This reads like a solid founder reflection, but it’s currently mixing three different things that would be stronger if separated: growth philosophy, scaling pain, and future strategy. Right now they blur into a “generic SaaS success story” tone instead of a sharp insight-driven narrative.
Here’s how the thinking lands when you tighten it:
---
🔍 What’s actually strong here
The most valuable ideas buried in this are:
Retention is the real growth engine, not acquisition
Product evolution driven by customer feedback creates compounding usage
Team scaling breaks previous systems repeatedly
AI will force business model redesign, not just feature upgrades
Those are all strong — but they need clearer emphasis.
---
⚠️ What weakens the impact
The “flywheel” section is too abstract — it describes intent, not mechanism
Team scaling reads like a standard startup milestone, not a lesson
“Do something you love” is familiar advice unless tied to a specific insight
The AI section is interesting but too high-level and safe
---
💡 How to sharpen the core message
The strongest narrative thread here is actually:
> most companies don’t fail from lack of ideas — they fail from misaligned systems at scale
That connects:
product evolution
retention
hiring growth
pricing model change under AI pressure
That’s your real backbone.
---
🚀 A tighter way to frame the future section
Instead of general AI optimism, the sharper angle is:
AI won’t just improve products. It will break pricing models.
Per-seat SaaS, static feature tiers, and manual workflows don’t survive when:
one user can do 10x more work
automation becomes continuous, not feature-based
value shifts from “usage” → “outcomes generated”
That’s the real disruption you’re hinting at.
---
⚡ Big takeaway
This isn’t really a “journey post.” It’s closer to a thesis:
> scaling breaks assumptions, retention compounds value, and AI will force a rewrite of how software is priced and delivered
If you lean into that instead of the narrative summary style, it becomes much more memorable and distinct.
It's wonderful to see you tackle problems step by step, growing stronger through your passions. I hope to hear more of your experiences in the future, especially regarding how to effectively utilize existing resources to overcome challenges. Thank you.
The "found the gap inside the business he ran" pattern is underappreciated by indie founders. Most validation advice assumes you're an outsider trying to figure out a market — but the sharpest products come from founders who lived a problem long enough that the workarounds became invisible to them.
The hard part of this path nobody talks about: the same intimate domain knowledge that lets you spot the gap also makes you wildly miscalibrate the audience size. When you're embedded in AV rentals, every other AV rental shop also has the gap and you assume that's a market. But the addressable buyer set might be 200 shops, not 20,000. Roy worked his way past that — but a lot of "I built for my own business" founders launch at $15k MRR ceilings and stall.
Practical takeaway from his journey that I'd highlight: the moment he stopped using the product just for his shop and added the second customer is when the calibration started. If you're building from inside-the-business pain, the second customer is the most important one — they tell you whether the workaround is yours specifically or industry-wide.
My favorite lines: "Every time the company hit a new stage, my adaptation speed was the bottleneck. The product could scale, the market was there, the team was ready, but I needed to grow into the next version of the role. " I loved the story, the process, and your problem-solving skills. Congrats on the beautiful journey :)
8 years bootstrapped to $15M+ ARR and now he's openly saying he'll kill his own per-seat pricing for an AI-native model. That's the part most incumbents won't do. They'll protect the SKU until someone eats them
Nice work
amazing
That’s a great example of how the best ideas often come from solving your own problems—what started as a practical fix naturally evolved into something much bigger because others clearly needed it too.
The 8 years of bootstrapping is the real story here. Everyone talks about ARR, but very few are willing to stick through that long, slow build phase.
That’s where most people drop off.
8 years bootstrapped is the part people skip over in these stories. most tools I've seen at that stage had already taken VC or burned out. that's genuine stubbornness.
i am begineer how to start this field ?
Hi William , Lets connect do you build SAAS? I do.
in my opinion Getting the first few users is the hardest part
how is this?
This is one of those stories where the best advantage is being the user first. You didn’t guess the problem—you lived it daily, which is probably why the product feels so aligned with real workflows.
The “no grand plan” part actually stands out. A lot of founders overthink before building, but here it was just: solve one real problem → get users → iterate. That tight feedback loop with early design partners is something many SaaS founders underestimate.
Luck opened the door for Roy — right timing, no real competitors, word spread naturally.
But a lot of people walk past the same door and do nothing.
He answered when the market pulled him, then stayed for 8 years without outside money. That's not luck. That's the part most people aren't willing to do.
The part about adaptation speed being the bottleneck resonates a lot. You can have the right product and market, but if the founder can't grow fast enough into each new stage, everything slows down.
Your point about disrupting your own business model before someone else does it is something most founders avoid thinking about. The per-seat model making sense today doesn't mean it'll make sense in an AI-native product — that's a hard thing to admit when it's your main revenue driver.
Starting from your own pain as a 16-year-old with a DJ business is also a good reminder that the best niches are often ones that look too small or too boring from the outside.
This is a great example of how the best SaaS ideas come from solving your own real problems. I really like how Roy didn’t start with a big vision but simply fixed something broken in his daily workflow. The part about staying close to users and building based on real feedback is especially valuable. Too many founders try to guess instead of listening.
The most valuable market research happens when you are sweating on a roof or dealing with a client who is trying to lie to your face about a job you just finished.
I spent years in solar installations and that is exactly where I found the friction that led to one of my SaaS. Digital-first founders often build tools for other digital people because that is all they see. They miss the massive, expensive gaps in traditional industries because they have never stood on the front lines of manual labor.
I think having 'brick and mortar' experience is becoming a more powerful advantage for a founder than a computer science degree.
This is a really insightful perspective. There’s a level of understanding that only comes from being directly involved in real-world operations, especially in traditional industries. Experiencing those day-to-day challenges firsthand makes it much easier to identify genuine pain points and build meaningful solutions. I also agree that founders with hands-on, “brick and mortar” experience often have an edge because they’re solving problems others don’t even see.
This really reinforces the idea that the best products come from actually living the problem, not guessing it.
What stood out to me is how he didn’t start with a “startup mindset” but just tried to fix his own workflow—and only later realized it could scale.
Curious—at what point do you think someone should shift from “just solving my own problem” to intentionally building a product for others? I feel like that transition is where many people get stuck.
Nice idea
This story really hit me. What stands out is how much of Rentman’s success came from solving a real problem you personally felt, long before thinking about “building a SaaS.”
A lot of us chase channels, trends, or the perfect growth plan. But your path is a reminder that the strongest products often come from deep firsthand experience — you knew exactly what was broken because you were living it.
I also like how simple your flywheel really is:
• solve something painful
• make it easy for people to try
• let word of mouth compound
• keep improving based on real usage
So many founders overcomplicate those basics.
Thanks for sharing the journey. Stories like this keep the rest of us grounded.
yes
Lol, nice
This is a masterclass in solving your own problem first. I've built TrendyRevenue (live – AI idea validation for founders) and your story reinforces something I'm learning: the best products come from scratching your own itch, not chasing trends.
The part about 'no grand plan, just building features as you encountered problems' – that's exactly where I am. But I'm struggling with one thing: when did you know it was time to stop building for yourself and start listening to those first 5 external customers? I'm at that decision point right now.
Also, bootstrapped for 8 years before funding – respect. What was the hardest transition after you finally took outside capital?
Thanks for sharing the real journey.
Amazing................
Great breakdown — the most valuable takeaway here is how deeply Roy understood the problem because he was the user first. That tight feedback loop + simplicity focus is what made the product stick, not just the tech stack or growth tactics.
The flywheel is also a reminder that in niche markets, community + word of mouth > paid acquisition, especially when the product solves a real operational pain.
One thing that stands out is how translating raw operational data into decisions becomes the real bottleneck as products scale. That’s something I’ve been exploring as well — building tools to simplify calculations and make performance insights more actionable alongside platforms like GA4 "peptixcalc"
Curious to see how AI reshapes these workflows, especially in operational SaaS.
funny how many SaaS stories start like this
i built a tiny JSON formatter because existing ones annoyed me… didn’t expect other people to start using it too
feels like the early stage of what you describe here
did you actively try to turn it into a product or did demand just pull you into it?
The willingness to kill your own per-seat pricing model to embrace AI is incredibly bold, but spot on. So many established SaaS companies are paralyzed by the fear of cannibalizing their existing revenue, which leaves the door wide open for lean, AI-native startups to undercut them.
Curious to hear how you're thinking about transitioning customers if you do move away from per-seat pricing? Does it look more like usage-based pricing, outcome-based, or something entirely new?
Huge congrats on the journey from scratching your own itch to $20M ARR!
8 years bootstrapped is the detail that gets buried. everyone wants the post-PMF part of the story. the part where he was just solving his own rental headaches for years - that's the actual build.
That's true.
yeah, hard to replicate that kind of insight from the outside
100%. The grind is where most quit.
yeah and it's usually the slowest part too. no story worth telling yet, just the actual work.
nice.
Hiring being hard is easy to say; "I was the bottleneck because I needed to become a different operator" is harder. Bootstrapping forces you to live through every version of the role, which is its own kind of education.
Getting the first 10 users is the hardest part. Did you do anything that didn't scale to get them?
i feel the journey
i'm building platform for events too, but a bit different niche - organizing complex incentive trips for big groups. so many moving pieces
good luck!
That sounds like a tough but interesting niche. Event businesses seem to have a lot of moving parts where the real product value is not just scheduling, but turning messy operational inputs into a clear plan people can trust.
I'm curious: for incentive trips, is the hardest part coordinating people and vendors, or is it estimating cost/margin accurately before the trip is sold?
Love seeing stories like this. I'm a CS student from Shantou, also building something on my own — a low-cost LLM API for Southeast Asian devs (70% cheaper than OpenAI, 32ms latency to SG). Still very early stage, but reading posts like this keeps me going.
The "scratch your own itch" approach really resonates. That's exactly why I started this project — I needed cheaper API access myself, and realized other devs probably do too.
Would love to hear how you validated your idea before building. That's where I'm at right now.
This comment was deleted 25 days ago