How to build a modern distributed SaaS from scratch, completely with AI agents — Aulinq Blog · Aulinq<br>← Back to blogHow to build a modern distributed SaaS from scratch, completely with AI agents<br>2026-08-01·14 min read·A<br>AulinqAuthor

·AI Agents<br>#ai-agents#saas#architecture#building-in-public

Starting another SaaS in 2026 is a strange thing to do. The discourse says the category is saturated, that AI flattened every moat, that the only things left worth building are wrappers around a frontier model with a nice landing page. I read those takes and I mostly agree with the diagnosis and completely disagree with the conclusion. The wrappers are exactly what dies first. What's left is the boring, hard-to-copy infrastructure underneath — the multi-tenancy, the billing, the cost control, the secrets handling, the idempotency across redelivery — and that work has not gotten cheaper just because the model got smarter.

This is the story of building one of those. It's called Aulinq. It's a multi-tenant, multilingual AI agent platform: the thing that answers a customer on Telegram, WhatsApp, or web chat, routes the conversation through the cheapest model that can actually handle it, charges the tenant per token in fractions of a cent, and keeps every tenant's data and secrets walled off from every other tenant. Three product tracks sit on top of that plumbing — a white-label path for agencies reselling agents to their clients, an API for startups embedding agents in their own product, and a single-tenant onramp for a solo founder who just wants a working bot without the infrastructure PhD. The production system is several Go services, one Postgres, one Redis, and a NATS JetStream bus. I am the only engineer, and I have a full-time job.

That last part is the thing people actually want to know about. How do you ship a distributed platform solo while employed? The honest answer is two things, and neither of them is "I code fast." The first is that I stopped coding solo and started orchestrating a team of AI agents — a planner, an implementer, a reviewer, a verifier, each with its own context and its own tools. The second is that I stopped trying to do this in daily one-hour increments. A weeknight hour is enough to review a diff, approve a plan, or watch a verifier run. It is not enough to research a stack decision, draft an architecture, or pull a failing service out of a drifted state. Those need a block of uninterrupted attention, and for me that block is Saturday, and the occasional Sunday when the family is out.

So the method and the operating model depend on each other. The weekend batch is where the thinking work happens — the research loops, the architecture iterations, the library gap-filling, the agent rules. The weeknights are where the small verify-and-merge tasks happen. Mixing them up is how you end up with a half-researched stack choice made at 11 PM on a Tuesday, which is the exact failure mode this method is designed to avoid.

This article is that method, written down. Not the polished version — the version with the dead ends and the rollbacks left in, because those are the parts that actually teach it. It assumes you're already a competent engineer. The agents don't replace that. They amplify whatever judgment you bring, and they amplify bad judgment just as fast.

The stack question isn't "what's popular"

The first thing an AI coding assistant will do when you ask "what stack should I use for a distributed SaaS" is give you the most popular answer. Python. FastAPI. Postgres. Redis. Maybe Kafka if you say "event-driven." This is the correct answer for a tutorial and frequently the wrong answer for a system that other AI agents are going to extend for the next two years.

The popular stack is popular because it's legible to the most people. Legible to the most humans is not the same as legible to the most agents. Agents don't benefit from a large ecosystem of tutorials — they've already read them. They benefit from a type system that rejects their mistakes, a runtime that fails loudly, and a deployment artifact with the fewest moving parts to get wrong.

I ran the stack question through deep research, not a chat. Four or five iterations: first a broad survey, then narrowing on the two or three options that survived, then a deep read on each, then a cross-check against a second model to catch the bias of the first. The pattern I followed for every consequential decision in this project, not just the stack. It's slower than asking once. It's faster than asking once and rebuilding in month four.

Go won. Not because it's popular in the AI-agent-tooling sense — it isn't, Python dominates that — but because a Go compiler turns a class of agent mistakes into build errors instead of 3 AM stack traces. When the agent adds a field to an event struct and forgets to update a consumer, the build fails. In the Python equivalent, the consumer silently deserializes to None and you find out in production.

The...