I Built Two AI Platforms in Two Days

I run a $70M+ construction company. I have five kids. I serve as an elder at my church. I am not a software engineer and I have never been one. Somewhere around the first weekend in April 2026, I decided to build two AI-native SaaS platforms from scratch, in parallel, in about forty-eight hours of actual working time.

By Monday both were live. operationalcfo.ai — AI-powered financial tools for business owners — had a 27-tool library, an AI CFO Advisor wired to QuickBooks, a diagnostic, a Pulse Report generator, and a pricing page. cfoos.ai — the career platform for finance professionals becoming Operational CFOs — had an AI Career Coach, the Five-Command Readiness Assessment, 10 Academy courses, role pages, career-path pages with readiness quizzes, and a toolkit.

Between them, more than 130 routes. Six integrations (Clerk auth, Stripe, Anthropic, Supabase, Prisma, Resend). A shared philosophy. Two distinct visual systems. Two audiences.

I want to tell you how that actually happened. Not the marketing version. The honest version — what AI handled, what I had to direct, where it struggled, what I got wrong, and what it means for every operator reading this.

The Starting Point

For months I had been watching business owners I knew — real ones, not startup-Twitter caricatures — struggle with exactly the problems that a CFO would have solved for them in thirty minutes. One friend of mine didn't know his gross margin by service line and was about to hire a $100K person he couldn't afford. Another was getting panicked by his bookkeeper about cash without understanding why the numbers looked bad. A third was getting pitched a fractional CFO engagement at $7,000/month when what he actually needed was a good monthly dashboard and twenty minutes of common sense per month.

I had been the fractional CFO on calls like these. I had built the models. I had walked the owners through them. I had seen the relief on their faces when they could finally see their own business. And I had thought: this is the most leveraged financial work in the world, and almost no one has access to it.

I had also been watching Claude. Not tinkering with it — actually using it every day for a year, on real CHE operational work. I had automated meeting-to-action flows. I had built a daily pulse report that summarized my inbox into a strategic brief. I had used it to draft contracts, to analyze budget variances, to debug vendor invoice discrepancies. Claude wasn't a curiosity. It was a coworker.

Somewhere in the first week of April, it clicked: Claude Code can build what I can describe. And I can describe a CFO platform because I've been running finance for twenty years. The gate between "I have an idea for a SaaS product" and "the SaaS product exists" had collapsed.

I cleared the weekend.

The Forty-Eight Hours

I don't want to romanticize this. It was not a 48-hour heroic feat. It was 48 hours of very focused, very directed work where I spent most of my time thinking — about structure, about information architecture, about who each platform was for — and Claude spent most of its time writing.

The shape of the work:

Hours 1-4: Architecture decisions. I sat with Claude and thought out loud. Two sites or one? Separate domains or subpaths? Shared component library or duplicated? Clerk or Supabase Auth? Stripe subscription or one-time? Prisma or direct Supabase? These are the decisions every software founder agonizes over for weeks. I made them in half a day because I had enough AI-pairing experience to know what the downstream consequences of each would be.

Hours 5-12: Component library and design system. I described the brand feel I wanted for each site — warm teal for business owners on opcfo, deeper navy for the career platform on cfoos. Claude generated the globals.css, the component patterns, the type system. I iterated on maybe a dozen rounds of tightening until it felt right. Same for cfoos. Parallel work streams.

Hours 13-24: The core tools. This is where the speed compounded. For each tool I wanted — Cash Flow Forecaster, Margin Analyzer, Pricing Calculator, Break-Even, DSCR, Hiring Calculator, AR Aging, on and on — I described the input form, the calculation logic, and the output format. Claude wrote the page. We tested it, fixed the edge cases, moved on. Each tool took 15-30 minutes. Twenty-seven tools got shipped in roughly ten hours of this kind of work.

Hours 25-36: AI surfaces. The AI CFO Advisor, the AI Career Coach, the AI Pulse Report generator, the AI assessment insights. Each is a thin UI over an Anthropic API call with a thoughtful system prompt and context injection. I wrote the system prompts myself — that's the part where domain knowledge mattered most. Claude wired the routes, the rate limiting, the auth checks, the streaming responses.

Hours 37-48: Content + integrations + polish. The Academy courses needed real content (I wrote the course outlines, Claude drafted the lessons, I rewrote them with personal stories). The pricing page needed Stripe product IDs and checkout flows. The email pipeline needed Resend templates. The diagnostics needed the scoring logic. This is where the sites became products instead of prototypes.

Forty-eight hours. Two live platforms. Both deployed to Vercel with production environments, analytics, error tracking, and real users.

What AI Handled Well

Boilerplate code. Every page skeleton, every form component, every API route. Claude has ingested so much Next.js and Tailwind code that generating a well-structured page from a description is near-trivial. I didn't type a single `

` tag in those 48 hours.

Parallel variations. "Build me the Cash Flow Forecaster, then the Pricing Calculator, then the Break-Even Calculator" — all three share a pattern (input form → calculation → result card → explanation). Claude did them in sequence without me having to re-explain anything. Variation on a theme was an order of magnitude faster with AI than without.

Integration code. Stripe checkout sessions, Clerk auth middleware, Supabase queries, Resend email templates. These are well-documented services with patterns Claude has seen thousands of times. I described what I wanted; Claude wrote code that worked on the first try roughly 80% of the time.

Documentation. Every API route got a comment block describing what it does. Every complex function got a docstring. Not because I asked — because Claude does it by default when the surrounding code deserves it.

Refactoring. Midway through I realized I'd duplicated a pattern across six tools. I asked Claude to extract a shared component. It did, correctly, across all six files, in under a minute. That refactor would have been an hour of focused pair-programming with a human engineer.

What I Had to Direct

Product decisions. "Should the AI advisor be rate-limited per day, per week, or per session?" AI doesn't have a strong opinion on product questions. I had to decide. "Should the assessment gate the score behind email, or show the score and gate the AI plan?" I had to decide. "How much of the Academy should be free?" I had to decide.

Taste. What should the homepage hero feel like? What tone should the course lessons strike? When is a form too long? When does a page have too many CTAs? These are taste questions. Claude will generate something competent, but if I want it to actually be good, I have to direct. Every page went through 3-5 iterations of my taste calls.

Information architecture. The scenario router on the cfoos homepage — six different "who are you?" cards that route users into the right path — was entirely my structure. I told Claude the skeleton; Claude wrote the markup and the copy. But the IDEA that users need a self-select router at entry was mine. AI doesn't originate information architecture. It fills in.

The content with personal voice. My career story. The Tower rescue. The Campbell reframe. The "why I built this" paragraphs. I wrote all of those. Claude drafted some; I rewrote almost everything. Personal voice is the one thing AI still can't generate that sounds like me.

What AI Got Wrong (the Honest Part)

Three specific things I want to name.

Hallucinated APIs. Multiple times Claude wrote code calling a function or library method that didn't exist. Always plausible-sounding. Never correct. The safety net was TypeScript's compiler — but if I'd deployed without type-checking, the site would have broken in production. You cannot skip the type-check step when building with AI. I run `bunx tsc --noEmit` before every commit. If I didn't, I'd be deploying hallucinations.

Overconfident architecture on the first pass. Early in hour 3 I asked Claude how to structure the multi-tenant auth across both sites. It gave me a confident answer. I went with it. By hour 20, I realized the approach it recommended wasn't going to work for how Stripe billing needed to cascade to feature flags. I had to rewrite a chunk. Lesson: AI is excellent for tactical code but slightly underweights downstream implications. I should have pushed back harder at hour 3 and asked "what's the failure mode?"

Stale knowledge on Next.js. Next.js 16 has breaking changes from 15 (different proxy.ts vs middleware.ts, different edge runtime behavior). Claude defaulted to Next.js 15 patterns. I had to explicitly instruct it to read the current docs. Once I did, it adapted. But a less experienced builder would have fought a hallucinated framework for hours before realizing the pattern was obsolete.

What the Old Rules Were

Here's the belief I had to unlearn.

The old rule: building software is a specialized craft that requires years of training, a team, and a budget.

That was true in 2023. It was true in 2024. It was partially true in 2025.

It is not true in 2026.

In 2026, building production software is a skill that stands on three legs: (1) you need to have taste, (2) you need to know what you're building for and why, and (3) you need to be able to direct an AI with enough specificity that it can execute. That's it. The typing is no longer the bottleneck. The expertise is no longer the bottleneck. The new bottleneck is CLARITY — can you describe what you want clearly enough that a capable AI can build it?

This is the collapse of the gate, and it is the most important business-strategic development of the next decade.

What This Means for Operators

If you are a CEO, an owner, a founder, or a senior leader, and you cannot build software with AI — or at least CAN'T direct the building of it — you are now competitively blind.

Here's why:

- The thing you have that your competitors don't is your specific operational knowledge. The procurement process that works for your business. The pricing logic your customers actually respond to. The reporting view your team needs. That knowledge, turned into software, is competitive advantage.

- In the pre-2026 world, turning that knowledge into software required hiring engineers, writing specs, managing projects, and waiting months. Most operators never did it — too slow, too expensive, too uncertain.

- In the 2026 world, you can turn operational knowledge directly into software yourself, in days. If you are the operator, and you do this, your competitor without these skills falls behind fast.

I built operationalcfo.ai and cfoos.ai because I wanted to serve a mission I cared about. But along the way, I also built a new CHE operating tool every other week. An AI-powered meeting processor. An automated close package generator. A proprietary vendor relationship tracker. None of those will ever be public products. They're internal tools that make CHE more defensible. Every operator in 2026 should be doing this, and most aren't, because they haven't realized the rules changed.

ITABWODI, Applied to Building Software

The question I asked at Campbell in 2001 applies here too.

Is there a better way of doing it?

The old way of building software: hire engineers, write specs, manage projects, iterate for months, hope the PM understood the requirement.

The new way: be the PM, be the engineer, be the designer, direct an AI that handles the typing, iterate in hours instead of months, watch your own idea ship the same week you had it.

Is there a better way? Yes. The better way is here. It's called Claude Code, it's two years old, and it's already rewired what a single operator can ship.

What I Would Tell Anyone Starting

Three things.

First: learn to pair with AI BEFORE you try to ship anything. Spend a hundred hours using Claude on real work before you try to build a product with it. Build the muscle of directing, reviewing, correcting, and iterating. The people who fail at AI-assisted building are usually the people who thought it would do the thinking for them.

Second: start with something you KNOW. I could ship a CFO platform in 48 hours because I've run finance for twenty years. I couldn't ship a social network for dentists in 48 hours because I don't know that business. Your domain knowledge is what makes the AI's speed actually useful. Without it, you'll ship plausible-looking garbage.

Third: the hard parts are still hard. Decisions. Taste. Information architecture. Product strategy. Customer discovery. Pricing. The actual BUSINESS of the business. AI doesn't make those easier. It makes the EXECUTION of them faster, which makes the thinking MORE leveraged than ever. Don't skip the thinking.

Closing

Two platforms in two days. Not because I'm special. Because the tools got good enough that a non-technical CEO with domain knowledge and taste could do this.

If you're an operator reading this and thinking "I could never" — I promise you: you could. Start small. Automate one workflow. Build one dashboard. Ship one internal tool. In six months you'll look back and wonder what took you so long.

The question that got me from Campbell 2001 to a $70M CEO seat also got me from non-technical operator to AI-native builder in a weekend.

Is there a better way of doing it?

Almost always, yes.

And in 2026, you get to BUILD the better way yourself.