Solo, 119 micro-sites, 1 year — an honest retrospective

What went better than expected, the surprises, the broken builds, and family time — a first-person look back at one year solo.

When I shipped the first micro-site on bal.pe.kr in April 2024, the honest expectation in my head was something like, "I'll build maybe five tools, and one of them might find a small audience." A year later the count is 119. The number sounds dramatic on a slide, but the inside view is much less dramatic. This is a first-person retrospective of what running 119 micro-SaaS sites alone — while holding a day job and welcoming a first child — actually looked like in practice. It is not a marketing piece. It is the kind of post I wish I had been able to read before launching tool number one.

Most of the sites barely have visitors — and that's fine

The first honest thing to say is that the majority of 119 sites have almost no traffic. Every time I open GA4, the same shape stares back: the top five sites account for roughly 70% of all sessions. More than half of the remaining hundred bring in fewer than a hundred unique visitors per month. The first time I saw this distribution clearly, I felt a wave of "have I wasted my time?" That feeling lasted about a day.

Then a different framing appeared. Those five top sites only exist because the hundred quiet sites underneath them taught my hands the patterns of infrastructure, SEO, AEO, and domain operations. I could not have written bal-pe-kr-rewrite-2 to land a new tool in 30 minutes without first writing, and breaking, the per-tool versions of it. So the quiet hundred are not failures. They are the apprenticeship that made the top five possible.

Unexpected traffic — in Korea, one line of recommendation beats a paid ad

Two unexpected spikes shaped the second half of the year. On 4 May 2026 the yebang vaccination-reminder tool jumped from two or three daily UVs to 138 UVs in a single day. My first instinct was to blame bots, but the GA4 mix included real search traffic and direct visits in roughly equal share. The trigger turned out to be a one-line introduction I had posted on Threads the previous evening — that single recommendation got reshared enough to move the needle.

The next day firekr (a Korean-style FIRE calculator) did the same thing on a smaller scale: 53 UVs in 24 hours, again with no paid promotion. The lesson is specific to the Korean market and worth flagging for any international solo operator considering Korea: a one-sentence recommendation on a Korean-native short-form social platform (Threads KR, X, KakaoTalk open chats, Blind) routinely outperforms a small paid ad. If you build for Korea and ignore those channels, you are leaving a clean leverage axis on the table.

Costs — AWS was predictable, GitHub Actions was not

I expected micro-SaaS to be almost free to run. Reality was more nuanced. The AWS bill (S3 + CloudFront + ACM + Route 53 combined) settled around USD 25–40 per month and barely moves as tools are added. That part went exactly as expected.

GitHub Actions was the surprise. Once site count grew and deploys started running four or five times per day, the free quota disappeared and overage charges began. The fix was to move static-site deploys to microsaas-infra/scripts/local-deploy.sh and run them on a laptop. Beyond the cost savings, an unexpected benefit appeared: when a deploy breaks, it is faster and calmer to re-run it from your own terminal than to scroll through GHA logs in a browser tab.

A second cost decision worth calling out: rather than buying 119 separate domains, every site is a subdomain of bal.pe.kr. That single decision saved roughly USD 800–1000 per year in registrations. The trade-off is real — any domain-level SEO or AdSense policy event affects all 119 sites simultaneously — but for a solo operator the savings are too large to ignore.

The two most expensive mistakes

First, provisioning a fresh CloudFront OAC and Lambda Function for every site. Six months in, the bill had climbed sixfold and the cause was hidden inside identical-looking line items. Consolidating onto a shared bal-pe-kr-rewrite-2 Function plus a single static-shorts-oac returned the bill to a flat baseline. Every new site now attaches to those shared resources by ARN reference rather than re-creation. That standard is now in our shared operator memory at the level of muscle reflex.

Second, the CDK BucketDeployment invalidation timeout. Bundling five sites in a single CDK stack triggered an invalidation timeout mid-deploy, freezing the stack into UPDATE_ROLLBACK_FAILED. The recovery happened at 3 a.m. on a Sunday: continue-update-rollback --skip, then a manual S3 sync, then a direct boto3 invalidation. The takeaway: when you run a fleet of 100+ sites, two or three recovery procedures have to be in your hands as reflex, because they will be needed in the middle of the night when nothing else is open.

Family balance — the first child as a turning point

There is one more honest detail. Our first child was born on 27 May 2025. For the rest of that year, the baby's first sounds were objectively more important than any site. The reason 119 was still possible during that period comes down to two things.

The first is that once infrastructure is standardised, a new site takes 30 minutes of focused work, which fits inside the cracks of a parent-of-a-newborn's day. The second is learning to put things down without guilt. The biggest enemy of a side project under parenthood is not inefficiency — it is ambition. One person who genuinely finishes one tool per quarter ends up further ahead, one year later, than one person who starts five tools per week. That asymmetry only gets clearer with time.

The kinds of tools we shipped also changed. Weaning-stage guides, infant developmental milestones, vaccination reminders. None of that came from market analysis. It came from the keywords I was searching from my own phone at 4 a.m. The cliché — build for yourself first — turns out to be technically correct.

One more GA4 finding — bot traffic was 30–40%

Average daily active users across the fleet during April and May 2026 hovered between 250 and 400 — but on 8 May we discovered that 30–40% of that was bot traffic with a US / Netherlands / Seychelles desktop-direct signature. Since then, every analysis runs with bot exclusion enabled (--no-bots).

Real-user numbers after bot exclusion look smaller, and the first reaction is mild disappointment. But accurate numbers are the only basis for accurate decisions. We once made a poor ad-spend decision on top of bot-inflated data, which we don't intend to repeat. A note for fellow Korean indie operators: that desktop-direct bot signature appears to be a fleet-wide pattern, not site-specific. We do not block the bot IPs at the CloudFront / WAF layer — excluding them from analytics is sufficient, and blocking adds an operational burden that delivers no marketing value.

The biggest asset year one left behind

If someone asked me to name the single biggest thing I took away from year one, it would not be 119 sites. It would be the instinct for what not to build. At the start, every tool was something that had to be created from scratch. Today, 80% of a new site is shared components configured by props. Time stops leaking. Output continues even during weeks when the day job and family demand everything.

The goal for the next twelve months is not a higher number. It is to take the top five or ten sites that already reach real users and, slowly and honestly, sharpen them. New launches will drop to one or two per quarter. Sites like yebang and firekr will get a second, careful pass at their user experience.

Five surprises year one delivered

To close out, here are five operational surprises the year delivered — the things I genuinely wish I had known before launching tool number one.

First, one well-written post can outweigh one new tool. The yebang spike of 138 UVs in 24 hours was not the result of new code; it was the result of a single Threads recommendation. Thirty minutes of writing produced more traffic than six hours of building. A reasonable split for a solo operator might be 70/30 code-to-writing — a year of running 119 sites makes this conclusion hard to avoid.

Second, AdSense reviews are sensitive to structural uniformity in posts. When all 24 blog posts followed the same H2 tree, reviewers became suspicious of automated generation. The cure was deliberately varying tone across five new posts (retrospective, Q&A, data analysis, self-interview, build notes). Tone diversity may matter more than word count for AdSense approval, which was not at all obvious to me twelve months ago.

Third, CloudFront Functions have a hard limit. The v1 shared function hit its association cap, and new sites cannot attach to it anymore. Moving early to v2 prevents a sudden deploy block. This belongs in operator memory as a permanent standard.

Fourth, the operator cannot mentally hold all 119 sites at once. I can recall 30–40 in a single sitting. The rest require searching the catalog. This is not a flaw — it is the natural state of distributed micro-SaaS. Stop trying to keep them all in your head.

Fifth, the day job feeds the side project more than the other way around. It is easy to see how lessons from side projects flow into work. The reverse is larger and quieter — only someone who handles AWS infrastructure daily at work can run 119 sites at USD 25–40 per month. Year one made it obvious that the day job is the side project's biggest asset, not the other way around.