Build vs. buy in 2026: how a solo dev replaced 6 SaaS tools with ~$100/mo of AI

John Farrell — Mon, 15 Jun 2026 14:18:13 +0000

Cross-posted from pheidi.training. This is the dev cut — same decisions, more code and auth detail.

Most build-vs-buy advice is stale. For most of my career, "don't roll your own X" was just true: engineering time was the bottleneck, so you rented anything that wasn't your core product. In 2026 the bottleneck moved. A focused feature that was a week of typing is now an afternoon of prompting and reviewing. So I started re-running the calculation, and I keep landing on build.

Some context: I'm the only person on Pheidi, an adaptive running-training app. The stack is ASP.NET Core + Blazor, C#, Azure SQL. You hand it a race, a schedule, and your history; it generates and continuously re-plans around your real life. No team, no contractors. Every architectural call gets filtered through "can one person own this forever?"

Let me start with the number that reframes the whole post: my entire AI bill — the assistant I pair with plus the tokens my agents spend — is roughly $100/month. The SaaS stack it displaced (feedback, email automation, analytics, an AI-features layer, plus a couple of stragglers) would each, individually, cost about that same $100. Bundle six of them and you're at 3–4× my total spend, indefinitely, with the price ratcheting up at every renewal.

Three categories everyone rents. Here's what building them looked like.

Feedback: 300 lines instead of $79/mo

The default is to bolt on Canny, Intercom, or UserVoice. Solid tools — but they open around $79/month, inject a third-party widget into my UI, and store the single most valuable signal I have (what runners are asking for) on infrastructure I don't control.

My version is three pieces:

A slide-out feedback panel in the navbar — one Razor component, 197 lines. Type, title, body, plus the originating page URL grabbed automatically.
POST /api/feedback backed by a 44-line service that persists to a FeedbackSubmissions table.
A background notification to my own inbox after the write.

Total: ~300 lines, and conspicuously no admin dashboard. That omission is the feature. Every submission shows up in email, where I already triage, star, and reply all day. If I ever want aggregate views, it's a SQL query against data I own — not a report someone else decided to expose.

The only decision worth flagging is ordering: persist first, notify second, and never let the notification block.

await _db.FeedbackSubmissions.AddAsync(submission);
await _db.SaveChangesAsync();        // durable before anything else
_ = _notifier.SendAsync(submission); // fire-and-forget; an SMTP blip can't eat feedback

Lose the email? Annoying. Lose a user's words? Never.

Email automation: ~1,200 lines instead of a per-contact bill

This is the budget line people actually feel. Mailchimp / ConvertKit / Customer.io get expensive the instant you want a welcome, a drip, and behavioral triggers — and the meter runs on list size.

Pheidi sends five flavors, all hand-rolled:

Welcome at signup, Reply-To set to my real inbox so a reply is a conversation, not a ticket.
5 AM workout reminder in each runner's own timezone — today's session, pace target, and a heat tweak computed from the live forecast. A hosted service sweeps every 10 minutes, capped at one per runner per day.
Phase transitions (base→build→peak→taper), scanned hourly, deduped per plan.
Day-3 check-in that branches on whether you've built a plan yet.
Day-14 nudge if you have a plan but zero logged runs.

The whole scheduler/template/eligibility layer is ~1,200 lines of C#. The piece I'd actually show another dev is the dedup. No queue, no distributed lock — just an atomic conditional UPDATE that's safe across multiple app instances:

UPDATE Plans
SET PhaseEmailSentUtc = @now
WHERE Id = @planId AND PhaseEmailSentUtc IS NULL;  -- @@ROWCOUNT == "did I win the race?"

@@ROWCOUNT = 0 means another instance already sent it, so I bail. The database is the coordination primitive. Unsubscribe is one-click and RFC 8058-compliant, so Gmail surfaces its native button.

Here's the boundary I don't cross: actual delivery. Azure Communication Services puts mail on the wire and charges me fractions of a cent per message. That's the rule I'd hand anyone — rent the infrastructure, build the workflow. Transport, DNS, hosting are commodities with genuine economies of scale. But which human gets which message and when is product logic, and that's precisely what the SaaS marks up. It was never hard. It was tedious, and tedious is the thing AI assistants vaporize.

Side effect of co-locating the logic: my 5 AM email calls the same weather-adjustment code as the in-app plan. They literally cannot drift, because they're one implementation.

Agentic tools: a few dollars of tokens instead of an AI middleware tier

Newest category, and the one I'd argue hardest for today. The reflex is to buy "AI features" as a layer that sits between you and your own data — the analytics-dashboard pattern, reborn. For a solo dev that's inverted. Spend a few dollars of tokens and let an agent touch the real database and the real product directly. No middle tier, no per-seat tax.

Built thing #1: an MCP server inside the app. Eight tools over the Model Context Protocol — get_today_workout, list_upcoming_workouts, record_workout, report_injury, add_vacation, update_profile, submit_feedback, get_active_plan. An MCP client like Claude connects and the runner just talks: "calf felt tight on today's run — log it and back me off this week." That fans out to report_injury + record_workout, and the plan re-plans identically to the UI path.

The tools themselves were trivial — 418 lines. The real work was auth: a full OAuth 2.1 + PKCE flow with dynamic client registration, so an assistant can attach to a user account without me minting API keys by hand. Call it ~500 lines and a stack of RFCs, but it's paid once. Every current and future MCP client now works with Pheidi with zero per-vendor integration on my side.

Built thing #2: the same idea aimed inward. No feedback dashboard, remember? When I want product signal I point a coding agent at my own DB — "cluster last month's feature requests by theme" — for pennies of tokens against data I own. A SaaS dashboard is a frozen set of someone else's queries with chrome on top. An agent with raw read access is every query, including the ones nobody thought to pre-build.

The honest caveats

"Just build it" is overcorrectable, so the boundaries matter:

This scales down, not up. With a team, a tool's RBAC, audit log, and onboarding can be worth every cent. At a million sends a month, deliverability is a job title, not a feature.
Some things I will never own: payments, raw mail transport, hosting. Rent infrastructure, build workflow — and "infrastructure" is a bigger set than it looks.
The maintenance is permanently mine. A bug in the day-3 email has exactly one assignee. That's been fine precisely because ~300-line, no-dashboard systems have almost no surface area. I keep them small deliberately.

The takeaway

Every subscription is more than a charge. It's another dashboard, another login, another integration to babysit, another export to fret over. Twenty of them is a part-time ops job before any of them earns its keep. And they compound quietly: $29 + $79 + ... each defensible alone, several hundred a month together, forever, for features that barely speak to each other.

My ~$100/month buys the opposite shape: code I own outright instead of rent that only climbs. The reason this works now has nothing to do with me being a strong engineer — it's that focused, boring, well-trodden code (a feedback form, a drip engine, an OAuth dance) got cheap, and assistants are excellent at well-trodden problems. The cost was always the typing.

So the question I now ask before every purchase: product, or plumbing? Plumbing → rent it. Product → it might be an afternoon to own it, with your data in your database, doing exactly what you need and not one thing more.