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
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!
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?
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,
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.
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!
This comment was deleted a day ago