How to Go From Idea to Usable Tool With AI in a Weekend
This weekend I built a tool that drills the math on the Series 7.
It’s live on the web, free, no login, running entirely in a browser. It works, and I’m glad I made it. The tool itself is the least interesting part of this story - but if you want to check it out here, you can.
What’s worth your time is the instinct that produced it.
A year ago, facing the same problem, I’d have bought a prep app and lived with whatever it handed me. This weekend my first move was to build the exact thing I needed. That reflex is new, it’s available to you, and it’s the real story here.
Think about what that changes. The cost of building the exact thing you need has fallen close to zero, and the bottleneck is no longer money or engineers.
It’s whether you notice the problem and reach for the tool. The friction you’ve learned to tolerate, the spreadsheet that eats an hour, the app that does nine of the ten things you need, the report you rebuild by hand every month, used to feel permanent. Most of it isn’t anymore.
The tool is simple enough to describe in a breath. Behind it sit 74 question generators that spin up fresh numbers every time you load one, so you drill methods instead of memorizing answers. There’s a mode where I type the answer and work the math out by hand, a timed quiz at exam pace, and a worked solution on every question. That’s the whole thing.
There’s a deeper reason though that this matters to me.
For the better part of a month I’ve been making a single argument: statutory licensing is the one moat AI can’t commoditize.
Software can’t sit the Series 7 for you or file your U4. Then I spent a weekend using software to build the thing that helps me clear that exam faster. That looks like a contradiction, but it’s the argument in a single frame.
The AI built the ladder. The license is still mine to climb to and hold.
How it came together
I approached it the way I’d brief a sharp junior analyst who happens to type fast. I didn’t write code by hand. I described outcomes and corrected what came back wrong.
Before building anything, I did the reading. I pulled sample questions and prep PDFs from a range of sources online, and I clipped pages straight out of my Kaplan manual so the model could match the formatting and the way the real questions are worded.
Then I did the thing that seems counterintuitive but is actually the highest leverage piece of advise in this article: I described the outcome I wanted.
Questions that regenerate with new numbers.
Answers checked against worked solutions.
Wrong choices built from the mistakes the exam likes to bait.
A helpful glossary of terms for me to memorize.
An Options Matrix reference guide I could use to see various scenarios.👇
The work ran on three tools, each with one job. Think of them as the trifecta that carries an idea from your head to a live link: one to generate the code, one to store it, one to launch it.
Claude Code is the engineer. It’s Anthropic’s coding tool, and you talk to it in plain English. It writes the code, runs the commands, and fixes what you flag. You never have to open a file unless you want to.
GitHub is the filing cabinet. It stores the project in one place and tracks every change, so the work isn’t stuck on one machine. I can pick it up from my laptop or my desktop, and Claude Code reads from it to know where things stand.
Vercel is the launchpad. It turns the code into a live website with a public address, automatically, every time the project updates. There’s no server to manage and no domain to buy. My trainer lives at series7math.vercel.app, an address Vercel gave me for free.
The move that ties them together is a fairly simple workflow once you recognize how the tools .
I tell Claude Code what I want, and I let it drive all three: write the code, save it to GitHub, push it live on Vercel, and handle the logins and wiring in between. I describe, it builds and ships. That’s how an idea becomes a link I can open on my phone, with no part of the chain requiring me to write or read code.
From there I worked in small loops. Claude Code would build a piece, I’d open it, try it, and tell it what was off. The breakeven on a put was subtracting in the wrong direction. The dollar conversion forgot the hundred-share multiplier. Fix that, show me again. Most of the weekend ran on that rhythm. Look at the thing, react to the thing, send it back.
The loop is the whole skill, and it’s more forgiving than it sounds. Nothing I tried first survived intact. The first timed quiz scored wrong. An early generator produced breakevens that were off by the premium. None of that cost me anything beyond the minute it took to say so. When making a change is nearly free, you stop defending weak versions and start replacing them, and the thing gets sharper with every pass.
What made it work came down to one thing: I know the material.
It’s critical that you have some kind of domain expertise with what you are trying to create so you validate the output as helpful and useable, while being able to determine if that output is garbáge (so fancy).
When the model put a formula in slightly wrong, I caught it, because I’ve read the manual and worked these problems by hand. The model brought the typing. I brought the judgment about what good looks like, and that was the part that couldn’t be handed off.
AI doesn’t replace judgment. Full stop.
It replaces the tedious work sitting underneath it. Writing the code to randomize a strike price is tedious. Knowing that a covered call’s maximum loss is the stock cost minus the premium received, and noticing when the screen says otherwise, is judgment.
How you can win doing this too
You don’t need to code, and you don’t need a technical background. You need a problem you understand, the three tools above, and the willingness to run the loop. Here’s the path I’d hand to anyone starting out.
Pick a real problem you already have. Start with the friction you tolerate every week, not a moonshot. Small and annoying beats big and vague.
Gather the raw material first. Know the subject well enough to tell right from wrong. That domain knowledge is what separates a version that works from one that only looks like it does.
Describe the outcome, not the code. Say what ‘done’ looks like and let the tool work out how to get there.
Work in short loops. Build a piece, test it, say what’s wrong, repeat. You’re steering, not typing.
Be the judge. The machine is fast, confident, and sometimes wrong. Your standard for what’s right is the part that can’t be outsourced.
This part should sit with you whether or not you ever touch the Series 7. We’re early in an agentic economy, and the edge is shifting from people who can do the work to people who can direct the tools doing it.
From a business angle, someone in your market is already compounding small builds while their competitors wait for a budget line. From a personal angle, this is the cheapest leverage available, and it’s sitting in a browser tab you already have open. The skill getting scarce is knowing what’s worth building and telling when the result is right.
The typing in the middle keeps getting cheaper by the month.
I’ll be living in this trainer for the next six to eight weeks, drilling toward the SIE and then the Series 7. It’s free, it’ll stay free, and the link’s below. What I’d want you to take from it isn’t the trainer but the habit behind it. Build the next thing you wish existed, then the one after that. The muscle is what compounds.
Until next time - keep building friends!
Matthew Snider is the founder of Block3 Strategy Group, author of “Warren Buffett in a Web3 World,” and publisher of the BitFinance newsletter. He holds a Series 65 and MBA, and has been an active participant in digital asset markets since 2015. This article is for educational purposes only and should not be considered financial advice. Always consult with a qualified professional before making investment decisions.