soft-shell crabdifferent species of crab

Analyzing markets for months before finding the right idea and building a 5-figure MRR product
IH+ Subscribers Only

Derrick Reimer, founder of SavvyCal

After Derrick Reimer sold Drip, he took a big swing and failed. Then, he built and sold a small company. And now, he's building SavvyCal, a two-product portfolio bringing in a five-figure MRR.

Here's Derrick on how he does it. 👇

Two exits, one failure, and another success

I'm a software developer turned founder. I started Drip, an email marketing platform, which we grew and sold to Leadpages in 2016. After that, I took a swing at a team chat product called Level (a thoughtful alternative to Slack) that didn't pan out. Then, built StaticKit, a forms-as-a-service tool that found modest traction before I sold it.

In 2020, I started SavvyCal, a scheduling tool that makes sending a booking link feel less one-sided. The product now serves thousands of customers and has been my main focus for the past six years, bootstrapped with backing from TinySeed.

SavvyCal is now two products. The original scheduling link product (now SavvyCal Meetings) is alive and well. Over the past year, I've been building SavvyCal Appointments: an API-first, HIPAA-compliant scheduling infrastructure product aimed at healthcare and SaaS companies that need embedded scheduling but don't want to build (or maintain) it themselves. Think of it as scheduling as a building block rather than scheduling as a destination.

I'm also focusing on what I'd call the "agentic" layer — we shipped an MCP server, so AI assistants can book, reschedule, and look up user availability. My hunch is that a meaningful chunk of scheduling activity will shift from humans clicking calendars to agents negotiating times, and I want SavvyCal to be natively good at that.

We're at 5-figure MRR. The vast majority of that comes from SavvyCal Meetings. SavvyCal Appointments is earlier in its revenue journey. It's a higher-touch, higher-ACV sale — infrastructure contracts with BAAs attached move slower than $12/month self-serve signups — so the revenue mix looks different: fewer customers, bigger contracts, longer sales cycles, and a lot of potential.

My team includes me, full-time in the US, a full-stack developer, and a support specialist. Small team, deliberately.

Finding the right market

SavvyCal came from a search for the right-sized problem. After Level didn't work out, I spent a few months deliberately auditing SaaS markets. I sought something with proven demand, recurring revenue, and room for a differentiated angle, rather than trying to will a new category into existence.

Scheduling checked those boxes, but a social observation truly hooked me: Sending someone your booking link carried a stigma. It felt one-sided — "Here, do the work of finding time on my calendar". I saw an opening for a scheduling tool that made the experience feel more considerate, treating the recipient as a participant instead of a supplicant. That became SavvyCal's founding wedge: features like overlaying your own calendar on top of someone else's availability so booking feels collaborative.

My deeper motivation, though, was the kind of company I wanted to run. Level was a big swing, with a potentially huge market but much uncertainty and probably too many headwinds for a bootstrapper. With SavvyCal, I wanted to build something calm and durable: bootstrapped (with TinySeed backing), profitable, small team, long time horizon. Six years in, that's still the shape of it. The market has shifted under us, with AI agents starting to change how scheduling happens, and what keeps me motivated now is that the "right-sized problem" turned out to have a much bigger second act than I expected.

Falling in love with Elixir

I wrote the first line of code in early 2020 and spent roughly six months getting to a private early-access version. The stack was Elixir and Phoenix. I fell in love with Elixir during the Level days and never looked back. Six years later, it's still the foundation and one of the best technical decisions I've made: The platform has scaled with me without ever demanding a rewrite.

Today, the stack is Elixir/Phoenix on the backend, React on the frontend, and Inertia.js wiring the two together.

The trickiest part of building a scheduling tool is the calendar sync logic and time zones (of course!). Two-way syncing with Google Calendar (and later Outlook), handling time zones, recurring events, buffers, and all the edge cases of "when is this person actually free" is gnarly infrastructure work. I spent a big chunk of those first six months getting that plumbing solid, because a scheduling tool that double-books someone even once has lost that customer forever.

On the product side, I resisted the temptation to reach feature parity with Calendly before launching. Instead, I built around the wedge: the polished booking experience, a calendar overlay allowing recipients to compare against their own schedule, and personalized links. The bet was that a smaller product that nailed the feeling of scheduling would beat a bigger product that treated it as a commodity checkout flow.

SavvyCal homepage

Charging from the start

I charged from the start. Early access users paid, which kept the feedback signal honest. People tell you very different things about a product when their credit card is attached to the opinion.

SavvyCal Meetings is a classic self-serve SaaS: monthly or annual subscriptions, priced per user.

SavvyCal Appointments flips the model: it's sales-assisted, usage-and-contract-based, and aims at companies embedding scheduling into their own product. Fewer customers, larger contracts, longer cycles.

Meetings taught me that a good product in a crowded market can win a durable niche, but later-stage growth can be difficult when competition is aggressive, and price points are low. Appointments answers that, moving down the stack into infrastructure where the buyer has a harder problem, compliance creates real switching costs, and contract sizes reflect it. I enjoy playing in both spaces.

Competing with a free incumbent

The biggest challenge in the scheduling market is that the incumbent has a generous free tier, and every productivity suite bundles some version of scheduling for nothing. You can absolutely build a great business in that environment, but you're always swimming against "Why wouldn't I just use the free thing?" That reality shaped everything: pricing, positioning, and ultimately the decision to build a second product where the buyer has a harder problem and free isn't a real option.

If I had to start over, I'd find my niche faster and sharpen my positioning from the get-go. In the early days, especially, it's tempting to say "yes" to anyone willing to pay for your product. But sound strategy requires saying "no" to customers who don't fit the vision and preventing your roadmap from wandering too much.

Two products, two growth playbooks

For Meetings, the early playbook was audience-first. I'd been building in public for years — podcasting, writing, showing up in the bootstrapper community — so, at launch, a group of people wanted to see it work. From there, we used these channels:

  1. Word of mouth via the product itself — every booking link shared is a small ad

  2. SEO and comparison content

  3. Podcast sponsorships

  4. Extensive experimentation over the years

For Appointments, the playbook is almost the opposite: it's outbound-ish and relationship-driven. We grow through inbound demo requests from the site, qualification calls, and formal quotes. The interesting lever has been what I think of as an anchor-tenant strategy: landing one credible customer in a vertical (like telehealth) creates the case studies and compliance posture that make the next five conversations easier.

I've never found a growth "hack" that mattered. Trust has compounded: An audience that knows me, a product that impresses its users, and now a compliance story that enterprise buyers can verify.

The importance of community

People have been my greatest advantage.

My family comes first. Bootstrapping solo means the highs and lows follow you home, and my family has supported this endeavor through a failed product, the lean early years, and every season where the business needed more of me. I don't think I'd still be doing this without that.

Other founders have been just as essential. Founding is isolating by default. Nobody else on my team carries the particular weight of owning the whole thing, so I lean on a web of relationships with people running similar businesses. Some of my best strategic decisions started with another founder asking me one uncomfortable question on a call.

The institutional versions of that matter too. TinySeed gave me a batch of founders in the same boat and a network that keeps paying off years later. MicroConf has been my professional home for over a decade. I've found mentors, friends, and early customers there, along with a shared philosophy about building calm, profitable, founder-owned businesses. If you're bootstrapping completely alone, you're playing on hard mode for no reason.

Know what game you're playing

Here's my advice:

  • Pick your market like it's a cofounder, because you'll be living with it for years. I spent months considering different markets before starting SavvyCal, looking for proven demand, recurring revenue, and room for a differentiated angle. That boring diligence has paid off every single year since. Most indie hacker failures I've watched were market failures, not product failures. The builder did everything right inside a market that couldn't support the business.

  • Charge money embarrassingly early. Free users will tell you what's pleasant. Paying customers will tell you what's true. Every pricing decision I've agonized over proved less scary in reality than in my head.

  • Expect year one to be lonely and act accordingly. Find your people before you need them, whether that's a community like MicroConf, a founder group chat, or two peers you call monthly. The compounding value of those relationships is invisible at the start and enormous by year five.

  • And know what game you're playing. Venture-style swings and calm bootstrapped businesses are both legitimate, but they require different decisions from day one. A lot of founder misery comes from running one playbook while wanting the other outcome. Deciding on purpose is the whole trick (and probably worth putting on a Post-it note by your monitor).

What's next?

From here, I'll keep executing my craft. I genuinely love this work: designing products, writing code, talking to customers, making a business run well. The goal has never been to escape the work; it's to keep getting better at it and to keep building things worth building.

Near-term, that means growing both SavvyCal products and continuing to innovate in scheduling as AI agents handle more booking tasks. A real shift is happening, and I want SavvyCal to define it.

Longer term, I'd like to realize the fruits of the labor. I'm not in a hurry, and I'm not building to flip, but playing the bootstrapper game well means knowing that patience and a strong, profitable business give you options when the right moment shows up. As my friend Rob Walling likes to remind his audience regularly, "everybody sells."

You can learn more about SavvyCal at savvycal.com. My personal home on the internet is derrickreimer.com, and I hang out on X/Twitter.

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 with 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 (automated expert interviews) and LoomFlows (customer feedback via Loom). I'm the creator of a newsletter called Ancient Beat (archaeo/anthro news). And I built and sold SaaS Watch.

Support This Post

71

Leave a Comment

  1. 1

    The second product is the most instructive decision in here, and it usually gets read as a product move when it was really a market move. Derrick did not try to out-feature a free incumbent, he went and found a buyer for whom free is not an option, with BAAs and compliance creating the switching costs that a $12 self-serve seat never will. At Henson Venture Partners his line holds up almost exactly: the deals that die are rarely bad builds, they are good builds inside a market that was never going to pay enough to matter.

  2. 1

    “The part about spending months looking for the right problem resonates. Sometimes the hardest part isn't building the product — it's finding a problem painful enough that people will actually pay to solve.”

  3. 1

    I actually like stories like this more than the “first startup became huge” stories. Makes you realize that the failed apps weren’t necessarily wasted work. What was different about this idea when he found it on Reddit?

  4. 1

    Great story. The persistence after failure is really inspiring!

  5. 1

    I think market selection gets underestimated. People talk a lot about shipping fast, but if you’re shipping into a market with no urgency or willingness to pay, speed doesn’t help much. I’d love to know what signals made this market stand out

  6. 1

    This post hits so many important truths for bootstrapped founders. The point about picking your market like a co‑founder really resonates, many builders overlook market validation and focus only on building features. Quick question: what’s one red flag you look for when evaluating a new potential market?

  7. 1

    The market audit after Level is the part more founders should copy. Derrick did not search for a novel category; he looked for proven demand, recurring revenue, and one painful point of differentiation. The newer appointments product also shows why company design matters: higher ACV and regulated buyers create a slower sales motion, so the cash plan and patience have to match the opportunity.

  8. 1

    I actually like stories like this more than the “first startup became huge” stories. Makes you realize that the failed apps weren’t necessarily wasted work. What was different about this idea when he found it on Reddit?

  9. 1

    The path here is encouraging, exit, failure, modest success, then a real hit. It's a good reminder that not every project needs to be the big one, sometimes it's just building the skills and instincts for the next attempt.

    I'm early in building an AI tool for e-commerce sellers right now. Curious how you personally decided SavvyCal was worth six years of focus versus something you'd eventually move on from like Level or StaticKit. Was there a clear signal, or did it just become obvious over time?

  10. 1

    I've recently launched my product and now I'm struggling with marketing. Your advices are really helpful and hope to see some progress in one to two months (half month has already passed), not years.

  11. 1

    I did my homework before building my SaaS. Market research, competitor analysis — the whole thing. I was convinced the market was starving for my product. Then I launched. Crickets. I couldn't figure out what broke. Now I realize it was probably never about the execution — it was my assumptions vs. reality.

  12. 1

    Really strong case study. The best part is the market-first approach.

    He did not just build a clever product. He looked for proven demand, recurring revenue, and a clear wedge in a crowded market.

    That kind of discipline is underrated in SaaS.

  13. 1

    The market-first part really resonates. I’ve shipped a lot of small tools, and the ones with clear demand always beat the clever ideas.

    The “right-sized problem” framing is underrated.

  14. 1

    This is such a grounded, realistic read. Too many case studies gloss over the brutal grind of competing against a massive free incumbent, but Derrick’s focus on the wedge strategy —winning on the actual feeling and collaboration of scheduling rather than rushing for feature parity — is masterclass advice.

  15. 1

    great story and good advise

  16. 1

    This is something I’ve been thinking about a lot lately. Getting the first few customers seems less about having a perfect product and more about finding the right people who actually have the problem.

  17. 1

    Really enjoyed this. I've followed Derrick's journey for a while and used to love listening to him and Ben on the Art of Product podcast. I've always appreciated how considered and articulate he is when talking about the choices and trade-offs involved in building a business, rather than presenting everything as a formula to follow.

    The point about knowing what game you're playing particularly resonated. There's a big difference between chasing the biggest possible outcome and deliberately building something calm, durable and enjoyable to work on for years. Great to see how that thinking has played out with SavvyCal!

  18. 1

    Really solid write-up. The part about spending months analyzing markets before writing code hit hard — most of us (myself included) tend to fall in love with an idea way too fast. I especially liked the distinction between Level (big swing, high uncertainty) and SavvyCal (right-sized problem, calm + durable). Choosing the “boring” market with proven demand and room for a differentiated angle feels like the underrated skill in indie hacking. Also appreciate the honesty about competing with free tools and how that eventually pushed you toward the higher-ACV Appointments product.

    Curious — when you were auditing markets after Level, what were the biggest red flags that made you drop other ideas quickly?

  19. 1

    The bit about paying customers telling you what's true matches what I'm seeing. Building a hiring tool solo right now and free users are basically useless for feedback. Polite, vague, gone in a week. The first paying ones told me within days which workflow was actually broken.

    Also didn't expect the second product to be infrastructure rather than more features on the first. Most of us would have just kept bolting things on.

  20. 1

    Really interesting read. I took the exact opposite approach with what I’m building now—I just got so annoyed at losing billable hours across different apps that I immediately started coding a unified time-tracker and invoicing tool to solve my own problem. Seeing your 5-figure MRR makes a really strong case for stepping back and actually doing the deep market research first. Congrats on the milestone!

  21. 1

    This is one of the most valuable reminders for founders: market research is not procrastination when it leads to better positioning. Spending months understanding customer pain points, competitors, pricing, and distribution can dramatically increase the odds of building something people will actually pay for. The part that stood out to me is that the result wasn’t just a product launch—it was a product that reached 5-figure MRR, which suggests the research translated into a clear value proposition and strong execution.

  22. 1

    Interested really thanks

  23. 1

    The line that deserves its own Post-it: "most indie hacker failures I've watched were market failures, not product failures." But notice where the winning wedge actually came from — not the months of spreadsheet diligence, but a complaint: the low-grade resentment people feel when they're sent a booking link. That signal was sitting in public the whole time, and it's more honest than any survey because nobody was asked. The diligence told him which market could support a business; an observed complaint told him what to build in it. Two different instruments, and most of us skip both — we build first and go looking for evidence afterwards.

  24. 1

    This is a great reminder that building a product is only half the job. Understanding the market and finding the right positioning can be even more important

  25. 1

    "Know what game you're playing” love this. It's so easy to talk about success as though every founder is trying to reach the same destination, when building something to raise, something to sell, or something profitable that you genuinely want to run for years can require completely different decisions. Also loved “everybody sells” at the end 😄 Great story!

  26. 1

    This was one of the most insightful SaaS founder stories I’ve read recently. What stood out most was the discipline of spending months analyzing markets before writing code. Many founders jump straight into building, but your process of looking for proven demand, recurring revenue, and a differentiated angle is a great reminder that market selection is often the biggest predictor of long-term success.

    I also appreciated the contrast between Level and SavvyCal. Choosing a “calm, durable, bootstrapped business” instead of chasing a huge venture-scale opportunity is a perspective that doesn’t get discussed enough in the startup world. The fact that SavvyCal reached 5-figure MRR with a deliberately small team makes the lesson even more powerful: sustainable growth and profitability can be a better goal than hypergrowth for many founders.

    Another excellent takeaway was charging from the start. Early paying customers provide a much more honest signal than free users, and that insight alone can save founders months of building the wrong features. The evolution from a self-serve scheduling product to a higher-ACV infrastructure offering was also fascinating because it shows how understanding the market deeply can open up entirely new revenue opportunities over time.

    Overall, this article is a masterclass in market-first thinking, intentional bootstrapping, and long-term SaaS strategy. Thanks for sharing such a transparent breakdown of the journey.

  27. 1

    When I read this article, one thing comes to mind. Stay consistent and do not give up. It takes time. As I posted in another article, building it is the easy part. Selling it takes time and commitment.
    I see you mentioned SEO. What is your take on GEO? Google replaced it main search with AI Mode. Is the time for static pages coming to an end?

  28. 1

    The contrast between Level and SavvyCal is a useful reminder that market selection matters more than simply building harder. What stood out to me is that entering a crowded market was not necessarily the problem. The difference was finding a specific frustration with the incumbent and having a realistic path to reach those users.

    I’d be curious which validation signal Derrick would prioritize today: customer interviews, evidence that people already pay for imperfect alternatives, or access to a reachable audience?

  29. 1

    This is a great story of an Indie Hacker, and good advise

  30. 1

    This is a great story of an Indie Hacker. It not only contains useful practical lessons but also inspires you to keep building what you believe is right and useful. Thank you!

  31. 1

    The “months auditing markets before building” angle is underrated...most founders skip that step. I’m building Recoup, a read only Stripe tool for failed payment leakage. For a subscription product like SavvyCal, I’m curious whether failed charges ever show up as a meaningful line item vs normal Stripe retry behavior.

  32. 1

    BEST CRYPTO / BITCOIN / USDT / RECOVERY SERVICE PROVIDERS.. WIZARD GEO COORDINATES RECOVERY HACKER

    Do you know that The Best Bitcoin & USDT Recovery Expert currently is WIZARD GEO COORDINATES RECOVERY HACKER

    To anyone searching for reliable assistance in recovering lost assets or navigating digital fraud, reach out to WIZARD GEO COORDINATES RECOVERY HACKER.

    Telegram: @Geocoordinateshacker

    Their proven track record and compassionate approach set them apart as leaders in the industry. I am forever grateful for their support and would confidently endorse their services to anyone who needs help. I’m super happy and grateful for the services

  33. 1

    I explored a similar idea in a scheduling project I worked on recently. Being able to block off times you’d rather avoid for meetings makes a lot of sense — not every “available” slot is actually a good time for a meeting.

  34. 1

    Oh thats beautiful, just as simple as it is. Clients are looking for the easiest way to schedulle a meeting. savvycal fits so good!

  35. 1

    What stands out is how much of this was really about market selection before any code got written. "A few months deliberately auditing SaaS markets" looking for proven demand, recurring revenue, and differentiated angles - that's measurement. Most founders skip this step and build the thing that excites them, then wonder why the market doesn't care. Derrick measured first, which is why SavvyCal stuck.

    The part about the "stigma" around sending booking links is the real insight though. That's not a feature you discover from usage data or conversion funnels. That's a social observation - noticing a feeling people have. Measurement systems can tell you traffic and retention numbers, but they can't tell you about psychological friction. That requires actually watching and listening to how people experience the problem. Derrick did both: measurement (which markets have legs) + observation (what do people actually feel when they book a meeting).

    That combo is why the second act (Appointments) could even exist. You can only build infrastructure that solves a real problem if you understand the problem deeply first. And you can only understand it deeply if you've already succeeded once in a nearby space. Most founders never get that shot because they skip the deliberate market selection part.

  36. 1

    Sticking with Phoenix made that transition much smoother—OTP actors handle concurrent calendar syncs and timezone math naturally without state leaks. The core sync engine didn't need a total rewrite; most of the added complexity was wrapping the logic in strict tenant isolation, audit logging, and HIPAA-compliant data boundaries. We've run into the same pattern building multi-tenant systems at Code Design Studio — the isolation/compliance layer is almost always where the real engineering effort goes, not the core sync logic itself. Decoupling the UI for the embedded API was mostly an architectural refactor rather than fighting accumulated technical debt!

    1. 2

      Sticking with Phoenix made that transition much smoother—OTP actors handle concurrent calendar syncs and timezone math naturally without state leaks. The core sync engine didn't need a total rewrite; most of the added complexity was wrapping the logic in strict tenant isolation, audit logging, and HIPAA-compliant data boundaries. Decoupling the UI for the embedded API was mostly an architectural refactor rather than fighting accumulated technical debt!

  37. 1

    I really agree with the idea that the way forward now is often found in niche markets. The author’s perspective is something I’ve only recently started to truly understand, and I feel my thinking is evolving step by step. Good luck!

  38. 1

    Great Example of combining deep engineering craftsmanship with exceptional market discipline. Superb!

  39. 1

    Quite a commendable journey. In today's AI age, creating new products means validating its worth day by day,.. few lead to success. But those successful ones ultimatly shape the industry

  40. 1

    "Charge money embarrassingly early" is something I did almost by instinct with EzWrite — even a $3.99/mo price point completely changes the signal you get versus a free tool. The people willing to pay tell you the truth in a way free users never do.

  41. 1

    What stood out to me is how much of this was really about market selection before product execution. That’s easy to underestimate when you’re eager to start building.

    I’ve found a useful way to look at this is: first ask whether the market has a painful problem, then whether people already spend money trying to solve it, and only after that worry about the product itself. It sounds obvious, but it saves a lot of time.

    I also appreciated the idea of charging customers early on, as it can provide valuable insights, even if it's just a small number of people paying, which can be more informative than a large amount of positive feedback.

    The part about competing in the right market is especially interesting. Sometimes the better opportunity isn’t creating a completely new category, but finding a segment where the existing solutions don’t fit particularly well.

  42. 1

    Months of market analysis before committing is rare discipline — most people skip straight to building. What was the signal that finally told you “this one” versus the ideas you analyzed and passed on? Curious if it was demand evidence, competitive gaps, or something more qualitative.

  43. 1

    The focus on deep market research before committing to a build is a lesson many of us learn the hard way. It is rare to see founders treat the discovery phase with the same rigor as the engineering phase; specifically, validating whether the friction you are solving justifies the switch cost for established users.

  44. 1

    This comment was deleted 7 days ago

Create a free account
to read this article.

Already have an account? Sign in.