Format note. This post is written as a self-interview: an operator questioning the operator. The Q is a fictional interviewer; the A is the author. The intent is to answer honestly, without polishing. A few interview requests arrived during year one of running 119 micro-SaaS tools, and they were declined for time reasons — which left the operator with a set of unanswered questions internally. This piece exists to finally answer them.
Topic 1 — The day job
Q. You hold a full-time job. What do you do there?
A. I work as a backend / AWS engineer at a Korean tech company. The day job sits surprisingly close to the side projects technically — the infrastructure patterns I touch at work apply directly to micro-sites, and the automation and standardisation instincts I develop on the side feed back into the quality of my work. If this two-way flow ever breaks, I think both sides would stagnate.
Q. How do you find the time for 119 sites alongside a day job?
A. It is less about finding time and more about making each site cost less time. With infrastructure standardised, a new site takes 4–6 hours on average. That budget splits into one hour before work, one or two after my child sleeps, and two or three on a weekend morning — which is enough for one or two new sites per week. Over a year that compounds to nearly a hundred. The key is not "six hours all at once every week" but "six hours that decomposes into small enough pieces to fit between life events."
Q. Has the day job ever conflicted with the side projects?
A. Direct conflict has been minimal — I follow my company's side-project guideline and never use work resources on personal sites. The conflict is energetic, not policy-based. On days with a full-day incident at work, I cannot write a single line of side code. I accept this and rest instead. Realising early in year one that "every day" is a dangerous illusion was the most important guardrail.
Topic 2 — Why micro-tools instead of a real SaaS
Q. The orthodox path for a solo developer is to grow one real SaaS. Why did you spread to 119?
A. Three reasons.
First, billing, taxes, and customer support would have multiplied the day-job load. Once a SaaS accepts payment, refunds, support tickets, and tax filings all become the operator's responsibility. With family and the day job as priorities, that weight was too much to take on at the same time.
Second, Korea has a surprising number of empty slots for tools that do not need payment — vaccine schedules, comprehensive-wage validity checks, fortune-telling traditions, infant weaning stages. Filling those slots was more interesting than chasing a single recurring-revenue product. Free tools with ads remove friction for users and remove pressure from the operator simultaneously.
Third, distribution reduces risk. When one site disappears from a search index, the other 118 keep the operation running. During the September 2024 Google Helpful Content update, one of our sites lost its index ranking — and the existence of the other hundred kept my mental state intact. If I had bet everything on a single SaaS, that quarter might have ended the entire project.
Q. Will you ever try a real SaaS?
A. Honestly, yes. One goal for next year is to slowly sharpen the top 5–10 sites, and if one or two of them naturally evolve into something users will pay for, billing and support will be accepted at that point. But I will not start with "I am building a SaaS." I prefer to discover the SaaS that users themselves request through "I would pay if you added this feature." A SaaS the market asked for and a SaaS the operator pre-decided to build have completely different one-year survival rates.
Q. What do you lose by not running a real SaaS?
A. There is no MRR curve to display, no chart that compounds visibly in a pitch deck. AdSense alone does not draw a meaningful growth line. Year-one ad revenue across all 119 sites totalled around USD 200–400 — effectively zero in business terms. But what I gain outweighs what I lose: freedom, specifically the freedom to stop. A real SaaS makes stopping difficult because of promises to paying users. A micro-tool with ads can pause tomorrow without harming anyone. For a solo operator with a family, that is the most valuable freedom available.
Topic 3 — Family
Q. Your first child was born during year one. How much did it affect the operation?
A. Born on 27 May 2025. For the six months after, new launches almost stopped — the available time at a keyboard simply was not there. But I do not see that period as a stagnation. I see it as the operator becoming a normal human being. Sites are tools. Family is not a tool.
Q. Did the kinds of tools you built shift after the child arrived?
A. Yes. A cluster of parenting-context tools appeared in late 2025 and early 2026 — weaning-stage guides, infant developmental milestones, the yebang vaccination reminder. None of that came from market research. It came from keywords I was searching from my own phone at 4 a.m. The cliché "build for yourself first" really is technically correct. yebang's small viral spike in May 2026 (138 UVs in 24 hours from a single Threads recommendation) was possible largely because I had used the tool myself every day, which kept the details filled in.
Q. A word for other parents running side projects?
A. Be able to decide "no code today" without guilt. That is the genuinely hardest part. Drop the fantasy that side projects need daily commitment. Finishing one thing to completion in a week is much further down the road than starting five things every week. The first words from your child only happen once. The site will still be there in a year.
Topic 4 — Money
Q. Are you comfortable discussing money? How much did you actually earn in year one?
A. AdSense took six months to clear the first USD 100 payout. The year-one cumulative is between USD 200 and USD 400. Per-hour, that works out below the Korean minimum wage. The project was never about earning a living. This model is honestly only practical for someone with a day job, and I admit that openly.
Q. Why run ads at all then?
A. Two reasons. First, when the site pays for its own infrastructure, guilt drops. If a site runs at a loss it pulls money from the family account, which I did not want. Infrastructure costs of USD 25–40 / month and ad revenue of USD 20–40 / month roughly cancel, which keeps the side project at net-zero personal cost.
Second, the presence of ads itself signals "this tool is officially operated" to visitors. It is an implicit promise that the site will not vanish overnight. A site with no ads communicates, accidentally, that the operator might be gone tomorrow.
Q. Any revenue outside AdSense?
A. Almost none. A handful of affiliate links generate tens of thousands of KRW per month combined. Within the next year I want to experiment with a small content subscription suited to Korean readers — but as an experiment, not a pivot. Tools stay free; what gets bundled into a subscription would be operator retrospectives, data analyses, and failure stories.
Topic 5 — Burnout and sustainability
Q. Did you experience burnout during year one?
A. Twice. Once in spring 2025, when I pushed the launch pace too hard and the keyboard physically felt heavy one morning. I took a full week off. The second was autumn 2025, in the sleep-deprived weeks right after our child was born — that was less burnout and more pure physical depletion.
Both recoveries took about a week of rest. Neither went deeper, which I attribute to the safety net built into the "distributed 119" structure. Because nothing was riding on a single site, the failure of any one tool was absorbed by the others. A week of rest does not register as "the operator vanished" because the sites are static enough to survive it. That is the hidden advantage of distributed micro-SaaS.
Q. Can you continue this for another year?
A. Yes, but smaller. I am not planning another 119. The goal for the next year is "1 to 1.2" rather than "0 to 1" — slowly sharpening how honestly the top 5–10 sites reach real users. New launches will fall to one or two per quarter.
Q. Could the count drop below 119?
A. Yes. Eight sites have already been categorised as dead-end based on GA4 data and marked noindex. They are removed from search visibility, not from the domain. More may drop next year. A shrinking count is not a regression. The next step beyond "do not build what you can avoid building" is "do not keep alive what should not be kept alive."
Q. One sentence for someone reading this interview?
A. Start with the smallest thing you can actually finish. That is the one decision that compounds furthest over twelve months. Only people who have shipped one small thing end up shipping ninety-nine more. People who start a hundred small things and finish zero end up shorter, every time.
---
Five questions held over for the year-two interview
This self-interview was constructed from the questions a year-one operator wanted to ask. To make the year-two interview a real promise rather than a vague intention, here are the five questions I want to answer when I sit down to do this again next year.
- "Did reducing launch pace actually result in more honest user experiences on the top 5 sites?"
- "How did the content-subscription experiment go? What price point worked for Korean readers?"
- "Did the next jump in AI coding assistants (Claude 5, GPT-5, the next Cursor) reshape the operating pattern again?"
- "Did we plan or have a second child, and what did that change about the rhythm?"
- "Is the two-way flow between day job and side projects still alive, or has one side tilted to dominate?"