The Saturday Morning Idea
Last month I had a simple idea on a Saturday morning. I wanted a tool that takes your monthly bank statement CSV, categorizes every transaction automatically, and gives you a clean spending breakdown — the kind of thing Mint used to do before Intuit gutted it. Nothing revolutionary. Plenty of apps do this. But I wanted one that ran locally, kept my data private, and actually categorized things correctly instead of dumping everything into "Other."
I'd been reading about vibe coding — the whole "describe what you want and AI builds it" workflow — and figured this was the perfect test case. Simple enough to scope, complex enough to be useful. I told myself I'd have a working prototype by Sunday night.
It took three weekends. And the final product cost me more in API credits than I'd ever admit to my wife.
What I Actually Built
The core idea: upload a CSV, hit a button, get categorized spending. The frontend is a Next.js page — one file upload input, one table, one bar chart. The backend is a Python script that calls Claude's API to parse the CSV, map transactions to categories, and return structured JSON. I used Supabase for a free-tier database so users could save their breakdowns and compare months.
Here's what the build actually looked like, hour by hour.
Saturday morning (4 hours): I opened Cursor and described the entire app in a prompt. "Build a Next.js app with a CSV upload endpoint that sends the file to a Python backend, calls Claude to categorize transactions, stores results in Supabase, and displays a dashboard." Cursor generated roughly 80% of the code in about twenty minutes. It looked right. It compiled. It did absolutely nothing useful.
The problem was immediately obvious: the generated code assumed a perfect CSV format. Every real bank exports transactions differently. Chase puts the date in MM/DD/YYYY. Capital One uses YYYY-MM-DD. My credit union exports a CSV where the first three rows are headers and account info, not data. The AI had built a beautiful app that worked perfectly for a hypothetical CSV that no bank on earth actually produces.
Saturday afternoon (3 hours): I rewrote the CSV parser myself. This is the part that no AI tool could handle for me, because the problem wasn't code — it was knowing what the mess actually looks like. I pulled real exports from my Chase checking, my Amex, a Venmo download, and a PayPal statement. Four different formats. Four different column names. Two of them had commas inside transaction descriptions that broke naive CSV parsing. I spent an hour just writing regex patterns to normalize date formats.
Saturday evening (2 hours): The categorization prompt. This is where I expected AI to shine, and it mostly did — but not without surprises. My first prompt was: "Categorize this transaction into one of these categories: Food, Transport, Bills, Entertainment, Shopping, Income, Transfer, Other." Claude categorized my $47.82 Trader Joe's charge as "Shopping" about 40% of the time. Grocery store. Shopping. Technically not wrong, but completely useless for a spending tracker.
I added a meta-prompt: "You are a personal finance categorizer. Groceries go under 'Food & Groceries,' not 'Shopping.' Amazon purchases that are household supplies go under 'Household,' not 'Shopping.' 'Shopping' is reserved for clothes, electronics, and discretionary purchases." That fixed it. But it took six rounds of testing with real transactions to get the categories right. Each round cost me about $0.30 in API calls. Tiny. But the time cost was the real expense — I was manually reviewing every transaction to check if Claude got it right.
Sunday (6 hours): Supabase setup, authentication, the dashboard UI, the bar chart, export-to-PDF functionality. The Supabase schema took me an hour because I kept forgetting that Supabase RLS policies need to be set up separately from the table creation. Cursor generated the chart component wrong twice — it used a charting library I hadn't installed and imported components that didn't exist in the version I had. I ended up writing the chart by hand using recharts, which took longer than it should have but at least worked.
By Sunday night I had a working prototype. Upload a CSV, get a categorized breakdown, see a bar chart of your spending by category. It worked. I was tired.
The Costs Nobody Warns You About
Here's what I spent on this "weekend project."
Claude API credits: $14.87. I used Claude 3.5 Sonnet for the categorization, and each bank statement with 150-200 transactions cost roughly $0.40-$0.60 to process. Sounds cheap. Then I started testing with larger statements (a year of Amex transactions is about 2,400 lines), and each full-year batch cost $3-4. I ran about 30 test batches. The API costs crept up fast.
Supabase: Free tier. But the free tier has limits — 500MB database, 1GB file storage, 50,000 monthly active users. For a prototype, fine. For anything real, you're on the $25/month plan immediately.
Vercel deployment: Free tier for personal projects. But my Python backend couldn't run on Vercel's serverless functions because of the CSV parsing dependencies and the timeout limits. I ended up deploying the backend on a $5/month Railway instance. So $5/month just for the backend to exist.
Domain: $12/year for a .com. I bought it because I was actually going to launch this thing. (I haven't launched it yet.)
My time: This is the real cost. Three weekends, roughly 30 hours total. If I valued my time at even $50/hour — which is low for a senior developer — that's $1,500 in opportunity cost. The app now saves me maybe 15 minutes a month compared to just manually glancing at my bank transactions. I will never recoup that time.
What AI Actually Good At (and What It Isn't)
Let me be specific about what Cursor and Claude handled well versus what they didn't.
Cursor was genuinely good at: boilerplate. Setting up the Next.js project, creating API routes, writing Supabase queries, building form components, generating TypeScript types. The boring scaffolding that takes time but requires no thought — Cursor knocked it out in minutes. If you've ever stared at a blank page.jsx wondering where to start, Cursor eliminates that friction completely.
Cursor was bad at: anything requiring domain knowledge. It didn't know that bank CSVs are inconsistent. It didn't know that transaction descriptions contain commas. It didn't know that you need to handle encoding issues (my Amex export is UTF-8, but my credit union exports in Windows-1252). It built the happy path perfectly and ignored everything else.
Claude was genuinely good at: categorization once I gave it the right context. With a detailed prompt and a few examples, it categorized transactions with about 92% accuracy. That's genuinely impressive for a zero-training, zero-fine-tuning approach. For a prototype, it's more than good enough.
Claude was bad at: edge cases. "PAYPAL *BUSPARK 402-867-5309 CA" — what is that? It's a parking garage in San Francisco that accepts PayPal. Claude had no idea. Neither did I, honestly, until I Googled the phone number. For recurring merchants, you'd want to build a custom lookup table over time. For one-off transactions, you're stuck with educated guesses.
The thing neither tool could do: tell me whether this product was worth building. That's a business question. AI tools are execution tools. They help you build faster. They don't help you decide what to build. I spent three weekends building a tool that already exists in ten better versions. Would I have known that if I'd spent the same three weekends researching the market instead? Probably. But the building was more fun than the research.
The Mistake I'd Make Differently
I would not start with the code. I know that's heresy in a "build with AI" article, but it's true.
I should have spent Saturday morning writing a one-page spec: what exactly does this tool do, who uses it, what are the five hardest parts, and does any existing solution already cover 80% of it? The answer to that last question is yes — Monarch Money, Copilot, and a dozen other apps do exactly this, usually better, usually for $10/month.
If I'd done that research first, I might have built something different. Maybe a tool that specifically targets small business owners who need to categorize transactions for tax purposes — a more specific audience with a clearer pain point. Maybe a tool that integrates with a specific bank's API instead of parsing CSVs. Maybe I wouldn't have built it at all and instead spent the weekend on something with a clearer market.
But I didn't do that. I jumped straight into prompting Cursor because the vibe coding workflow is addictive. You describe something, it appears, you iterate. It feels like progress. It feels productive. But building the wrong thing faster is still building the wrong thing.
The other mistake: I didn't set a budget. I told myself "I'll just prototype it" and then spent $15 on API credits and three weekends of time without once stopping to ask whether the prototype justified the investment. If I'd set a hard limit — $20 in API costs, one weekend max — I would have hit the wall with the CSV parsing on Saturday afternoon and probably stopped. Which would have been the right call.
"Yeah But What About Just Using GPT for Everything"
A friend asked me why I didn't just use ChatGPT's custom GPTs feature to do the categorization. Upload your CSV to ChatGPT, ask it to categorize, copy the results. No backend, no Supabase, no deployment.
That's a fair question, and for most people it's the right answer. A custom GPT with a good system prompt will categorize your transactions with similar accuracy to what I built. The difference is workflow: you have to manually upload each month, copy the results, and you can't build a dashboard or track trends over time. For a one-off analysis, ChatGPT wins. For a recurring tool, you need actual code.
The other thing: data privacy. If you upload your bank statement to ChatGPT, OpenAI has it. They say they don't use it to train models, but you're trusting their policy. My tool processes everything locally (well, locally initiated — the API still sees the data) and stores results in your own database. For a spending tracker, that matters to some people. For most people, it doesn't. Be honest about which camp you're in.
Where This Actually Makes Sense
After building this thing, I've started thinking about when the "AI-assisted weekend build" approach actually makes sense versus when it's just procrastination dressed up as productivity.
It makes sense when: you're building an internal tool for yourself or your team, the problem is well-defined and technical, and you'd otherwise spend weeks doing it manually. A data pipeline that transforms messy CSVs into clean database records. A dashboard that pulls from three different APIs and normalizes the output. A code generator for repetitive boilerplate in your specific domain. These are problems where the value is clear, the scope is contained, and the AI helps you skip the boring parts.
It doesn't make sense when: you're trying to validate a business idea. Building the prototype is the easy part. Finding customers, understanding the market, figuring out pricing, and actually selling — that's the hard part, and no AI tool helps with that. I built a spending tracker in a weekend. I have zero customers and no plan to get any. That's not a product. That's a hobby project.
It definitely doesn't make sense when: you're using the building as a way to avoid the harder work. I see this pattern constantly in indie hacker communities: people build prototype after prototype, each one more polished than the last, none of them ever launched. The AI tools make this worse because they lower the friction of building, which makes it even easier to stay in the "just one more feature" loop. Shipping is the hard part. AI doesn't help with shipping.
What I'd Tell You Starting Today
If you're reading this and thinking about building something with AI tools, here's what I'd actually tell you.
Do the research before you do the build. One afternoon of Googling competitors, reading Reddit threads, and checking App Store reviews will save you a weekend of building something nobody wants. The AI tools aren't going anywhere — they'll still be there when you've validated the idea.
When you do build, scope ruthlessly. My spending tracker had seven features in my head when I started. I shipped three. The other four — recurring transaction detection, budget alerts, bank API integration — were scope creep that would have added weeks. Pick the one thing that makes your tool useful and do that. Nothing else.
Budget your API costs before you start. Set a hard ceiling. If your prototype costs more than $30 in API credits to build, something's wrong — either your scope is too big or your prompts are too wasteful. The costs feel invisible because they're small per-call, but they add up in ways that sneak up on you.
Accept that the AI will build you a beautiful prototype that works on perfectly formatted data and breaks on real-world mess. That's not a bug in the tools — it's the nature of software. The gap between "demo" and "production" is where all the real work lives, and no AI tool has closed that gap yet.
And be honest with yourself about whether you're building a product or building a project. Both are fine. Projects are fun. Products make money. They require completely different disciplines. I built a project last month. It was a great weekend. I'm not under any illusions that it's a business.
I don't regret building the thing. I learned more about CSV parsing in three weekends than I'd learned in fifteen years of professional development. But if I'd spent those same three weekends on market research and customer interviews, I'd probably have a better product idea and a list of people ready to pay for it. The code is the easy part. It always has been.