The Single Serving Application

About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.

I recently had two AI models build a complete Harvest clone in under 20 minutes. The winning version covered 97% of Harvest's features. I'm seriously considering canceling my $180/year subscription and using it instead.

That experiment got me thinking about something bigger than one app replacement. We're entering an era where a competent engineer with an AI coding assistant can generate a fully functional web application from a requirements document in the time it takes to eat lunch. That changes the economics of software in a fundamental way.

I'm calling this new category the Single Serving Application (or SSA).

What is a Single Serving Application?

An SSA is a purpose-built application designed for an audience of one: you. It replaces a SaaS product you're currently paying for with a private, AI-generated equivalent that runs on your own infrastructure, serves only your needs, and costs nearly nothing to operate.

The name is a nod to the single-serving friends from Fight Club. These applications are permanent, purpose-built, and entirely yours.

The key insight is this: the vast majority of SaaS complexity exists to serve thousands of other customers. When you strip away everything that exists to serve other people, what remains is a simple application.

The Complexity You're Paying For

Think about what a typical SaaS product needs to support that you, as a single user, do not:

Multi-tenancy. Every SaaS application must isolate data between customers. This means user_id and organization_id foreign keys on virtually every table, row-level security policies, tenant-aware caching, tenant-scoped API keys, and careful query scoping to prevent data leaks. In an SSA, there is no tenancy. Every row in every table is yours. The entire database is yours. This alone eliminates an enormous category of complexity and an entire class of security vulnerabilities.

Authentication and identity. SaaS products need user registration, email verification, password hashing, password reset flows, multi-factor authentication, session management, OAuth integrations, enterprise SSO via SAML and OIDC, role-based access control, team invitations, and permission hierarchies. An SSA skips all of this. You authenticate with a client certificate: install it on your laptop, your phone, and your tablet, and any device without the certificate simply cannot connect. Mutual TLS provides strong security, requires zero user interaction after initial setup, and eliminates the entire identity management surface area.

Scalability infrastructure. SaaS products need load balancers, auto-scaling groups, read replicas, connection pooling, CDN distribution, multi-region failover, message queues for async processing, and caching layers to handle thousands of concurrent users. An SSA serves one concurrent user: you. A single AWS Lambda function behind API Gateway handles your traffic with ease. Traffic spikes and capacity concerns do not apply. Redis, message brokers, and horizontal scaling all become unnecessary. The infrastructure collapses to almost nothing.

High availability. SaaS products promise 99.9% or 99.99% uptime via redundant infrastructure across multiple availability zones. This requires health checks, automatic failover, blue-green deployments, and on-call engineering teams. If your SSA goes down for five minutes while you're asleep, the only affected user can simply wait. You can deploy with zero-downtime aspirations and single-AZ simplicity, because the blast radius of an outage is exactly one person.

The Feature Tax

Beyond infrastructure, SaaS products carry an enormous feature tax: code that exists purely to serve the multi-user, multi-tenant, commercial business model.

That table represents tens of thousands of lines of code in a typical SaaS product. You indirectly pay for all of it through your subscription, and none of it needs to exist in an SSA.

The Architecture of an SSA

When you strip away all of that complexity, the architecture becomes lean:

┌─────────────────────────────────────┐
│          CloudFront (CDN)           │
│     + Client Certificate Auth       │
├──────────────┬──────────────────────┤
│   S3 Bucket  │   API Gateway        │
│  (Frontend)  │  + mTLS Validation   │
│              ├──────────────────────┤
│              │   Lambda Function    │
│              │  (Entire Backend)    │
│              ├──────────────────────┤
│              │   DynamoDB or        │
│              │   SQLite on EFS      │
│              └──────────────────────┘
└─────────────────────────────────────┘

Frontend: A static React (or even plain HTML/CSS/JS) build deployed to S3 and served via CloudFront. CloudFront handles TLS termination and can enforce mutual TLS, requiring the client certificate before serving any content.

Backend: A single Lambda function that handles all your API routes. For a typical SSA replacing a tool like Harvest, this function will handle maybe 20-50 API endpoints. Lambda's 15-minute execution limit and 10GB memory are absurdly generous for a single user's workload.

Database: DynamoDB for serverless simplicity, or SQLite mounted on EFS for relational needs. Either way, a single table or a single database file. Connection pooling, read replicas, and failover all become irrelevant. For a single user generating maybe 100 database operations per day, even the most minimal database configuration is wildly over-provisioned.

Authentication: Mutual TLS (mTLS) via client certificates. Generate a certificate authority, issue client certificates for each of your devices, configure CloudFront and API Gateway to require them. Any request without a valid certificate gets rejected at the edge before it ever reaches your application code. Passwords, token refreshes, and session management all disappear.

Infrastructure as code: The AI that writes your application can also write the Terraform configuration to provision all of it. Lambda functions, API Gateway, DynamoDB tables, S3 buckets, CloudFront distributions, ACM certificates, Route 53 records: the entire infrastructure stack can come from the same conversation that produces the application code. One prompt, one terraform apply, and your SSA is live.

What This Costs

Let's do the math for a typical SSA running on AWS:

Under a dollar a month. Compare that to the SaaS subscription you're replacing: $10/month for a simple tool, $15-30/month for something like a project manager or CRM, $180/year for Harvest. The SSA pays for itself in the first month and then essentially runs for free.

Even if you double or triple the infrastructure for comfort (add a proper RDS instance, enable CloudWatch logging, set up daily backups to S3 Glacier), you're still looking at $5-10/month. A rounding error compared to a SaaS subscription.

What You Give Up

SSAs involve real tradeoffs:

You're the ops team. When it breaks at 11pm, you fix it yourself. For engineers, this is usually fine. For non-technical users, this is a dealbreaker.

No automatic feature development. SaaS products ship updates constantly: bug fixes, new features, performance improvements, all delivered without you lifting a finger. An SSA only gets better when you (or your AI) actively improve it.

No mobile apps. Most SaaS products have native iOS and Android apps. Your SSA is just a web app. Actually, scratch that. The latest version of Xcode fully supports vibe-coding native iOS, macOS, and even visionOS applications. My workflow is to put the iOS app folder alongside the web app folder, point the AI at the web app's functionality, and tell it to duplicate or sync the features into the native app. It does the rest. You get a real native app (with the same data model and the same features) built from the same requirements document. This is no longer a tradeoff.

Data migration is on you. Getting your data out of the SaaS product and into your SSA requires effort. Some products have good export APIs. Others make it deliberately painful. Budget time for this.

No collaboration. The moment you need to share access with a second person (a business partner, an accountant, a spouse), you're back to needing authentication, permissions, and multi-user considerations. An SSA is definitionally single-serving. The moment it serves two users, it becomes a self-hosted app, and the complexity creeps back.

When an SSA Makes Sense

The best candidates for SSA replacement share a few traits:

• Single-user tools where you're the only person who touches the data
• CRUD-heavy applications (time tracking, expense management, invoicing, bookmarks, note-taking, habit tracking, personal CRM)
• Tools with straightforward data models that an AI can fully implement from a requirements document
• Subscriptions that feel expensive relative to the features you actually use
• Tools where data sovereignty matters: your financial records, client information, health data, or anything you'd rather keep on your own infrastructure

The candidates that come to mind immediately, organized by category:

• Time tracking and invoicing: Harvest, Toggl, Clockify, FreshBooks, Wave
• Project and task management: Todoist, Things, TickTick, Basecamp (solo use), Trello (personal boards)
• Note-taking and knowledge bases: Notion (solo use), Evernote, Obsidian Publish, Bear, Roam Research
• Bookmarks and read-later: Pocket, Instapaper, Raindrop.io, Pinboard
• Personal finance: YNAB, Mint, Lunch Money, Copilot Money
• CRM for freelancers and solopreneurs: HubSpot (free tier), Dex, Clay, Monica
• Habit and fitness tracking: Habitica, Streaks, Strong, Fitbod
• Recipe and meal planning: Paprika, Mealime, Plan to Eat
• Password management: 1Password, Bitwarden (self-hosted is already common here)
• Home inventory and asset tracking: Sortly, Encircle, Home Assistant integrations
• Writing and publishing: Ghost (solo blog), Substack (if you don't need the network), Medium (for drafting)
• File sharing and transfer: WeTransfer, Dropbox (personal), file.io
• URL shortening and link management: Bitly, Short.io, Dub
• Email newsletters: Buttondown, ConvertKit (solo creator use)
• Analytics: Plausible, Fathom, Umami (lightweight site analytics)

When an SSA Doesn't Make Sense

• Collaboration-first tools (Slack, Figma, Google Docs), where the whole point is other people
• Tools with proprietary algorithms (Grammarly, Shazam, AccelaStudy AI), where the value lives in the model itself
• Tools with large datasets (mapping, stock data), where maintaining the data yourself is cost-prohibitive
• Tools where the network is the product (LinkedIn, marketplace apps), where a single-user version serves no purpose
• Tools requiring complex hardware integration (IoT platforms, specialized sensor apps) where the hardware SDK is the hard part
• Anything where downtime has real consequences. If your tool being unavailable for an hour costs you money or clients, pay for the SaaS and their SLA.

The Requirements Document is the Product

The fundamental shift with SSAs: the deliverable is the requirements document, not the code.

When I built the Harvest clone, I wrote a requirements document and handed it to an AI. The AI produced a working application. If I lost the code tomorrow, I could regenerate it in 20 minutes from the same requirements document. The code is ephemeral. The requirements are the durable artifact.

This inverts the traditional relationship between specification and implementation. In conventional software development, the code is the product and the spec is a planning artifact that gets stale. In SSA development, the requirements document is the product. The code is a disposable rendering of that document, regenerated as needed, potentially by a different AI model each time.

This means:

• Version control the requirements, not just the code. The requirements document is your source of truth.
• Iterate on the requirements, not the code. Want to add a feature? Update the requirements document and regenerate.
• The requirements document is portable. It lives independent of any framework, language, or model. Today you generate a React/Flask app. Tomorrow you might generate a Swift app for iOS. The requirements stay the same.

Getting Started

If you want to try building your first SSA:

1. Pick a SaaS tool you're paying for that you use alone and that does something relatively straightforward.
2. Write a requirements document. Be specific about the data model, the pages/views, the workflows, and the edge cases. The more precise the requirements, the better the AI output.
3. Hand it to your preferred AI coding assistant with instructions to build a Dockerized full-stack application. Start with Docker Compose for local development.
4. Import your data. Export from the SaaS product and write an import script (or have the AI write one).
5. Run it locally for a week alongside the SaaS product. Validate that it does what you need.
6. Deploy to AWS. Convert the Docker setup to Lambda + S3 + DynamoDB (or keep it as a lightweight container on ECS/Fargate if you prefer). Add mTLS for authentication.
7. Cancel the subscription.

The entire process, from requirements document to running SSA, should take an afternoon. The data migration is usually the hardest part.

The Bigger Picture

The SSA represents a philosophical shift in who software serves.

For the last 15 years, the SaaS model has been the dominant paradigm: pay a monthly fee, use the software, trust the vendor with your data, accept the features they choose to build, live with the pricing they choose to set. This model works well for many scenarios, particularly collaborative tools and complex platforms.

For single-user productivity tools (the apps that help you track your time, manage your finances, organize your notes, and run your freelance business), the SaaS model has always been a compromise. You pay for multi-tenancy you do not need, subsidize infrastructure designed for thousands of users, trust a third party with data you could easily manage yourself, and accept a feature set designed by committee rather than tailored to your specific workflow.

That last point deserves emphasis. An SSA goes beyond replicating the SaaS product's features; it lets you add features that only matter to you. Features the SaaS vendor would never prioritize because you're the only person who wants them. In my Harvest clone, I added a "Fill Month" button that populates 8 hours of time for every workday in the current month for a given project. One button press replaces 20+ manual time entries. It saves me significant time every month, and it's the kind of hyper-specific workflow optimization that a SaaS product serving thousands of customers would never build. When the application serves an audience of one, your feature requests have a 100% approval rate.

AI-generated code changes the equation. The barrier to building a custom application has dropped from "months of engineering effort" to "an afternoon with a requirements document." The barrier to operating it has dropped from "a devops team" to "a Lambda function and a credit card."

The tools are here. The cost is negligible. The only remaining question is whether you'd rather rent software or own it.

I know which one I'm choosing.

This post was drafted by me and expanded with Claude. The concept, opinions, architecture, and cost analysis are mine. Claude helped me articulate them more clearly, which is, itself, a demonstration of the thesis.