Shipped my first real production deploy of OrchestrAI — here's what actually broke along the way
Quick milestone update. OrchestrAI (B2B SaaS monitoring layer for n8n/Make/Zapier workflows — catches silent failures before customers notice) just went live in production for the first time.
I want to write about this honestly, because the "shipped it!" moment is the easy part to post about. The two weeks before it are where the actual work was.
What went wrong, in order:
Production was serving a commit from a month ago. Turns out Vercel's Production Branch was still pointed at master, while all my actual work had been merging into dev for weeks. The live URL was just... stale. Nobody's fault but mine for not catching it sooner — an easy thing to miss when you're the only one checking.
Auth token bug. A cached Firebase token was being stored in localStorage and never refreshed. Sessions would silently start failing API calls about an hour in — no error, just quiet breakage. Found it during code review before it shipped, but it's the kind of bug that's genuinely scary because it's invisible until a user hits it.
Env vars were never set on Vercel at all. Zero. Not misconfigured — just never added. First production deploy was a blank white screen. Console said Firebase: Error (auth/invalid-api-key). Classic.
Firestore security rules had real gaps. A few collections allowed any authenticated user to read/write any document, not just their own. Caught this in a review pass before onboarding real users — glad I checked before, not after.
Still working through this one: onboarding shows "connection successful" even with a wrong API key, because a SKIP_CONNECTION_TEST dev flag got left on in the deployed environment. And even with a valid key, workflows don't actually sync yet — turns out the code saves the integration record but never calls the actual workflow-list endpoint. Two separate bugs stacked on top of each other, both hiding behind what looked like one symptom.
None of this is dramatic. It's just the normal texture of getting something real into production solo, on a tiny equity-only team. I'm sharing it because I remember reading posts like this before I started and finding them more useful than the highlight reels.
Pre-revenue, still heads-down on fixing the onboarding sync bug before I put this in front of more people. If you're running automated workflows and want to be an early tester once it's solid, drop a comment — happy to add you to the list.
Interesting that the bugs you hit are almost the same class of problem OrchestrAI is trying to solve: things look connected / successful, but the real workflow isn’t actually working.Once the sync bug is fixed, I’d be careful not to test with generic beta users.The strongest signal would be one real production workflow where a silent failure actually costs someone time, money, or client trust.A demo workflow proves the integration works. A fragile real workflow proves whether OrchestrAI matters.
You are right and that distinction matters a lot. A demo workflow tells me the integration works. A real workflow with consequences tells me whether the detection rules actually catch what businesses care about. That is exactly why I am being deliberate about who I bring in first. I am looking for people already running production automations, not people who will spin up a test scenario. If you are in that situation or know someone who is, I would genuinely love to talk.
Exactly. A live workflow can still become a dressed-up demo unless the business consequence is frozen before onboarding.I’d ask one thing first: “What business outcome breaks if this workflow silently degrades?” Only bring in people who can answer that concretely.Could you post back contacted / qualified / pilot started, plus the consequence for any qualified workflow? Even 5 / 1 / 0 would show whether the blocker is access, trust, or rule relevance.
Real data instead of a vibe: 8 people got your exact question. 6 qualified, specific consequences named, not vague interest. 1 didn't qualify (pre-production, no real stakes yet). 1 gave a non-answer, still following up. 0 piloted.
The useful part: two of the six qualified people didn't convert, and neither was because the problem wasn't real. One's interested but bandwidth-constrained right now. The other told me straight: pain is real, but he's "not looking to add another tool right now."
So per your framework not access, not rule relevance (75% qualified on real ICP). It's trust/friction at the adoption step. People believe the problem exists, but a new tool competes with limited time even when the pain is confirmed. More useful thing to know than I expected.