The Software That Runs My Handyman Company
ENGINEERING
AUGUST 29, 2026

The Software That Runs My Handyman Company

6 min read
BACK TO BLOG

I own a handyman company in Michigan. Every quote, job and invoice runs through software I wrote myself — $216,291 invoiced through it. What I built, how it works, and what it proves.

I own a handyman company in Michigan. A crew, trucks, customers who call when a faucet is still dripping. Every quote it sends, every job it schedules and every invoice it issues runs through software I wrote myself. $216,291 has been invoiced through it.

I did not build it to sell it. I built it because I was sitting at my kitchen table at nine at night with a calculator, splitting a lead's hours from a helper's hours by hand, and getting it wrong.

The problem, precisely

Four things were broken, and only one of them was interesting.

  • Invoicing was manual. Every job's labor and materials tallied by hand. Slow, and wrong often enough to matter.
  • Leads leaked. Angi, the website and plain email had no shared funnel. Some were never followed up, and I could not have told you which.
  • The inbox was the system. Quotes, jobs and customer history lived in email threads. There was no source of truth, there was a search box.
  • Multi-rate billing. This was the one that actually cost money.

The one thing off-the-shelf software could not do

Send two people to a job. One is the lead, on $50 an hour. One is a helper, on $20. They work different numbers of hours. Add materials. Now produce a correct invoice.

Every invoicing product I looked at wanted one labor rate per job. That is a reasonable assumption for most businesses and it is wrong for mine, and no amount of configuration fixes an assumption baked into a data model. So every multi-person job came back to me and a calculator.

What the system does now:

Crew closes out on their phone — lead 2.0h, helper 1.5h, $30 materials. Owner taps approve. The billing engine reads the per-person field hours, applies the per-role rates, and emails a correct invoice. $100 + $30 + $30 = $160. Nobody opened a calculator.

The trick is not the arithmetic. The trick is that the hours are captured at the source, in the field, tagged by role, at the moment the work finishes — instead of being reconstructed from memory by me, later, badly. Get the capture right and the invoice is a consequence rather than a task.

What I built

Two applications against one backend.

The crew side is React Native, because the people using it are standing in someone's driveway. They see their assigned work orders and close them out. On a multi-person job the close-out captures hours per crew member, each tagged lead or helper. That screen exists to capture billing data disguised as a checklist.

The owner side is a React web app: email-driven auto-ticketing, a unified lead pipeline that merges Angi, website and email intake and filters spam, contractor performance, an ROI dashboard, QuickBooks sync, receipt OCR through an LLM's vision model, and Profit First accounting fed by Plaid.

The architecture

Serverless AWS, event-driven, and deliberately boring.

  • Lambda behind API Gateway, one function per capability.
  • Inbound email lands via SES and is parsed into structured tickets and leads. Built to survive a forced email-platform migration, because it already had to once.
  • DynamoDB single-table design for leads, jobs, quotes, contractors and financials — one canonical schema shared by web and mobile.
  • Terraform for all of it, in modules, with CORS generated rather than hand-maintained.
  • Cognito for auth, Plaid into Profit First categorization, QuickBooks for invoicing.

It is AI-assisted end to end. I scoped the business logic and the architecture, then directed AI tooling to build and deploy it. I want to be precise about what that means, because "built with AI" is doing a lot of unearned work in marketing copy right now: the model did not know that a lead and a helper bill at different rates, that a work order becomes a pay record the moment someone's name is on it, or that Angi leads arrive in a format nobody documents. Knowing what the business needed and how the pieces connect was the job. The typing was the easy part.

The numbers

MetricNumber
Money invoiced through the system$216,291
Money collected$191,983
Outstanding more than 30 days$610
Invoices generated334
Jobs processed (253 completed, billed and paid)323
Leads captured and tracked367
Bank transactions auto-categorized3,235
Admin hours removed~140
Engineers1

Jobs, invoices and dollars are actual, pulled from DynamoDB and QuickBooks. The hours-saved figure is an estimate — automated task count multiplied by how long each used to take me — and I would rather label it than let it sit in a table next to numbers that came out of a database. It is conservative, but it is arithmetic, not measurement.

What it does not do

Scheduling is still partly manual, because dispatching a crew around weather and cancellations turned out to be a judgment problem wearing a software problem's clothes. Some of the earliest modules I would build differently today. And the whole thing was built for exactly one business, which is the point and also the limit — it fits Haslett because it was shaped around how Haslett actually runs, not around how home-services companies are supposed to run.

It has also broken in instructive ways. A cleanup cron deleted two men's pay because I never told it that a work order stops being a checklist item once someone is owed money for it. I wrote that one up separately, along with the bookkeeping bug that mislabeled $66,438.97.

What this actually demonstrates

The point is not handyman software. Nobody needs my handyman software.

The point is that I can take a real operation, find where the friction and the money are, design a system that fits how the business actually works, and build and deploy it on modern cloud infrastructure — including the hard, business-specific logic that off-the-shelf tools cannot encode, because encoding it requires knowing the business. Business problem to deployed system, solo, in production, with customers depending on it.

That is the work I do for other people now.

If you are reading this because your own operation is held together with a group chat

Start with the free Operations Audit. Thirty minutes, no charge, and I will tell you where your actual bottleneck is — including the times it is not software. If your problem is a reminder and a template, you do not need a platform, and I will say so. Software should be the last resort, not the first.

If it is worth building, most of my builds land between $2,500 and $10,000, and the pricing is published so you do not spend three calls finding out.

SHARE
6 min read
Read More

MORE ARTICLES

Two ECS failures that produce no useful error
Engineering
Engineering

Two ECS failures that produce no useful error

A readiness probe blocked by the task's own IAM role, and readonlyRootFilesystem silently killing ECS Exec. Both look like broken infrastructure.

How do you know when your AI feature is wrong?
Engineering
Engineering

How do you know when your AI feature is wrong?

Most teams ship an AI feature and have no answer past spot-checking. What an evaluation harness actually contains, and the failure it usually misses.

Don't put a model where you need a reproducible answer
Engineering
Engineering

Don't put a model where you need a reproducible answer

Three systems where I deliberately chose regex and a lookup table over an LLM, and the two questions that decide which one a problem needs.

CLAUDE.md as production infrastructure
Engineering
Engineering

CLAUDE.md as production infrastructure

What a coding agent's context file has to contain when the repos it touches are live, and the day I found the file preventing disasters had no backup.