October 16, 2026

We're Building a Mobile App for HyppoCRM

Listen to this post

0:00 / 5:15

HyppoCRM is getting a real mobile app. Why: fragmented systems cost you leads, Slack-style integrations are glue that fails, and most of our users run their business from a truck, not a desk. How: one backend, two doors in, no sync, and Claude writing and testing most of the code while I architect and review.

HyppoCRM is getting a mobile app. Not a shrunken website in a wrapper. A real app, same data, same brain, built for a phone held in one hand between jobs.

I want to walk through why, and then the part I actually find interesting: how it's getting built, because the answer to that is different than it would have been a year ago and it changes what my job is.

Fragmented systems are a tax you pay every day

Ask any owner of a service business to show you how a lead becomes a paid job. Watch them open the ad platform, then the form tool, then the CRM, then the calendar, then their texts, then the invoicing app. Six logins. Six places the lead can fall through a crack.

A small business owner at a desk surrounded by nine glowing screens, each a different app shouting a notification, sticky notes bridging between them — This isn't a tech stack. It's a liability with a monthly bill.

Every one of those seams costs something. Time, obviously. But also the lead that got replied to in the wrong system, the appointment that didn't make it to the calendar, the invoice that went out for the wrong amount because the quote lived somewhere else. I built HyppoCRM in the first place to collapse all of that into one system, one database, one source of truth. The mobile app is the same idea carried into your pocket.

Slack-style integrations are not the answer

The industry's fix for fragmentation is "integrations." Connect everything to everything. Webhooks, sync jobs, a Zapier account with forty zaps nobody remembers building. Every app gets a Slack-style notification feed and we call it connected.

A server room with dozens of app boxes connected by a hopeless tangle of glowing cables labeled webhook, sync and integration, several unplugged and sparking — Every cable is a place it can break. Most of them do, quietly, on a weekend.

It's a mess, and I say that as someone who built a company on APIs and loves them. Integrations between products you don't own are glue, and glue fails. The sync runs late. A field gets renamed on one side. A token expires. And because the failure is a sync job that didn't run, nobody finds out until a customer does. You end up spending more time maintaining the connections than using the tools.

The alternative is boring and correct: one system that owns the data, with the pieces that need to talk to the outside world (Twilio for texting, Stripe for payments) living inside it, not bolted to the side. That's how HyppoCRM is built. The mobile app doesn't integrate with it. It is it.

Most of our users would rather be on their phone

Here's the thing I underweighted for too long. The people using HyppoCRM aren't at desks. They're cabinet installers, roofers, exterior crews, law firm staff running between meetings. The laptop is in the truck. The phone is in their hand.

A cabinet installer in the cab of a work truck tapping a lead reply on his phone, with a closed laptop gathering dust on the passenger seat — Where the work actually gets managed. The laptop has not moved in a week.

A lead comes in at 2pm. The owner is on a job site. If replying means "I'll do it when I'm back at the computer," that lead is going to somebody faster. A real mobile app, with push notifications, a one-tap call back, a text thread, the calendar, and the pipeline, means the business runs from wherever the owner is standing. That's not a nice-to-have for this market. It's the product.

How it's built

Here's the architecture, and it's deliberately simple.

Architecture diagram: a mobile app and a web app both feeding into one API, backed by Postgres with row level security, alongside Twilio, Stripe and push notification services, captioned same backend, no sync — The phone and the browser are two doors into the same house. There is nothing to keep in sync.

The mobile app and the web app hit the same API. One backend, Postgres underneath with row level security so every tenant's data is walled off at the database level, not just in the app code. Twilio handles texting, Stripe handles money, push notifications ride alongside. No second database for mobile. No sync job between "the app" and "the real system." If a lead's status changes on your phone, it changed, period, and the person at the desk sees it immediately.

Multi-tenant from day one, because HyppoCRM is a platform our clients run their businesses on, not a single-company tool. That's a decision you make at the start or pay for forever.

Who's writing the code

Now the part that's actually new. A year ago, "we're building a mobile app" meant hiring a mobile developer or two, a few months of work, and a budget that would make a small business flinch. That math changed.

Diagram of a build loop: an architect sends a spec into a cycle where Claude writes code, runs tests on a phone simulator and fixes, then a report goes back up to review and ship — I write the spec and review the output. The loop in the middle runs without me.

Claude writes most of the code. It also tests it. It runs the app in the simulator, taps through the flows, checks that the lead actually saved, that the push notification actually fired, that the OAuth flow actually completes. When something breaks it fixes it and tries again. Then it hands me a report, and I review it the way I'd review a pull request from a senior developer: skeptically, with the architecture in my head. I've written about that loop before, and the mobile app is the biggest thing I've run through it yet.

Two consequences. First, cost. The same app that would have been a six-figure line item is a fraction of that, which means we can build it right instead of building a cheap version and apologizing for it. That saving shows up for our clients, not just for us.

Second, my job changed. The CTO used to be the best engineer in the building, writing the hardest code. Now the seat is worth more than ever, but for a different reason. I'm the architect and the overseer. I decide how the system is shaped, what the data model is, where the walls go, what "done" means. Then I review what comes back and catch what the machine missed, and it does miss things. Edge cases, the weird customer flow, the thing that's technically correct and practically wrong. Human in the loop, with the leash getting longer every quarter.

I've got more going on behind the curtain right now than I can talk about yet. This isn't that. This is the thing I can talk about, and it's shipping.

The takeaway

Fragmented systems cost you leads. Integrations between products you don't own are glue, and glue fails. Your people are on their phones, so the system should be too. One backend, two doors in, no sync.

And the way it's getting built is the part worth paying attention to: AI writes and tests the code, the human architects and reviews it, and the whole thing costs a fraction of what it did eighteen months ago. That's not a prediction. That's what's happening on my desk this week.

More when it's in your hands.