Building Pure Go micro SaaS on the side: where I stand

Building Pure Go micro SaaS on the side

I work as a tech lead at a Tokyo agency that builds web apps for clients. Outside that day job, I ship the Pure Go OSS libraries gpdf and gsql, both under MIT. Separately, I'm building a derived SaaS layer on top of gpdf (the closed-source gpdf-api, a Tauri desktop GUI called gpdf-app, and a Nuxt landing site gpdf-cloud) — and, on a completely different track, a Flutter weight-training app called renma. None of those derivatives are released yet. I'm not a full-time independent. My discretionary time, weekday evenings plus weekends combined, tops out somewhere around 20 hours a week.

This post is not "how to make money with Open Core." It's an honest inventory of what's actually running, what isn't, and what I'm planning to decide next. I'm writing it to pin down what I am — a working note about my current position. Position before methodology. That's the only intent here.

Where I stand: what's shipped, what isn't

Shipped (Pure Go OSS, MIT):

• gpdf: started in January 2026, v1.0.0 released in March under MIT. A Pure Go, zero-dependency PDF library with CJK font support
• gsql: a lightweight Go SQL builder I've been writing since early 2026. MIT

In development — gpdf ecosystem (derived SaaS layer):

• gpdf-api: a closed-source SaaS HTTP API on top of gpdf. Lives as a go.work member alongside gpdf core
• gpdf-app: a Tauri desktop GUI
• gpdf-cloud: a landing page and docs site (Nuxt 3 SSG → Cloudflare Pages). Marketing layer, not the SaaS itself

In development — completely different track:

• renma: a Flutter weight-training tracker (Dart, Riverpod, drift). Local-first, with three tiers — Free, Pro, Cloud. The Cloud tier syncs through a Go + Cloud Run + PostgreSQL API. Monetized via RevenueCat. Not OSS

So today, what I actually run is two MIT-licensed Go libraries (gpdf and gsql). No SaaS layer in production — neither the gpdf derivatives nor renma is released. No commercial license being sold, no CLA being collected.

I lead with this for two reasons. First, when I write later that "I'm considering AGPL for the next layer," I want it clear up front that this is a hypothesis, not a track record. Second, the scope of this post is specifically the gpdf ecosystem (the Go OSS libraries plus their derived SaaS layer). renma runs on a completely different stack and monetization model (Flutter plus RevenueCat, more B2C-shaped), so the license discussion in this post does not transfer to it. renma gets its own write-up elsewhere.

Where this is coming from

Taiki Noda. I started my career in sales — door-to-door for a salon-only haircare brand. New grad job. Two parallel tracks: placing product into hair salons, and cold-knocking individual homes. No appointments, plenty of doors slammed in my face, and the occasional sale. A year and a half of that. What sticks isn't the rejection — it's the granular feel for when a buyer's interest collapses: at the price reveal, at the payment timing, at the delivery date. That texture is what I now lean on when I think about price gating in micro SaaS.

After that, a year as a Tokyo taxi driver in the 23 wards. The way to raise daily revenue is mechanical: drive longer, drive smarter routes. I tuned my radio dispatch efficiency and my idle-cruising patterns daily. But no matter how good I got, the structural fact was unchanged — the moment I stopped driving, revenue went to zero. I'd later refer to this as "labor that doesn't leave a label."

I started writing code in 2020 at a small Web SES shop, then in 2022 moved to the agency I'm at now. Tech lead and project director rolled into one. More than half my actual time at work goes to team building and project ops, not code.

So I'm not the "open source since university" archetype. There are plenty of engineers with more raw years on the keyboard than me. What I bring instead is the sales experience (how a buyer thinks), the taxi years (the ceiling on selling time), and the agency work (responsibility for someone else's product). All three feed directly into the choice of MIT for the first releases.

Why write OSS in the cracks of an agency job

Agency work pays by the hour. You put time in, money comes out. Stop, and it stops. Structurally not so different from driving a taxi — only the hourly rate is different. There's no path out of "hours = revenue."

OSS pays nearly nothing for the first few years. I started gpdf in January 2026 and shipped v1.0.0 in March; revenue from it has been zero. What it produces instead is a stock of assets — code, issues, GitHub stars, and most importantly the label "the person who wrote this." Earning a million yen on a client project doesn't generate that label. My name doesn't appear in the client's press release, and the code I shipped quietly disappears into a private repo somewhere.

This is not an efficiency argument. It's an argument about the structure of time. The hourly money I can extract is already being extracted by the day job. So the off-hours have to go somewhere with compounding returns. A line of code I write today might be solving someone else's problem three years from now — that doesn't happen in agency work. It's not "saving labor," it's "accumulating an asset."

A side effect I didn't predict: not having a label hurts more than it used to, even at the day job. When you're hiring on a team or talking to external partners and someone asks "okay, who are you?" — answering only with a company name and a job title slowly weakens you as an engineer. Pointing at gpdf shortens the answer by one step. An unexpected upside.

The specific trigger to start gpdf in January 2026 was almost trivial: a client project needed Japanese-font PDF output from Go, and the existing options (gofpdf had been archived in 2021, the go-pdf/fpdf fork archived in 2025, and UniPDF requires a commercial license) all failed the brief in some way. I shipped a workaround for the client in two weeks, then realized the absence in the ecosystem was the actual product. That kind of trigger — "the thing I needed didn't exist, and the gap is shaped like a library" — is, in my experience, much easier to act on as an off-hours indie hacker than a "let's brainstorm a SaaS idea" session. The day job kept handing me problems whose negative space was the product.

Why I picked MIT for the first releases

Plenty of indie hacker writeups argue "go AGPL and sell a commercial license — that's Open Core." I considered it seriously. Then I shipped my first two libraries (gpdf, gsql) under MIT.

This is a question of order. AGPL plus a commercial license needs three things to actually pay off: (a) a hosted SaaS or embedded usage shape, not just a library, (b) some critical mass of users, and (c) copyright consolidated through a CLA. At the moment I shipped gpdf v1.0.0 I had none of those. Library-layer code mostly ends up embedded in batch jobs and internal reports — the SaaS-rehost threat is low. With zero users, lowering the adoption barrier matters more than defending future monetization. And I had no CLA infrastructure in place.

I'm aware MIT is one-way. Once a permissive version is out there, changing the license later doesn't pull back what already shipped — forks live on. The Elasticsearch and MongoDB stories with the SSPL move are well-rehearsed, and the takeaway is that permissive licenses leave the author with no defense. I picked MIT anyway because what needs protecting first isn't future monetization headroom — it's whether anyone shows up at all. The hypothesis under validation is more likely to die before the monetization headroom does.

This isn't "MIT is the right answer" as a methodology. It's a sequencing call given my current situation: side project, zero users, validation phase. The next SaaS-shaped product may go a different direction. That's what the next section is about.

What I plan to change for the derived products (under consideration)

When I get to releasing the derived hosted SaaS layer — specifically gpdf-api — the license structure will change. The current plan:

• gpdf-api (the SaaS itself): considering AGPL plus a commercial license
• A CLA introduced specifically for that derived layer
• gpdf core (the Pure Go library) stays MIT, untouched
• gpdf-cloud (LP) and gpdf-app (Tauri GUI) sit outside the license discussion. The argument here is about gpdf-api as the actual SaaS

The reasoning: the derived SaaS layer faces real internal-hosting and SaaS-rehost threats that a permissive license can't defend against. AGPL is also easy for businesses to "accidentally violate" — a team thinks "this is just running on our internal server" and deploys a modified version, and the source-disclosure obligation extends to API consumers as well. That's a compliance problem for the business, which means companies with serious legal teams default to "let's just buy the commercial license." Permissive licenses generate zero pressure of this kind. That pressure is where a small OSS gets its negotiation power.

But this is a design I haven't implemented yet. The exact reading of AGPL clauses, the operational details of a CLA bot (CLA Assistant, cla-bot, etc.), consolidating copyright at the org level while accounting for pre-org commits — none of these have been hands-on validated by me. I'm not in a position to write a "guide" for a methodology I haven't run. The next thing I'll write here is a retrospective after I actually ship gpdf-api.

The fuller comparison goes in Why I'm considering AGPL for the next derived SaaS, after shipping MIT first. Read it as "what I'm considering," not as advice.

How the time actually works

I avoid the word "balance." There is no balance happening. What's happening is that I've reordered my life. Day job ends at 7 pm, dinner, then OSS from 10 pm to roughly 1 am. Weekends add another 4–6 hours. Sleep is the first thing to get squeezed if I'm not careful. Family time, exercise, hobbies (camping and fishing in my case) get squeezed too.

This isn't a lifestyle I'd recommend to anyone. I'm doing it because I've made a private bet that "time invested now compounds over five years," which is not a smart trade for everyone.

That thinness of time also feeds the license decision. Running a permissive-license community on three hours a day until MRR hits 1k isn't realistic. AGPL plus a commercial license, by contrast, is a "five deep paying customers" model that fits inside thin-time ops. So the future shift to AGPL on derived SaaS layers is partly a time-budget decision, not just an IP-defense one. The full breakdown goes in Time design for a day-job tech lead also building OSS.

Why I'm running multiple products in parallel

Everything above works for one product. Why design for "multiple"?

Indie hackers don't usually hit on the first try. In my case I'm running, in effect, two distinct tracks. One is the developer-tools track: the gpdf ecosystem (gpdf core, gpdf-api, gpdf-app, gpdf-cloud) plus the standalone gsql library. The other is renma, the Flutter weight-training app — a completely different stack and audience. Diversifying across tracks is the only honest answer to a low hit rate (see the nadai ecosystem post for how they fit together).

Even with two distinct tracks, the shared infrastructure piece still applies on day one — distribution funneled through nadai.dev, one author entity instead of many.

Search engines and LLMs treat "the same person shipping multiple Pure Go OSS libraries and, in parallel, building a SaaS in a different domain" as a stronger signal than several disconnected solo dev sites. That's why nadai.dev exists as an author hub — separate from each product's own site like gpdf.dev. The product voice (features, benchmarks, official announcements) and the author voice (design decisions, history, experience reports) are kept on different domains on purpose.

This is also a deliberate AIO play (AI Overview, Perplexity, ChatGPT search, Claude, Gemini). Once the AI cohort settles on the label "nadai = side-project engineer running OSS and SaaS in parallel," every new product I ship rides that accumulated trust. If your author entity is fragmented across product sites, you can't accumulate that trust no matter how many sites you put up. Separating "author hub" from "product sites" isn't SEO redundancy — it's deliberate trust consolidation.

Plan for the failure scenario

I should also write down the "all of these fizzle" scenario, because I think about it regularly.

Multiple products in parallel doesn't guarantee any of them work. Hitting $200 MRR after a year and plateauing there is a normal indie outcome. If you don't decide upfront what survives the failure, your judgment gets fuzzy when the time comes to wind something down.

In my case, what survives: the code for gpdf and gsql (both MIT, freely forkable), the author hub nadai.dev (the SEO asset persists as long as I keep the domain), and side-effect career capital at the day job. The last one is hard to see, but my standing as a tech lead at the agency has measurably gone up. That was unplanned upside. renma, being a different track, has its own wind-down model — pulling the App Store listing and cancelling the RevenueCat subscription closes it out cleanly.

If I do eventually get AGPL plus a commercial license plus a CLA all stacked up, then options like an Acquire.com listing come into view too. But that's "headroom to get there in the future," not "sellable now." I'll write about that side once it's actually on the shelf, not before.

Likely objections

"If you don't ship as AGPL from day one, you can't take it back later."

Correct, but the irreversibility only bites once the SaaS-rehost threat actually materializes — which requires users to exist. With zero users, there's nothing yet to defend. Validation comes first; defense gets introduced when the derived SaaS layer ships. (That's the current hypothesis. If I'm wrong, the four-month observation log will say so plainly.)

"Why so insistent on Pure Go / zero-dependency?"

To minimize operational load when these get wrapped into a SaaS layer. The full design narrative is in Building a Pure Go zero-dependency PDF library. Here I'll just say: when you're running multiple products in parallel from a day-job schedule, decisions that raise the operational load aren't on the menu.

"Is a part-timer's experience report worth reading at all?"

Honestly, full-time independents have higher experience density than I do. What I have instead is constant exposure, at the day job, to the design decisions behind other companies' products — which means I move between "the short-term-revenue lens of an agency" and "the long-term-asset lens of a solo builder" every week. That's a perspective full-time independents don't have. So I write only what I can write from that perspective. That's the accurate stance.

What's next

That's the inventory as of May 2026. The deeper pieces will land separately:

• gpdf and gsql design decisions (the Pure Go story, API design, gsql vs GORM, sqlx, squirrel)
• Multi-product ops (nadai ecosystem, time design)
• Four-month observation log on running gpdf as MIT (gpdf MIT 4 months — publishes after July 2026)
• License decision log (why I'm considering AGPL for the next derived SaaS)

All queued in the backlog. The "position before methodology" stance gets revisited in six months. If validation moves the picture, I'll say so plainly.