Chapter 4: Hardening for Launch
6 min read · 1,254 words ·
The Gumroad listing went live at 11:43 PM on a Tuesday. Not because that was the plan. Because I'd been going through the checklist all evening, found one more thing to fix at 11:30, fixed it, and then just did it.
That's a perfectly fine way to launch. Anyone who tells you there's a right moment is selling something that isn't on Gumroad.
What "launch" actually meant
Zo.E was running. The content catalogue had posts scheduled. The five content pillars were documented. The design system existed.
What I didn't have was a product to sell.
The Zo.E template pack became that product — ten sanitised n8n workflow JSONs plus four supporting documents covering setup, NocoDB schema, and the Gemini prompts I use for content generation. It's the engine itself, packaged so someone else can run it.
Hardening for launch meant getting from "this works on my machine" to "this works on someone else's machine without me holding their hand." That's a non-trivial gap.
The credential problem
Every workflow in Zo.E connects to external services: NocoDB, Telegram, Google Gemini, Upload Post, Bluesky, Cloudinary. In my running instance, all of those are live credentials.
The templates needed to ship without any of them.
The solution was a systematic find-and-replace pass through all ten workflow JSON files, replacing every live value with a YOUR_* placeholder: YOUR_NOCODB_API_TOKEN, YOUR_TELEGRAM_CHAT_ID, YOUR_GEMINI_CRED_ID, and so on. Twenty-three distinct placeholder types in total.
This sounds mechanical, which it mostly is. What makes it not mechanical is that credentials show up in places you don't expect. Node parameters, headers, webhook URLs, default values buried three levels into a JSON structure. I grep'd for my actual values after the first pass and found seven I'd missed.
Lesson: never trust a single scan. Grep for the real values, not just the expected locations.
The documentation problem
A workflow JSON is not documentation. It tells you what the system does; it doesn't tell you why, or what order to set things up in, or what breaks if you do it wrong.
I wrote four documents. Not because four is the right number — because that's how many things needed explaining.
README.md — what you're buying, what you need before you start, what the ten workflows do in plain language.
SETUP_GUIDE.md — the activation order (which matters: you can't run WF5 before WF4 because WF4 handles the approval state WF5 depends on) and the specific configuration steps for each credential type.
NOCODB_SCHEMA.md — the six-table schema with field names, types, and what each field is for. Without this, someone setting up NocoDB from scratch is guessing.
GEMINI_PROMPTS.md — the actual prompts I use for content generation. This is the intellectual property bit. Anyone can run the workflows; knowing what to tell Gemini is the part that took the most refinement.
Writing these took longer than building the system. That's usually true of documentation. It's also the part most people skip, which is why most template packs are useless.
The setup guide HTML version
The four documents are markdown. They're fine for someone who's comfortable with markdown.
I also built a single-page HTML version — ZOE_SETUP_GUIDE.html — that presents the same content with the SSC design language: dark terminal chrome, cyan accents, step-by-step layout. It's the version I'd want to receive if I'd just bought a product.
Technically it's the same content. Practically it changes the experience of using the thing. That matters, because experience-of-using determines whether someone recommends it.
The Gumroad listing
Getting a Gumroad listing right is not complicated, but it's not obvious either.
The cover image is 1280×720. It needs to communicate what the product is in a thumbnail — which means text-forward, high contrast, clear value statement. I built mine as HTML (the SSC design language: dark background, cyan, mono font), screenshot it at the right dimensions, uploaded it.
The listing copy has one job: answer "what is this and why should I pay for it?" without any of the usual sales-page inflation. No "10x your results". No testimonials from people who haven't used it yet. Just: here's what it is, here's what's included, here's what you need to run it.
Price point: I'm not going to state a specific number here because it'll be out of date by the time you read this. What I will say is that I priced it at a level where someone could buy it without thinking too hard about it, because the barrier I wanted to remove was friction, not scepticism.
The infrastructure budget
Under thirty pounds a month. Here's where it goes:
n8n runs on PikaPods — self-hosted, costs a few pounds depending on instance size. NocoDB is free for the use case I have. Google Gemini has a generous free tier; I'm not close to exceeding it. Telegram is free. Upload Post has a paid tier for the features I use. Bluesky is free. Cloudinary free tier handles the image hosting.
Gumroad takes a percentage of sales. That's fine — it's a marketplace with a built-in audience and zero setup cost.
The only thing I'd change in retrospect is that I set everything up piecemeal, which meant the credential management was messier than it needed to be. If I were starting again I'd document all the service credentials in a single place from day one, not reconstruct the list when packaging the product.
What "production-ready" actually means
For a one-person side project with a weekly budget of four to seven hours, production-ready means:
The system recovers from normal failures without me. Zo.E has retry logic on the workflows that are most likely to hit rate limits. A failed post doesn't break the queue; it logs the failure and moves on. I can ignore it for a week and it'll still be running when I come back.
The product doesn't require me to support it. The documentation covers the scenarios someone is likely to hit. A buyer who reads the setup guide can run the system without pinging me. (They can still ping me if they want — I'm not hard to reach — but they shouldn't have to.)
The credentials are never in the shipped files. This is non-negotiable. A one-person business can't survive a credential leak, and the reputational damage of shipping a product with live keys embedded in it would be worse than any revenue opportunity.
The files open. This sounds stupid until you've shipped a PDF that renders correctly on your machine and is blank on someone else's because the fonts were embedded wrong.
That's the whole list. Not everything works perfectly. A few things are inelegant. Some of the workflow error handling is thin. But it runs, it ships, it recovers — and that's what launch-ready means for a build at this stage.
What comes next
The product is live. The system is running. The catalogue exists.
What doesn't exist yet is an audience — which is the whole problem Chapter 5 is about.
For now, though, the infrastructure is in place. Zo.E is posting. The Gumroad listing is live. The machine is running.
The question changes from "can I build this?" to "can I build an audience for it?"
Different problem. Different skills. Similar amount of trial and error.
Chapter 5 covers the first live sale: what it took, what it felt like, and what it told me about what to do next.
Ta,
James
Founder | Nunlimited
