When I launched my first micro-SaaS tool in the spring of 2024, I did not believe that one year later I would be running 119 of them. My honest expectation at the time was something like, "I will build maybe five, and one of them will find a small audience." But once the infrastructure standardised, each new tool took only four to six hours from idea to live URL, and the annual total quietly crossed the three-digit threshold. This retrospective is an attempt to write down what a solo operator actually learns from running 119 micro-SaaS sites for a year — the expensive mistakes alongside the highest-leverage moves. Most of the audience for this post is a non-Korean solo builder thinking about the same path, so I have translated the Korean operator-context where it matters: the AWS regional infra, the local search-engine quirks (Naver vs Google), the AdSense thresholds, and the cultural difference of "share a single sentence on Threads and watch traffic spike" that does not always exist in Western markets.
The headline numbers from year one
- 119 live tools (104 oriented to the Korean market, 34 international, some overlap)
- Solo operator, with a separate day job in AWS / backend engineering
- Average time-to-launch for a new tool: 4–6 hours (after infrastructure was standardised)
- AWS infra cost: roughly USD 25–40 per month (S3 + CloudFront + ACM + Route 53)
- Traffic distribution: the top 5 sites carry roughly 70% of all GA4 sessions
- First AdSense payout (USD 100 threshold) reached after about six months
- 2025-05-27: our first child was born — the operating rhythm of the second half of the year reorganised itself around this date
The number 119 sounds dramatic, but the inside view is much less dramatic. The cadence was roughly one hour before work, one to two hours after the baby went to sleep, and two to three hours on a weekend morning. Around ten hours a week, on average. That is not a heroic time budget. The only reason the count grew is that infrastructure standardisation and the discipline of not building things both compounded.
The five most expensive mistakes
1. Provisioning a new CloudFront OAC and Function per tool
Every early site was given its own CloudFront Origin Access Control and CloudFront Function. The domain was the same. The origin pattern was the same. Only the resources multiplied. About six months in, the AWS bill had grown sixfold, and the cause was buried inside identical-looking line items. Consolidating onto a shared bal-pe-kr-rewrite-2 Function plus a single static-shorts-oac brought the bill back to a flat baseline. We learned the hard way that the v1 shared function eventually hit a soft limit; every new site since then attaches to v2 by ARN reference, not by re-creation.
Lesson: if the domain is the same, share the OAC and the Function. About 90% of the infra has no per-site reason to differ.
2. Burning through the GitHub Actions free quota
When deploys started happening four or five times a day, the GitHub Actions free minutes evaporated and the billing started. The fix was almost embarrassingly simple: static-site deploys really only need an aws s3 sync plus a cloudfront create-invalidation. Both run fine on a laptop. The whole pipeline got moved to microsaas-infra/scripts/local-deploy.sh and never moved back. The unexpected side benefit was psychological — when a deploy breaks, it is faster and calmer to re-run from your own terminal than to scroll through GHA logs.
3. CDK BucketDeployment invalidation timeouts
Bundling five or more sites in a single CDK stack triggered invalidation timeouts that froze the stack into UPDATE_ROLLBACK_FAILED. The recovery — at 3 a.m. on a Sunday — was to continue-update-rollback --skip and then run the S3 sync manually. After that, every site got its own CDK stack, and invalidations are now called directly via boto3.
4. Missing i18n metadata
For a few early sites, the English title and description fields stayed empty for six months. That cost us half a year of international search traffic. The fix is a lint script that fails the build when any locale metadata is missing. A tiny safety net, but at the 100-site scale it is the difference between a fleet that ranks and a fleet that silently does not.
5. Copy-pasting tool code across eight sites
This was a sin from the legacy Korean pool. Identical component trees were duplicated across eight sites. When a bug appeared in one, the other seven kept the bug. The cure was a shared package (microsaas-shared) with prop-injected variations. Today, roughly 70% of a new site is the shared package configured with props, which is the reason the four-to-six-hour build budget is realistic.
The five biggest leverage moves
1. Subdomain + repository per tool
Instead of bal.pe.kr/{tool} paths, every tool lives at {tool}.bal.pe.kr with its own GitHub repository. One decision solved four problems: build isolation, deploy collision risk, SEO separation, and AdSense slot management. A broken build on one site no longer impacts the others.
2. Shared infrastructure (CloudFront / ACM / S3)
One OAC + one Function + one ACM certificate now serves all 119 sites. The new-site cycle dropped from six hours to thirty minutes. Once the infra is standardised, the cost of going from five sites to a hundred is roughly linear in content, not in infrastructure. That is the real meaning of "micro" in micro-SaaS.
3. AEO first — llms.txt across the fleet
After standardising llms.txt on every site, the citation rate from ChatGPT and Perplexity (measured by GA4 referrer) climbed about 27%. That is still a small share of total traffic, but it is durable. It depends on a different signal — clean machine-readable summaries — that does not rise and fall with Google core updates. Pairing SEO with AEO from day one is the single cheapest insurance policy a solo operator can buy.
4. The seven-person work-pool team for big campaigns
Every quarter we run one large improvement campaign. That campaign does not happen by one operator clicking 119 sites by hand. Instead, we dispatch Claude Code agents in a structure of one architect, five workers, and one reviewer running in parallel. The Q2 2026 campaign — a fleet-wide SEO and AEO upgrade — finished in two weeks rather than two months.
5. Data-driven Sunday retros
Every Sunday morning, thirty minutes goes to GA4 + Search Console + per-tool usage logs. 80% of effort that week goes to the top 5 tools. The remainder is on maintained autopilot. After discovering on 8 May 2026 that bot traffic (a US / Netherlands / Seychelles desktop-direct signature) was inflating GA4 by 30–40% on some sites, every analysis now runs with bot exclusion (--no-bots). We made one bad ad-spend decision on bot-inflated numbers — we will not make it twice.
Operator checklist (10 items)
These are the items I personally verify when launching any new site.
- [ ] No new OAC / Function created for the new site (shared ARNs only)
- [ ]
llms.txtis generated from the sitemap automatically - [ ] Build fails if any locale metadata is missing
- [ ] Local deploy script is the default path (GHA only as fallback)
- [ ] One CDK stack per site
- [ ] Common components come from the shared repo, never copy-pasted
- [ ] Weekly GA4 + GSC report is generated automatically
- [ ] Top-5 sites have 99.9% SLA monitors
- [ ] AEO citation rate is checked monthly
- [ ] A quarterly retrospective is written publicly
Advice for would-be solo SaaS builders
- Make the first tool something you personally use every week. This is the single best decision an indie builder can make. It fixes motivation, attention to detail, and the willingness to debug all at once. You don't need user interviews — you are the interview.
- Standardise infrastructure before tool number five. From the sixth tool onwards, the new-site cycle should be effectively cloneable. If you have not standardised by then, you will plateau.
- Ship SEO and AEO together from day one. Generate
llms.txtalongside the sitemap. AI search is a small but durable share of traffic, and early indexing compounds. - Use a local deploy script. GitHub Actions minutes are a trap once the fleet grows.
aws s3 syncandaws cloudfront create-invalidationare perfectly happy on a laptop. - Score, prioritise, retro. Make every decision leave a data trail. Six months later you will be a different operator looking at the same dashboard, and you will need the data more than you think.
Related tools
The one-sentence summary after 119 tools
If you forced me to compress one year of operating 119 micro-SaaS sites into a single sentence, it would be: deduplicate, automate, measure. Skip any of those three and the fleet stalls at site five. Get them right and the cycle from site five onward is roughly constant, which is the only reason 100 is possible at all. The goal for the next twelve months is not to grow the number — it is to let the top five to ten sites quietly reach the users who need them. I'll come back to write another retrospective at that point.