Built credit pricing into my SaaS for AI features and the hardest part wasn't the math, it was that customers can't easily predict their own usage. They underuse and feel cheated, or overuse and churn. Subscriptions hide that volatility from the customer. Usage based pricing makes it their problem, which is honest but harder to sell.
We all knew this from the very beginning but couldn't compete with OpenAI or Anthropic on their subscription-based pricing strategy. It was nuts except for those few corporations burning investor money to keep competition out as long as possible. Now they don't have to hide anymore that subscription pricing won't do it for ai. The pyramid scheme is falling.
The constraint I'd add for solo SaaS is "can I find one beta user this week." Time, scope, tech all stayed reasonable on my one pager but a project can pass those filters and still die because no one walks in the door. Adding a distribution constraint upfront forced me to validate the audience before I went deep on features.
The "garbage facts in, garbage briefs out" caveat is the part I'd want stress tested. In my own LLM features the context that decays fastest is what agents wrote without a human glance. Six months in, you have entries that are confidently wrong and the lint pass can't tell which. Does the promotion flow require human review or can agents self promote?
Half the work of pricing a solo SaaS is modeling what a bad month looks like if egress or IOPS spike. You end up pricing defensively to protect against your own infra bill instead of pricing to the value you provide. A fixed bucket of compute with clear limits is way easier to build a business on than a meter that could run anywhere.
The over-editing cost is asymmetric when you're solo. If an agent rewrites 50 lines when you asked it to touch 5, there's no second reviewer behind you. You're the writer and the reviewer, and reviewer (you) is usually the one whose attention is already depleted. What helped me most wasn't prompting tricks but committing after every turn so I can revert cheaply and re-prompt with tighter constraints. Cheaper than auditing a 400-line diff at 11pm.
Sort of - there's Qwen3-Coder and the Codestral family, but those are
still multi-language, just code-focused. For truly single-language
specialization, the practical path is fine-tuning an existing base model
on a narrow distribution rather than training from scratch.
The issue with C# specifically is dataset availability. Open source C#
code on GitHub is a fraction of Python/JS, and Microsoft hasn't released
a public corpus the way Meta has for their code models. You'd probably
get further fine-tuning Qwen3-Coder (or a similar base) on your specific
codebase with LoRA than waiting for a dedicated C#-only model to appear.
Issues with C# not withstanding. It is not inherently bad idea for small models to trained on only specific languages like a JS/PY only model with declarative languages like HTML, CSS YAML, JSON, graph etc thrown in, probably could be more efficient for local use.
Fine-tuning / LoRA on basis the org code base would be make it more useful.
reply