All articles

Building The Defined CRM: a SaaS for home service businesses at $1.7K MRR

October 1, 2026 by Ade

  • case study
  • SaaS
  • React
  • Node.js
  • React Native
  • AI development
  • Stripe

The Defined CRM is my own product. It’s a multi-tenant SaaS for home service businesses: cleaning companies, window cleaners and similar trades. It’s live in production at thedefinedcrm.com, it reached $1.7K in monthly recurring revenue in early 2026, and I’m still actively building it.

I’m writing this up for founders who are deciding who should build their app. A client project shows you how someone works with a brief. Your own product shows you how someone works when they’re paying for every decision themselves.

What the product does

A home service business runs on a loop: win the customer, quote the job, schedule it, do it, get paid, and get the next customer. The Defined CRM covers that loop.

  • Win work: leads, campaigns, Mailchimp, Facebook Lead Ads, AI-drafted Google Ads, and postcards and texts to neighbors after a completed job.
  • Quote and sign: estimates with e-signature, and contracts.
  • Schedule: scheduling, recurring jobs, crews and a route optimizer.
  • Do the work: clock-in with face verification and liveness checks, timesheets and payroll.
  • Get paid: invoices, recurring invoices, Stripe Connect payouts to each business, and Stripe Terminal so crews can take card payments at the door.
  • Answer the phone: a phone number per company, missed-call text-back, and an AI voice receptionist built on OpenAI Realtime and Twilio.
  • Understand the business: plain-English reports over a SQL warehouse, an AI website builder, and an MCP server with 30 scoped tools so AI clients can operate the CRM.

That’s a lot of surface area, so I want to be clear about what it is. This is not a first version. It’s what a product looks like after a year and a half of steady building on top of one. The scale today is roughly 550,000 lines of code across the web app, API, mobile app and AI services, about 800 API routes and 103 backend service modules.

What I built first and why

I started the backend in April 2025, the web app in July 2025 and the mobile app in August 2025.

That order was deliberate. In a multi-tenant product, the backend is where the expensive mistakes live. Every record belongs to a company, and every query has to be scoped to that company. If that rule is enforced in one place from the start, it holds. If it’s bolted on later, you spend months finding the places where one business can see another business’s data.

The web app came next because the office side of a home service business, the owner doing scheduling, quoting and billing, is where the buying decision gets made. The mobile app came after that, because crews in the field need a smaller set of things: their jobs, clock-in and taking payment.

The stack follows the same thinking. I picked tools I could move fast with and that wouldn’t need replacing:

  • React and TypeScript for the web app
  • Node and Express for the API, on Heroku
  • Firestore as the main database, alongside Redis and Algolia
  • Expo and React Native for the mobile app, so one codebase covers iOS and Android
  • A Python FastAPI service on AWS, deployed with Docker and Terraform, for the AI features

Reporting is where the main database stopped being the right tool. Owners want to ask questions like “which crew had the most completed jobs last month,” and Firestore isn’t built for that kind of query. So data flows from Firestore through Pub/Sub and Redis Streams into MotherDuck, a SQL warehouse, and the plain-English reports run there. That’s more moving parts, and the tradeoff is that reporting doesn’t slow down the app people are using to run their day.

What I’d leave out if this were your MVP

If a founder brought me this idea today and wanted to launch in about eight weeks, most of that feature list would wait. My cut would be the core loop for a single business: customers, estimates, scheduling, invoices and getting paid. Multi-tenant scoping would be in from day one, because it’s cheap to start with and expensive to add.

The voice receptionist, the warehouse, the website builder, the MCP server and face-verified clock-in are good features. In my view, none of them is the reason a business signs up in its first month, and every one of them is easier to build well once the core loop is in real use.

How it makes money

The pricing has two parts.

Monthly plans: Starter at $49, Professional at $79, Enterprise at $149 and Defined at $349 a month.

Usage billing for things that cost money each time they run, like address lookups and postcards.

I split it this way because some features have a real cost every time a customer uses them. Charging a flat fee for something like mailed postcards means either overcharging light users or losing money on heavy ones. Usage billing keeps the plans simple and keeps those costs covered.

Stripe Connect matters here too. Each business gets paid out directly, which is what home service businesses expect, and it puts the CRM in the middle of how they get paid, not off to the side as another app.

That model is at $1.7K MRR as of early 2026.

How one developer builds this much

I built The Defined CRM with AI doing a large share of the coding, and with a workflow designed so that doesn’t turn into a mess. My estimate is that AI-assisted development cut development time by about 60%. Here’s what that workflow looks like:

  • Tests first, and I approve them. For each change, AI writes behavior tests in a Given-When-Then format. I read and approve those tests before any implementation is written. This is where I spend my judgment: deciding what the software should do.
  • Written rules in every repo. Each repository has a CLAUDE.md file with the architecture rules and the pitfalls specific to that codebase. The most important one is multi-tenant scoping: every query has to be scoped by companyId.
  • Git hooks. Hooks require tests to pass and require conventional commit messages, so nothing skips the process on a busy day.
  • A review agent. A custom review agent checks each diff against the known traps for this codebase and only reports issues it has verified, so I’m not wading through false alarms.
  • Bug reports that turn into pull requests. When a user reports a bug in the app, it goes to a bug-fixer built on the Claude Agent SDK. It writes a fix on a branch, runs the tests and opens a pull request. A human reviews every one before it merges.

The point of all this is that AI writes code fast, but it doesn’t know your business rules unless you write them down, and it doesn’t check its own work unless you make it. The tests, rules and reviews are what make the speed safe to use.

How working with me goes

If you hire me, you get this same workflow on your product.

We start with the loop your customers care about and agree on what’s in the first version and what waits. I write down the rules that matter for your app, like who can see which data, before the code that depends on them. You approve what the software should do in plain language, as behavior tests, before it gets built. And we talk about pricing and how the app makes money early, because that shapes what gets built.

I offer three packages:

  • Prototype in a week for $2,500, to put something real in front of users.
  • MVP in about 8 weeks from $15,000, for a first version you can launch and charge for.
  • Monetization audit for existing apps, $750, if your app has users but the revenue isn’t where it should be.

There’s a shorter summary on the Defined CRM case study page. If you’re deciding who should build your app, get in touch or book a free 30-minute call and we’ll work out what your first version should include.