How I Built a SaaS Product as a CPA (No Code, No Engineers, No VC)

I am a CPA. Never written a line of code before February 2026. In 38 days, I built a SaaS product that serves multiple clients, automates financial deliverables, and generates recurring revenue.

No engineering team. No venture capital. No coding bootcamp. Just me, Claude (Anthropic's AI), and a problem I was tired of solving manually.

This is the full story. Not the highlight reel. What happened, what broke, and what I learned about building software as a finance professional.

The Problem I Was Solving

I run a fractional CFO practice called Meicho Consulting. I work with small and mid-market businesses doing $500K to $10M in revenue. My job is to take their messy QuickBooks data, build financial models, create dashboards, and deliver strategic insight.

For two years, that process looked like this: export from QuickBooks, paste into Excel, build formulas, format the spreadsheet, email the PDF, schedule the meeting, present the numbers. Every single client. Every single month.

The deliverable was good. The process was brutal.

I was spending 60% of my time on formatting and delivery. 40% on the actual financial analysis that clients pay for. Those numbers are backwards. The thing I was best at, the financial strategy, was getting squeezed out by the thing that felt most like data entry.

And it was not just about time. Every manual step was a risk. I fat-fingered a SUMIF formula once and told a client their gross margin was 47% when it was actually 22%. I caught it before the meeting, but it took two hours to trace the error back to a mistyped cell reference. Two hours I could have spent on analysis that actually helps the client make better decisions.

So I decided to fix it.

Why I Chose to Build, Not Buy

There are off-the-shelf CFO dashboards. I tried three of them over the course of six months. Every single one had the same problem: they were built by engineers who do not understand how CFOs actually work.

The first tool I tried had beautiful charts. The metrics were generic: revenue, expenses, net income. That is what you get from a developer who read an article about financial dashboards. A real CFO needs gross margin by service line, operating expense trends by vendor, AR aging by customer with concentration analysis. The tool could not do any of that without extensive customization that cost more than building from scratch.

The second tool had good customization but assumed clean books. My clients are small businesses. Their QuickBooks files have miscategorized transactions, duplicate vendors, inconsistent naming conventions, and chart of accounts that evolved organically over years. No off-the-shelf tool handles that reality.

The third tool was priced for enterprise. Thousands per month before I delivered a single insight. And I would still need to do all the financial analysis manually because the tool only handles visualization, not interpretation.

I needed a tool that matched my exact workflow. That understood my specific chart of accounts mapping for each client. That could ingest messy QuickBooks data and transform it into the exact metrics I present in client meetings. That cost less than $50 per month to run.

So I built one.

Day 1: The CLAUDE.md File

I did not start by writing code. I started by writing a document.

CLAUDE.md is a plain text file that tells the AI exactly who I am, what I am building, how I want it built, and what the rules are. Think of it as an operating manual for your AI development partner. It is the single most important piece of infrastructure I built during the entire 38 days. More important than any dashboard or API route.

My first CLAUDE.md started small and grew into a comprehensive document by day 38. It contained my tech stack decisions, my code standards, my git workflow, my debugging protocol, and my professional scope rules (critical for a CPA working with client financial data).

Here is why this file matters so much. Without it, every AI session starts from zero. You explain your project. You explain your preferences. You explain your constraints. You do this every single time. With CLAUDE.md, the AI reads the file automatically at the start of every session. No re-explaining. No drift. No hallucinated architecture decisions.

By week three, I could start a session by saying "add a cash flow chart to the client dashboard" and the AI already knew: which codebase, which tech stack, which data source, which chart library, which styling system, and which deployment process. All from the file.

I will write a full post about CLAUDE.md in this series. For now, just know: if you are building anything with AI, start with a document that defines the rules.

The Tech Stack

I chose Next.js, TypeScript, Supabase, Tailwind CSS, and Vercel. I did not choose these because I understood them. I chose them because they are the most commonly used modern web stack, which means the AI has the most training data on them.

When you are building with AI, your tech stack decision is not about what you know. It is about what the AI knows. Pick the tools with the deepest training data, and the AI will write better code, hit fewer errors, and require fewer corrections.

Next.js handles the frontend (what users see) and the API routes (the backend logic). Supabase handles the database and authentication. Tailwind handles styling. Vercel handles deployment. TypeScript catches errors before they hit production. If you want the full breakdown of each tool, Post 11 in this series covers every one in detail with honest pros and cons.

Total monthly cost to run everything: under $50. That is not a typo. The tools I am using have generous free tiers, and even at the paid tier, the infrastructure cost is less than what I spend on coffee.

The 38-Day Timeline

Days 1 to 5: Foundation. Set up the project, built the blog, deployed to Vercel. First commit to first live page in under 48 hours. I published the website at peterxiacpa.com with a blog, booking page, and basic navigation. These five days felt like learning to walk. Every task took 3x longer than it should have because I was learning the workflow: write code, test locally, push to staging, verify, push to production.

Days 6 to 12: Admin and Auth. Built the admin panel. User authentication with Google OAuth (I click my Google account, I am in. No passwords). Content management system for blog posts. This is where I learned about staging vs production environments the hard way. I broke the live site twice by pushing untested code directly to production. After the second incident, I wrote a rule in CLAUDE.md: "Never push directly to main." That rule has prevented every production incident since.

Days 13 to 20: Client Dashboards. This was the hard part. I needed to take QuickBooks data, pipe it through a transformation layer, and render it as interactive charts. Multiple clients, each with different chart of accounts, different fiscal years, different metrics that matter. The transformation layer alone took five days. But when it worked, when I saw real client P&L data rendered as an interactive bar chart for the first time, I knew the entire build was worth it.

Days 21 to 28: Automation. Automated blog publishing with a daily cron job that fires at 8 AM EST. Built a QuickBooks OAuth integration that lets clients connect their books directly. Built an email notification system that alerts me when syncs complete. Built ship.sh, a deployment script that handles the entire pipeline: build, test, lint, merge, deploy, monitor, smoke test, notify. One command. Walk away.

Days 29 to 38: Polish and Expansion. SR&ED tax credit tracking (more on this in Post 4). A financial model calculator with interactive sliders. Magic link client access. A presenter cockpit for client meetings. A practice management dashboard. A demo subdomain. Store page with 46 financial templates. Landing page redesign. Blog redesign with search and tag filtering.

98 commits. Dozens of client dashboards. 46 financial templates in the store. Zero engineering hires.

What the Numbers Actually Look Like

Let me be specific about the economics, because vague success stories help nobody.

Development cost: $0 in engineering salaries. My AI subscription costs roughly $200 per month. Total AI spend over the 38-day build period: approximately $600. Compare that to hiring a full-stack developer: $8,000 to $15,000 per month in Canada, minimum 3-month engagement, plus the management overhead of someone who does not understand financial services.

Infrastructure cost: Vercel free tier for the first month, then $20/month pro tier. Supabase free tier for the database. Domain names I already owned. Resend for email notifications at $0 (free tier). Total monthly run rate: under $50.

Revenue impact: One client moved from their previous rate to a premium monthly retainer after I deployed their dashboard. The price went up because the value went up. The dashboard reduced my delivery time for that client by over 80%, freeing up hours per client each month.

Multiply that across a full client roster and you start to see why I am writing this blog post instead of formatting Excel spreadsheets.

Time to ROI: The entire 38-day build, including all the mistakes and learning, paid for itself with one client in one month. The first month. Every month after that is pure upside.

What I Got Wrong

Here is what actually went wrong.

I underestimated database complexity. Row-level security in Supabase is powerful but unforgiving. I had three separate incidents where staging and production databases diverged. Columns existed in one but not the other. Trigger functions pointed at different tables. I spent full days debugging authentication issues that came down to missing RLS policies. The fix: I wrote detailed rules in CLAUDE.md about checking schema differences before every deployment.

I over-built early features. The first version of the admin panel had a newsletter management system, analytics dashboard, and user role management. Nobody needed any of that. AI assistance makes it easy to say yes to every feature idea, because the cost of building feels low. It is not low. Every feature is maintenance. Every feature is surface area for bugs. Every feature is something you have to think about when you make changes elsewhere.

I added a rule: "Build what was asked. If something seems like a separate thing, it IS a separate thing." That rule has saved me from scope creep dozens of times since.

I did not test enough on mobile. Dashboard charts that looked perfect on my 27-inch monitor were unreadable on a phone. Buttons overlapped. Text got truncated. Scrolling was broken. I had to rebuild several components to be mobile-first, which I should have done from day one. Now it is a rule: "Mobile-first design. Always include responsive breakpoints."

I pushed to production when I should have pushed to staging. Twice. Both times the site went down for less than five minutes. Both times a client could have been looking at a broken page. That fear is what motivated me to build ship.sh, the automated deployment script that makes it physically impossible to skip the staging step.

What This Means for Other Professionals

I am a CPA who builds financial dashboards. But the pattern here is not specific to finance.

If you are a lawyer, you could build a client portal that automates document delivery and status updates. Your clients check their case status the same way my clients check their cash flow: on demand, without calling your office.

If you are a management consultant, you could build a reporting dashboard that replaces your monthly PowerPoint. The data updates automatically. The client sees the metrics in real time. Your meeting becomes a strategy discussion instead of a data review.

If you are a real estate agent, you could build a property analysis tool that runs comps automatically. A mortgage calculator that pulls live rates. A client dashboard that shows their portfolio performance over time.

The unlock is not "CPAs should learn to code." The unlock is this: AI has collapsed the cost of building custom software to near zero. The bottleneck is no longer technical skill. The bottleneck is domain expertise, the knowledge of what to build and why. And domain expertise is what professionals already have.

You do not need to be an engineer. You need to know your workflow well enough to describe it in plain English. The AI handles the translation from English to software.

What I Am Building Next

The dashboard system is live. Clients are using it. But the real product is not the dashboard.

The real product is the knowledge of how to build this. How to go from "I have a manual process that is killing me" to "I have automated software that runs while I sleep."

If you want to go deeper, the AI Operator Intensive is a 4-week course where I walk you through building your first AI-powered tool from scratch. $3,000, and you walk out with a working product deployed on the internet with real users.

The Bottom Line

38 days. 98 commits. Zero engineers. One CPA with a clear problem and an AI that does not sleep.

The tools exist. The cost is negligible. The only question is whether you have a problem worth solving.

If you do, book a call and let us talk about what you could build.

Next step: run your numbers through the free CFO scorecard.