Building the operating system
for serious option sellers

Getting specific about who this is for

The instinct in early product work is to broaden the ICP to feel safer. I did the opposite. The more precisely I could describe the user, the better every product decision became.

The choices that define the product

Every product is defined as much by what it doesn't do as what it does. These were the deliberate decisions that shaped the architecture and roadmap.

Getting the data model right before anything else

A week before writing a single new frontend feature, I audited the existing Supabase schema. Found three tables — trades, trade_legs, trades_legacy — built organically as the product evolved. The leg-based model would have made analytics hard and assignment impossible to model correctly.

I designed the complete target schema first, then wrote the migrations. The principle: every architectural decision made at schema level is free. The same decision made after 1,000 users have data costs weeks.

Sequenced for signal, not features

The roadmap isn't a feature list. It's a sequencing strategy for building defensibility in the right order — first get traders to switch from Excel, then give them something Excel can never do.

What it looks like to own the whole thing

Every role on a normal product team — I'm doing it. That changes how you work. There's no handoff latency, no miscommunication between design and eng, no PM-to-dev translation loss. But it requires deliberate sequencing to avoid spreading across everything at once.

The discipline required: one thing fully done before the next thing starts. A roll flow that works completely is worth more than four half-built features. Every day starts with one task, not five.

The educator insight most SaaS founders miss

The option selling community has a thriving educator layer — YouTube channels, paid courses, Discord signal groups, Twitter traders. These are micro-influencers with warm, paying, high-intent audiences. They need tools, credibility, and recurring income. The product can provide all three.

Principles I applied throughout

• 01 Schema decisions are free at the start, expensive at scale. Every architectural choice made before real users have data costs nothing to get right. The same choice after 1,000 users have records costs weeks of careful migration work. One week on schema before writing features is the best investment in a data-intensive product.
• 02 Understand why the existing behavior persists before trying to replace it. Excel survives not because it's good enough, but because nothing has beaten it on its own terms while also offering something it can't. You have to do both — match the flexibility, then exceed it.
• 03 The ICP already exists and is describable. The option selling community is on Reddit, Twitter, YouTube, Tastytrade forums. You can read what they complain about, what tools they use, what they wish existed. Primary research is available for free before you write a line of code.
• 04 Distribution is a product decision, not a marketing decision. The educator affiliate system, the classroom sharing feature, the community trade feed — these are product features that double as distribution mechanisms. Building them early means the product grows itself. Building them as afterthoughts means you're paying for ads.
• 05 Defer AI until the data exists to make it useful. The impulse to add AI features early is strong. But AI on sparse, single-user, early-stage data produces noise, not insight. The correct sequence is: build the data model that captures what matters, get users putting real data in, then let the AI interpret patterns that actually exist.
• 06 One thing fully done beats five things 80% done, every time. As a solo builder, fragmentation is the primary risk. A roll flow that works correctly and handles all edge cases is a competitive advantage. Four half-built features are a liability. The daily discipline is choosing the one thing and finishing it.