All Articles

I'll be honest up front: writing about my own work is uncomfortable. I'd rather show you the code than tell you it's good. So this post is a build log, not a pitch. If you take one thing from it, I hope it's not "use my app." I hope it's "you might not need that subscription."

I build Pheidi alone. It's an adaptive running training app: you tell it your race, your schedule, your history, and it builds and rebuilds a plan around your actual life. One founder, no employees, no contractors. That constraint shapes every technical decision I make, and the biggest one is this:

When I need a capability, my default is to build it into the app, not subscribe to it.

That used to be bad advice. "Don't build your own X" was right for most of my career, because developer time was the scarcest thing a small company had. But the math changed. With AI coding assistants, a focused feature that used to take a week takes an afternoon. Code got cheap. Subscriptions didn't.

Here are three things people usually rent that I built instead, with real numbers from the codebase.

1. The feedback system

The standard advice for collecting user feedback is to embed a tool like Canny, UserVoice, or Intercom. They're good products. They also start around $79 a month, ask my users to load a third-party widget, and put my most valuable data, what runners actually want, inside someone else's database.

Here's what I built instead:

  • A feedback form that slides out from the navbar. One Razor component, 197 lines. Bug or feature request, title, description. It captures the current page URL automatically so I know where the user was.
  • A POST /api/feedback endpoint and a 44-line service that saves the submission to a FeedbackSubmissions table.
  • An email to me, fired in the background after the save, with the type, title, description, page, and the user's email.

That's the whole system. Around 300 lines for the core.

Notice what's missing: there's no admin dashboard. I never built one. Every piece of feedback lands in my inbox, where I already live. Email gives me triage (archive), prioritization (star), and follow-up (reply) for free. If I ever need to analyze trends, the data is sitting in my own SQL database, one query away. A dashboard for a feedback volume of "one founder reading every message" would be decoration.

The one design choice I'd point at: the save happens first, the email happens second, fire-and-forget. If the notification fails, the feedback is already safe in the database. Boring, but it means I can't lose a user's words to an SMTP hiccup.

2. The email autoresponder

This is the one where people spend real money. Mailchimp, ConvertKit, Customer.io: the moment you want a welcome email, a drip sequence, and behavioral triggers, you're into tens or hundreds of dollars a month, and the price climbs with your list.

Pheidi sends five kinds of email, all from code I wrote:

  • Welcome email, sent right after first signup, with links to setup and the docs people need on day one. Reply-To is my personal inbox, so answering it starts a real conversation with me, not a ticket queue.
  • Morning workout reminder, sent at 5 AM in each runner's own timezone. It includes today's workout, the pace target, and a heat adjustment note pulled from the live weather forecast. A background service sweeps every 10 minutes and sends each user at most one per day.
  • Training phase emails, triggered when a runner crosses from base into build, build into peak, peak into taper. An hourly scan with per-plan deduplication so each phase fires exactly once.
  • Day-3 check-in, which asks a different question depending on whether you built a plan yet. If you didn't: "what got in the way?" If you did: "what do you think?"
  • Day-14 nudge, only if you made a plan but haven't logged a workout.

The whole thing, schedulers, templates, deduplication, eligibility windows, is about 1,200 lines of C#. The templates are plain HTML strings in code. The deduplication is atomic conditional updates in SQL, so even if I scale to multiple app instances, nobody gets the same email twice. Unsubscribe is one click and RFC 8058 compliant, so Gmail shows its native unsubscribe button; I didn't want to build email people resent.

I'm not pretending delivery is free. Azure Communication Services actually sends the mail, and I pay per message: fractions of a cent. That's the line I draw, and I think it's the useful general rule: rent infrastructure, build the workflow. Delivery, DNS, hosting? Rent it; that's commodity plumbing with real economies of scale. But the logic of who gets which email and when? That's product. That's the part the subscription products charge you hundreds for, and it's the part that was never hard. It was just tedious, and tedious is exactly what AI-assisted coding removed.

There's a quieter benefit too. Because the email logic lives next to the app code, my morning emails can do things a generic platform can't, like reuse the exact same weather-adjustment engine that the in-app plan uses. The email and the app never disagree, because they're the same code.

3. The agentic tools

This is the newest one, and the one I'd push hardest on if you're building right now.

People are buying "AI features" the way they bought analytics dashboards: as a bolt-on SaaS layer between them and their own data. I think for solo builders that's mostly backwards. You can spend a few dollars of API tokens and give an AI agent raw access to your actual database and your actual product. No middleware, no per-seat pricing.

Two things I built:

An MCP server inside the app. Pheidi exposes eight tools over the Model Context Protocol: get today's workout, list the upcoming week, record a run, report an injury, add a vacation, update your profile, submit feedback, fetch the active plan. Any MCP-capable assistant (Claude, for instance) can connect, and a runner can manage their training by talking: "I felt a twinge in my left calf on today's run, log it and ease off this week." The assistant calls report_injury and record_workout, and the plan adapts the same way it would if they'd tapped through the UI.

The hard part wasn't the tools; those are 418 lines. The hard part was authentication: a proper OAuth 2.1 flow with PKCE and dynamic client registration, so an assistant can connect to a user's account without me hand-issuing API keys. That was roughly 500 lines and a lot of RFC reading. It was also a one-time cost, and now any agent platform that speaks MCP works with Pheidi without me writing an integration for it.

The same trick, pointed at myself. Remember the feedback system with no dashboard? When I want to understand what users are asking for, I don't open an analytics product. I point a coding agent at my own database and ask. "Summarize the feature requests from the last month and group them by theme" costs me a few cents of tokens against data I already own. Every SaaS dashboard is ultimately a fixed set of someone else's queries with a UI on top. An agent with raw access is every query, including the ones nobody pre-built.

What I'm not claiming

I want to be careful here, because "just build it yourself" is easy to say and easy to overdo.

This works for me because I'm one person at a manageable scale. If you have a team, a shared SaaS tool's permissions, audit trails, and onboarding might be worth every dollar. If you're sending a million emails a month, deliverability becomes a profession, not a feature. And there are things I would still never build: payments, raw email transport, hosting. The rule is rent infrastructure, build workflow, and infrastructure is bigger than it looks.

The maintenance is also mine forever. When the day-3 check-in email has a bug, there's no support ticket to file; there's just me. So far that trade has been fine, because 300-line systems with no dashboard have very little surface to break. But I keep them small on purpose.

The actual point

I didn't set out to avoid SaaS on principle. I set out to run a one-person company without drowning, and I noticed that every subscription is not just a bill; it's a dashboard to check, a login to manage, an integration to maintain, an export to worry about. Twenty tools is a part-time job in overhead before any of them do anything for you.

The reason this is newly possible is not that I'm a great programmer. It's that the cost of focused, boring, well-understood code collapsed. A feedback form, a drip campaign, an OAuth flow: these are solved problems, and AI assistants are extremely good at solved problems. The expensive part was always the typing, and the typing is cheap now.

So before you reach for the credit card, it's worth asking the question I now ask every time: is this product, or is it plumbing? If it's plumbing, rent it. If it's product, it might be an afternoon of work to own it outright, with your data in your database, doing exactly what your app needs and nothing else.

That's the whole lesson. The app, if you're curious what all this plumbing serves, is Pheidi, a training plan that adapts to your life. But honestly, build the feedback form first.