From idea to $5k MRR: an AI micro-SaaS teardown

The idea: how we found it

We didn't have a clever insight. We had a client. A regional restaurant chain with 23 locations was spending four hours a week having a marketing coordinator manually respond to Google and Yelp reviews. The coordinator had a rough template for positive reviews and a rough template for negative ones, but every response had to be personalised enough to not look like a copy-paste job. It was exactly the kind of work that should have been automated three years earlier.

The first version took four hours to build. We created a Make.com scenario that watched for new Google Business reviews via a polling webhook, passed the review text and the location details to Claude with a prompt that matched the chain's voice and response policy, and posted the draft response to a Slack channel for approval before publishing. The coordinator went from writing responses to approving them. Four hours per week became thirty minutes.

The client asked if we could do the same for their other locations and whether we could handle Yelp and TripAdvisor. We asked how much they'd pay for it as a standalone tool. They said $300 a month without hesitation. That was the signal we needed.

Building v1: the fastest possible thing

V1 was not a SaaS product. It was a Make.com workflow with a configuration form. Customers filled in a Typeform with their brand voice guidelines, response policy, and the review platforms they used. We set up the Make.com scenario manually for each customer using their provided configuration. Billing was manual Stripe payment links. There was no dashboard, no user account, no automated onboarding.

This approach let us start charging before we'd written a single line of product code. The first three customers paid $250-350 per month before we'd built anything beyond the workflow. This was the validation signal — not 'would you pay for this hypothetically' but 'here's a Stripe payment link, pay now and we'll set it up tomorrow.' Two out of the first three people we pitched paid. That's a 67% conversion rate on a product that didn't exist.

The limitation of the manual approach became obvious by customer five. Each new customer took 90 minutes to set up, and the scenarios were fragile because they weren't built for maintainability — they were built for speed. We had five slightly different versions of the same workflow, and when we updated the Claude prompt for one customer, we had to manually update it for all five. That was when we started building the actual product.

Pricing: the mistakes and what fixed them

Our initial pricing was location-based: $25 per location per month, minimum 5 locations. This seemed logical — the value scales with location count. In practice, it created sales friction. Restaurant operators aren't used to per-location SaaS pricing, and explaining the model took time. Some prospects wanted to pilot with one location before expanding. The per-location minimum blocked them.

We switched to three tiers: $149/month (up to 5 locations), $299/month (up to 15 locations), and $499/month (unlimited locations). This was a standard SaaS tier structure that prospects understood immediately. Conversion improved. The $299 tier was the most popular — most regional chains have 5-20 locations, and it gave them room to grow without hitting the next tier immediately.

The revenue impact of the pricing change was immediate. Monthly sign-ups nearly doubled in the month after the switch, and the average revenue per new customer increased because the flat-tier structure nudged prospects toward the tier that fit their location count rather than the minimum. The pricing model is a product decision, not just a finance decision — the wrong pricing model creates friction that good features can't overcome.

“We made $6,000 before we wrote a single line of product code. The workflow was the product. The product came after the revenue.”

What nearly killed it: the Google API problem

Two months in, Google updated its Business Profile API and the webhook integration we were using stopped working. Not gradually — it stopped working overnight, for all customers simultaneously. We had 18 paying customers, none of whom could receive new review notifications. Our support inbox filled up in hours.

We'd built the integration on top of a third-party service that was itself built on the Google API. When Google changed the API, the third party's service broke, and we found out from customer complaints rather than from monitoring. We had no early warning system. We had no fallback. We had no incident communication plan.

We fixed it by switching to a direct polling integration against the Google Business Profile API, which was more reliable than the webhook approach. We built a monitoring workflow that checked for new reviews every 15 minutes and alerted us if the check returned an error for any customer. We created a status page. We sent an honest post-mortem to all customers explaining what happened and what we'd changed. We lost one customer. We retained seventeen. The ones who stayed said the communication made the difference.

Growth: how we got from 0 to $5k MRR

The first three customers came from the original client's network. Restaurant operators know each other, and a genuine referral from someone in the industry carries more weight than any marketing campaign. We asked every customer to introduce us to one other operator who might benefit. Not a formal referral program — just an ask in conversation. About 40% followed through.

The second channel was LinkedIn content. We posted a case study of our first customer's results — three months of data on response time, response rate, and review volume — with all identifying information anonymised. The post got traction in the restaurant operator community and generated eight inbound inquiries in a week. We converted three. Content about results outperforms content about features.

We hit $5k MRR in month three with 19 customers at an average of $263 per month. Churn was low — two customers in three months, both for reasons unrelated to the product (one location closed, one was acquired). The product's retention was good because it was deeply embedded in a daily operational workflow. Tools that handle a daily operational need are stickier than tools that provide insight — customers notice immediately when an operational tool goes away.

The lessons that apply to any AI micro-SaaS

Find the problem before building the solution. We didn't have a product idea and then look for customers. We had a client with a problem, solved it, and then found more clients with the same problem. The narrow niche wasn't a limitation — it was the advantage. 'AI review management for restaurant chains' gets you in the door with exactly the right people. 'AI productivity tool' gets you nowhere.

Charge before you build. The validation that matters is payment, not feedback. Surveys, user interviews, and pilot requests tell you that people find your idea interesting. A payment tells you they need it. If you're building a service — even a tech-enabled one — you can charge before automation exists and do it manually first. Build automation when manual execution is breaking your capacity.

The operational fragility of AI-powered products is real. Your product will fail in ways that traditional software doesn't — API changes, model behaviour changes, content policy updates, unexpected inputs. Build monitoring, alerting, and a communication plan before you have more than five customers. The customers who stick around through an incident are the ones who see how you handle it.