# Onboarding is the second product
*Mark Ramos · Founder · August 21, 2026*
This week I shipped fourteen versions of something that isn’t the trading system.
Not the indicators. Not the scoring engine. Not the bot that executes while I’m asleep. Fourteen iterations of the **setup flow** — the sequence a new subscriber walks through between paying and placing their first automated trade.
Version 4.3 through 4.16. Layout rewrites. A vertical pipeline diagram that finally made the architecture legible. A progress bar. An aesthetic audit where I sat there and asked, honestly, *does this look like something a serious company built, or like a founder’s weekend project?*
If you’d asked me three months ago how I’d rank that work, I’d have called it internal ops. Necessary, unglamorous, invisible. Something you do once and forget.
I was wrong about that, and this week I finally said the thing out loud: **onboarding is the second product.**
## Why the setup flow gets the same bar as the indicators
Here’s the uncomfortable math of what I’m building.
The indicators are excellent. I’ve spent a year on them. But nobody experiences an indicator on day one. On day one, a new subscriber experiences a *sequence*: create a TradingView account, accept an invite-only script grant, connect a broker, configure an execution layer, verify the first webhook fires. Five systems that don’t know about each other, stitched together by instructions I wrote.
Every seam in that sequence is a place where someone quits.
And here’s the part that changed how I think: a subscriber who gets stuck on step three doesn’t blame step three. They blame **the product**. They don’t file a support ticket saying “your TradersPost connection instructions were ambiguous.” They just go quiet. Then they cancel in month two and tell a friend it didn’t work for them.
The trading system can be right and the business can still fail, entirely inside the setup flow.
Once I framed it that way, the fourteen versions stopped feeling like procrastination and started feeling like R&D — because that’s what they are. A setup flow that a non-technical person can complete alone, in one sitting, without messaging me, is a *feature*. Arguably it’s the feature that determines whether every other feature ever gets used.
There’s a scaling argument too. Right now, if someone gets stuck, they can text me and I’ll fix it in ten minutes. That’s a lovely experience and it is completely unscalable. Every hour I spend on the setup flow now is an hour I’m not spending on the phone with subscriber number forty. Solo founders don’t get to skip that trade.
## The bug that deletes things quietly
The other half of the week was less fun.
I ran a full audit of how money and identity flow through the backend — Stripe checkout to subscriber record to TradingView grant to Discord role to affiliate attribution. Not looking for a specific bug. Just tracing the path end to end and asking what could break.
I found the same bug I’ve already fixed three times.
The short version: when my cloud bot restarts, it re-syncs each subscriber’s record from the database. But it only copies over fields on an explicit approved list. Anything not on that list gets quietly reset — not to an error, not to an alert, just to empty.
That’s bitten me three times. A subscriber’s email address vanished. A webhook secret vanished. A TradingView username vanished. Each time I found it *after* it caused a problem, patched the one field, and moved on.
This week I finally recognized it as a **class** of bug rather than three separate incidents. And I looked ahead: Charter Members open September 26, and every new subscriber will populate four new fields — Stripe customer ID, subscription ID, Discord ID, and affiliate referral ID. None of them were on the approved list. The first routine server restart after Charter would have silently wiped all four for the entire cohort.
Billing lookups broken. Cancellation flow broken. Discord access broken. Affiliate commissions unattributable — which means the people who referred those subscribers don’t get paid, and they’d have no idea why.
The fix was two lines of code and took about five minutes.
I want to be precise about the lesson, because it isn’t “I’m a good engineer.” It’s the opposite. **The bugs that hurt you most aren’t the ones that throw errors.** Errors page you. Errors show up in Sentry. The dangerous failures are the ones that look exactly like success — a clean restart, a green deploy log, and a field that’s now empty. Nothing crashes. You find out weeks later when a customer asks why something stopped working.
I’ve started building detection for that category specifically: checks that compare what *should* be there against what *is* there, rather than waiting for something to fall over. If you run any kind of system where records get synced between two places, go look at yours. I’d bet you have this bug too.
## What lands Monday
All of this converges on August 25. Three things ship the same day:
– **Updated indicators** — three of the five get new versions published to TradingView. Existing subscribers inherit them automatically on the next chart reload.
– **Deployment Center v4.16** — the setup flow described above, rebuilt.
– **Library v4** — the reference documentation, rewritten around the questions people actually asked in the pilot rather than the structure I imagined they’d want.
They ship together on purpose. Shipping new indicators without updated documentation means the docs describe a product that no longer exists. I’ve done that before. It generates support load that lands squarely on me.
I have a cue sheet written for Monday morning — the exact order, with the backend patches first because the server takes ninety seconds to redeploy, and the announcement email dead last so it can never promise something that hasn’t actually landed. Two hours, notifications off.
That’s the whole discipline, really. Not brilliance. Just sequencing, and refusing to let the boring layer stay broken.
## If you’re watching this build
**Charter Members open September 15.** The first thirty subscribers become Founding Members — locked-in pricing for as long as they stay, plus inclusion in every product line we add after (futures, options, crypto).
If you want the founder notes and first look when seats open, [join the waitlist](https://trding.ai/#founding).
For reference, the headline backtest we publish everywhere is **61.3% win rate, 2.75 profit factor, +47.1R across 62 trades** on SOXL 1H with the Default preset plus the Zone Proximity Filter. The weaker rows are on the methodology page next to it, including the ones with sample sizes too small to conclude anything from. That’s deliberate, and I wrote about why [last week](/blog/why-we-dont-hide-weak-backtest-rows).
More next Friday.
— Mark
—
*Trding.ai is a software tool, not a registered investment advisor. Nothing on this page is financial advice. Past performance does not guarantee future results. Trade at your own risk.*