Solo architecture isn't about technology, it's about time
A solo founder has twenty, maybe thirty hours a week for everything: product, support, distribution, billing, themselves. Every hour spent on infrastructure instead of something the customer can see is an hour that rarely comes back. This isn't sentiment — it's the foundation of unit economics for a one-person company.
The temptation to build your own LLM stack — your own RAG pipeline, your own vector DB, your own finetune — comes from technically sound intuition. Vendor lock-in is a real risk. API prices may rise. Open-source models keep getting better. Owning it sounds like the professional choice.
The trouble is that this "professional choice" costs three to six months of a solo developer's time, plus permanent MLOps overhead, plus the opportunity cost of everything not built in that time. In most scenarios, for the same time and money, you'd ship three products on a commodity API and find out which one has actual customer fit. Building your own model is often a form of technical procrastination that occupies your head while keeping you out of conversations with customers.
That doesn't mean it's always wrong. It means the defaults should be reversed: commodity API as the starting position, your own stack as the exception you have to economically justify.
Litmus test: four gates that keep you in the green
Instead of an academic comparison of models and benchmarks, here's a decision tree. Four gates you have to pass through before you even consider your own model. Most projects stop at gate 2 with a clear verdict.
Is the best commercial model "good enough" for your core problem?
The question: can Sonnet 4.6 or GPT-5 over the API solve your task at acceptable quality, such that customers will pay for the result? Concretely — if you measure accuracy, are you above 80% while staying economically viable?
If YES — proceed to gate 2. If NO — you have a uniquely hard problem. Only now can you consider a specific solution. But even then, the first question is "do I have the right prompt?", not "do I need a custom model?".
Is the unit cost of the API sustainable at target scale?
The question: if I had 1,000 or 10,000 paying users, would API costs eat my margin? Is the cost per request a fraction of the value that request generates?
If YES (margin holds) — STOP. Stay on the API. Optimize the product, not the stack. Eighty percent of decisions end here. If NO — you have a legitimate economic reason to proceed to gate 3.
Do you have proprietary data that gives you an edge over the SOTA model?
The question: do you have a clean dataset (in the order of thousands, ideally tens of thousands of high-quality examples) that a finetune could leverage to do something the standard frontier model can't? And do you have the capacity to maintain and grow that dataset?
If NO — you don't have an edge. A custom model will be worse and more expensive than SOTA, because SOTA is trained on multiples of your dataset. Go back to gate 2 and see if you can optimize cost in other ways (cheaper model, prompt caching, RAG over your own data with the API). If YES — this is the 10% case. A finetune of an open-source model (Llama, Mistral) via a managed service is a valid path. Proceed to gate 4.
Do you have a non-negotiable external reason to host yourself?
The question: does your business (GDPR data residency, HIPAA, banking compliance, sub-100ms latency, air-gapped deployment) require running the model on infrastructure you fully control?
If NO — stay with finetuning via a managed service (Hugging Face, Replicate, Together). Self-hosting is the most expensive level and only makes sense where it's forced. If YES — you have a legitimate reason to self-host. But understand that this is a permanent MLOps commitment, not a project.
The tree is intentionally brutal. Most decisions fall on gate 2, and that's where they should fall. If your API economics work, you have nothing to solve. The other three gates are for exceptional cases.
Life on the API: boring, but extremely profitable default
Most of an AI application's value isn't in the model. It's in the data you send into it, the workflow around it, and the UI that turns the output into something usable. The model is commodity. Everything else is your product.
A concrete example from my own stack: cz-agents.dev runs six MCP servers for Czech government data — ARES, ČNB, ISIR, ADIS, sanctions, due-diligence aggregator. Each is a thin layer over public APIs, normalising, caching, and exposing to LLM clients. The Vision AI pipeline at reality.cz-agents.dev pulls structured data out of PDFs through Anthropic Haiku 4.5. No custom model. No GPU. No MLOps. 95% margin.
What creates value here: domain expertise (knowing which fields to extract from an ISIR notice and how to validate them against ARES), schema validation (Zod over the model's output), workflow (cron, queues, retry with escalation), UX (where to trust the model and where not to, where to link the original). All of that is your work. The model is a swappable component.
Vendor lock-in is solved by architecture, not by ditching Anthropic. Specifically: model output is portable. A Vision API from OpenAI or Gemini can be swapped in within a few hours of refactoring, as long as you keep an abstraction layer between business code and the vendor SDK. Lock-in is a risk, but a few-hours-of-work risk, not a multi-month-stack risk.
When the API becomes a millstone
There are legitimate reasons to leave the API. Two main ones: economics that don't scale, and a data moat.
Economics don't scale
The breakpoint is where the API call cost stops being a fraction of the request's value. Concrete math: if Sonnet 4.6 costs ~USD 25 per million output tokens and you push 10,000 requests a day at 2,000 tokens each, that's ~USD 500 per month for one product. If your ARPU is USD 2, the economics don't work. If ARPU is USD 200, it works comfortably.
Where it breaks: B2C apps with heavy per-user usage and low pricing. There a custom model, or at least a finetune of a cheaper one, can make sense. Where it usually doesn't break: B2B with ARPU in the low hundreds of dollars per month. There API economics hold even under intensive use.
Data moat
If you have unique data others don't have — internal company documents from 20 years of operations, domain classifications nobody else has — finetuning a small open-source model on them can produce results the big SOTA model won't reach. The keyword is unique. "Our customer support tickets" are unique only if you have tens of thousands of them, well-tagged. Five hundred unlabeled emails aren't a dataset, they're a lottery ticket.
A practical line: if you can't put together a CSV of 10,000+ cleaned examples in the right format in an afternoon, finetuning doesn't make sense. And even then, the first option is RAG over that data with a large API model, not a finetune.
My P&L: why I haven't done a single finetune yet
None of my production systems use a custom finetuned model. Every time I've considered it, a simple calculation has sent me back to the original plan.
Conservative cost estimate for a first finetune:
- Dataset preparation: 30–60 hours of solo developer time. Cleaning, schema design, tagging, validation. At an economically meaningful hourly rate, that's tens of thousands of CZK in opportunity cost.
- Training and iteration: 20–40 hours of experimentation. Hyperparameters, eval, debug. Cloud GPU costs in the low thousands to tens of thousands of CZK per project.
- Deployment pipeline: 20–30 hours. Inference server, monitoring, rollback strategy, eval pipeline. Plus permanent infrastructure.
- Maintenance: A permanent 5–10 hours per month. Drift, re-training, security patches, debugging production issues.
Alternative for the same time and money: write three more articles in this series, ship two new gov-data integrations for cz-agents, or push reality.cz-agents.dev to the next sales milestone. For a lifestyle business targeting a 95% margin, the choice isn't between "boring API" and "elegant finetune" — it's between "move the product one step forward" and "spend half a year in training loops with no clear business return".
More concretely: a finetune isn't an upgrade. It's a shift of cost from variable (API call per request) to fixed (infrastructure, time, maintenance). For a company with growing revenue, fixed cost is bearable. For a solo founder still searching for product-market fit, fixed cost is a trap. Variable costs scale with revenue and naturally drop in lean months. Fixed costs kill you in lean months.
That doesn't mean I'll never build a custom model. It means that if I do, it'll be after a validated business case, not before.
Closing: build products, not models
Your job isn't to train neural networks. Your job is to solve a problem someone will pay for. The commodity API is the largest leverage a solo founder has ever had on this task — SOTA-quality model with no fixed cost, no MLOps, no six-month implementation phase.
Before you pip install transformers and open a tab on A100 instance pricing, walk the four gates above. Most of you will stop at gate 2. That isn't a sign you're missing something — it's a sign you have a working business that doesn't need premature technical optimization. Optimize the product. Models are commodity. The leverage is in how you use them.
Facing a similar decision in your company? → AI consulting