Six things that went wrong before the first sale
5 min read · 1,130 words ·
The workflow was generating posts with the wrong brand colours for at least three days before I noticed.
Not slightly off. Not a subtle hue shift. The posts going out for SSC — Sales Source Code — were rendering in Nunlimited colours because I'd updated the colour variables in the content template without updating the node that referenced them. The system kept running. The posts kept going out. I kept not checking.
That's the honest version of "building in public." Not the launch tweet. The three days where your production system is quietly embarrassing you and you have no idea.
Here's what else broke, what it cost, and what each thing actually taught.
Precision beats creativity in the early stages
When I first set up the Gemini prompts for Zo.E, I gave them too much latitude. The brief was something like "write a LinkedIn post about productivity for sales professionals." The output was florid, generic, and completely off-tone — the kind of thing that sounds like it was written by someone who has read a lot about sales professionals without ever having been one.
The fix wasn't a better brief. The fix was treating the LLM as a data-entry clerk with a specific format to fill, not a creative collaborator with licence to interpret. Once I locked down the prompt structure — exact word count range, defined opening pattern, banned phrases, specified audience — the output quality jumped immediately. The lesson is that in the early stages, getting the system right matters more than making it look impressive. Creative latitude is a reward for a stable system. It's not how you build one.
Documentation takes longer than the build
The Zo.E Template Pack shipped with four supporting documents: a README, a Setup Guide, a NocoDB schema, and the Gemini prompts. Writing those four documents took longer than building the ten workflows they describe. That ratio surprised me the first time. It shouldn't have.
A workflow JSON 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 get step four wrong. The Setup Guide has to explain that you can't run WF5 before WF4, because WF4 handles the approval state that WF5 depends on — and that if you try, nothing obviously fails, it just silently skips approvals and you won't realise for days. That's the kind of thing that takes thirty seconds to say and thirty minutes to learn the hard way.
Most people skip the docs. That's why most template packs are useless. You're not selling the workflow. You're selling someone else's ability to run it without needing you.
Build for failure from day one
WF5 — the workflow that batches and schedules posts across platforms — had no rate limiting in the first version. A full queue flush of twenty-two posts would have hit the Upload Post API in rapid succession, which would have triggered rate-limit errors, which would have caused the workflow to bail, which would have left the queue in an unknown state.
I caught it before it happened. Just about. The fix was a delay node between each API call — simple enough once you know to add it, not obvious until you've mapped the failure mode. The lesson is that defensive architecture isn't something you retrofit. By the time you know you need it, you're already managing the incident. Build the retry logic and the rate limiting and the error-handling branches before the first real load, not after.
Never trust a single credential scan
Before the Zo.E Template Pack went on sale, every workflow JSON had to be sanitised — all live credentials replaced with YOUR_* placeholders. Twenty-three distinct placeholder types across ten files. I did the first pass manually, found everything I expected to find, and marked it done.
Then I grep'd for my actual values — the real tokens, the real API keys — not just the locations where credentials were supposed to be. Found seven more. Buried in node parameters, in webhook URL defaults, in header values I'd forgotten I'd hardcoded during a late session. One of them was a live NocoDB token sitting in a default-value field that would have shipped to customers and been visible to anyone who exported the workflow.
The lesson is blunt: search for the real values, not for the expected locations. The expected locations are where you remember putting them. The real values turn up everywhere else.
Operational clarity matters more than operational perfection
At one point, the Notion workspace had a task list on a wiki page, a separate task database, a second wiki page that had been turned into a de-facto task list by accident, and no clear canonical source of truth for what was actually in progress. Finding the status of a specific piece of work meant checking three places and picking whichever one looked most recent.
Fixing it was a single focused session — consolidating everything into one database, archiving the conflicting pages, establishing a clear convention for what goes where. It didn't make the work better. It made it possible to see the work, which is a prerequisite for managing it. Operational clarity is something most people defer until the mess is painful enough to force action. The mess gets painful faster than you expect.
Build dual-brand from the start
Zo.E was built for SSC. That was the first use case, the first content strategy, the first set of brand variables. Adding Nunlimited as a second brand later — different content pillars, different tone, different visual identity, different audience — meant retrofitting routing logic that should have been in the architecture from day one.
Not complicated, in the end. But it required touching a lot of nodes that hadn't been designed with branching in mind, and it introduced the colour-variable problem I mentioned at the start. If I'd designed the system from the beginning with a BRAND_ID variable flowing through every template node, adding a second brand would have been additive. Instead it was reconstructive.
If you're building anything with the faintest chance of scaling to more than one brand, one product, or one audience — design the routing before you need it.
That's the honest version of the first few months. Nothing catastrophic. No lost data, no credentials shipped, no customers burned. But close enough on a couple of those to have made things properly awkward.
The wins are real. The system works, the product is live, and the Zo.E engine is running. But the wins happened alongside these failures, not instead of them. That's what building actually looks like.
Ta,
James
Founder | Nunlimited
