We've shipped 100+ apps. The five categories that consistently produce real revenue, the three that keep dying in the App Store, and the unit economics behind both.
We've shipped over 100 production apps in the last decade. A small number of them turned into real businesses. Most of the rest taught the founder something useful and were quietly retired. The pattern between the two groups is not what most founders expect.
Here are the five app categories that consistently produce revenue in 2026 — and three that keep collapsing in the App Store no matter how good the build is.
The pattern: pick a specific trade — pest control, HVAC, mobile dog grooming, septic service, dance studios — and build the back-office software they actually need. iPad in the truck, route optimization, invoicing, recurring billing, technician dispatch.
Why it works: these trades are operating on Excel, paper invoices, or a generic CRM that wasn't built for them. They are willing to pay $50–$500/month per location for software that fits the exact workflow. ARR per customer is high, churn is low, and the moat is the depth of vertical knowledge — not the technology.
What the build looks like: native iPad/iPhone for the technician, web for the office, payments via Stripe Connect, scheduling that respects real-world routing constraints. We've shipped several of these. The successful ones invested heavily in the unglamorous parts — payroll integration, QuickBooks export, and multi-tenant permissions — that the founder didn't realize would be the deciding feature.
Unit economics: $200/mo per location, 95% gross margin, $1,500 CAC at trade-show acquisition, 8-month payback. Boring on a slide. Excellent in a P&L.
The pattern: a company with 50–500 field employees who do not sit at desks. Pest control techs, AC repair, healthcare home aides, in-home cable installers, freight drivers. The current solution is paper, a clunky enterprise app, or a Slack channel.
Why it works: these workforces touch revenue directly. A 5% efficiency gain per technician compounds across the fleet into seven figures of margin per year. The buyer (operations VP or CIO) has a clear ROI calculation. The contract size is enterprise. The technology is, frankly, not that hard.
We built Aptive's five-summer field-sales app on this pattern. Native iOS, AWS backend, real-time route optimization, offline-first because field reps lose signal. Aptive is now a ~$300M ARR business and that app handled summer scaling spikes that would have killed a Heroku trial.
Telehealth itself is overcrowded and regulated to the moon. The successful adjacent plays are:
These avoid the "telehealth user-acquisition death spiral" because the buyer is the provider or payer, not the patient. CAC is paid by an enterprise; the app rides existing distribution.
What's hard: HIPAA compliance is real, BAAs are real, and any AWS architecture you ship needs to be audit-ready from day one. We carry these patterns into every healthcare engagement (CloudTrail enabled, encryption in transit and at rest, dedicated VPC, patient data isolated from the analytics path).
Consumer subscriptions die in general. They thrive in niche obsessions where the user is genuinely passionate. Examples that worked in our portfolio or in the broader market:
The key is not "consumer subscription." The key is "obsession." If your TAM cares about the topic enough to wear a hat about it, the LTV math works. If you're building "another fitness app," you're competing with a market that has already eaten Calorie King's lunch and isn't done.
Pricing in this lane is $4.99/mo to $9.99/mo with a 7-day trial. ARPU is small but compounding. Pursue this lane only if you have a content moat (Duolingo's curriculum), a hardware moat (Peloton's bike), or a real obsession-community moat (Strava's social graph). Pure software-only consumer subscriptions without one of those three rarely scale past $1M ARR.
The cleanest revenue lane in app development. The user of the app is an employee at a company who can expense it. Examples:
The unit economics here are trivial compared to consumer subscriptions: $20–$100/seat/month, multi-seat deals, expense-account-friendly pricing, and the buyer's IT department renews because removing it would cause a revolt.
The build is usually unsexy: forms, lists, sync, offline, integrations. The product is excellent unsexy plumbing.
Social apps require both critical mass and a real network-effect mechanism. Most "Instagram for X" pitches have neither. The few that work (BeReal, Threads at Meta scale) had a structural advantage we don't replicate by building harder. We turn down most "social" pitches in the strategy call.
The total addressable market that wants a Web3 consumer app is, charitably, small and getting smaller. The infra plays still produce revenue (custodial wallets, B2B compliance tooling). The user-facing apps have not, with rare exceptions. We've built a few. The ones that produced revenue were the B2B infra ones, not the consumer-facing dApps.
The market is in a brutal commodity squeeze. ChatGPT, Claude, Perplexity, and Gemini are eating the "general AI assistant" lane and have margins to burn that no startup can match. Vertical AI agents — like the ones we ship on AWS Bedrock + AgentCore for specific workflows — produce revenue. Generic chat apps don't.
The question to ask, before "should I build this app?" is:
If you have clean answers to those four, the build is the easy part. We can ship the build in 30 days. The four questions above take longer to answer than the app takes to build — and getting them wrong is the most expensive mistake in this category.
The Lehi strategy session is free. Bring the four answers. We'll tell you which of the five lanes you're really in.
# keep-reading
Deterministic code beats LLM calls on cost, latency, and reliability for most 'AI' use cases. Here's how we decide which 20% stays.
Our internal pre-submission checklist. ~95% first-try approval rate on ~120 submissions. Rejections are rarely technical — they're policy.
$ ready to start
30 minutes. You leave with a scoped MVP plan, a fixed-price quote, and an AWS architecture sketch.