I’ve been in the tech industry my entire life, but up until two years ago, I had never written a single line of code. Today, I’m building secure, multi-tenant, full-stack applications.
How? By leveraging AI. But not in the way most people think.
There is a massive misconception among business leaders that building with AI means typing a prompt into a chat window and watching a finished app pop out. That’s a parlor trick. Asking Claude to write a Python script is a great starting point, but it’s not engineering.
Real AI development, the kind that replaces massive enterprise contracts and solves complex, real-world problems requires more than a vibe-coding session. It requires architecture, discipline, and a willingness to break things in development so they never break in production.
Here is what the last 24 months of building actually looked like, and why the era of paying for bloated software you only use 10% of is officially over.
The Arc of an AI Developer
In the early days, my education started with “vibe coding.” I used AI-powered development environments like Bolt to spin up simple landing pages. I broke things often. It was low-level, but it was the spark.
From there, the training wheels came off. The evolution of building looked like this:
Phase 1: Vibe coding simple experiences deployed directly to Vercel.
Phase 2: Structuring code within proper GitHub repositories.
Phase 3: Wiring up relational databases and executing edge functions.
Phase 4: Building end-to-end setups with multi-tenant architectures.
Phase 5: Implementing Row Level Security (RLS) to ensure absolute data isolation between clients.
Phase 6: Shipping client-facing, full-stack applications backed by daily local vulnerability scans.
Phase 7: Monetizing my learnings with paid clients.
AI didn’t just give me a shortcut; it gave me an entire engineering assembly line.
Why did I spend countless hours learning to build this infrastructure? Because it’s obvious where the future of business is heading, and it’s not buying more bloated legacy SaaS.
My Current Arsenal
You don’t need a massive team of engineers to build robust software anymore. You need the right tools orchestrated perfectly. Here is the stack I currently use to outpace traditional development:
The Engine: Terminal-based Claude Code (for deep, systemic coding) & Claude Design (for UI/UX architecture and component generation). (Codex #2, Antigravity #3 and I switch it up often.)
The Infrastructure: GitHub (version control) & Vercel (continuous integration and edge deployment).
The Powerhouse: Supabase (PostgreSQL database, Edge Functions, and Authentication).
The Security: The stack above itself provides a very strong security layer, but my new personal agent, Hermes runs daily security scans and repository configuration checks.
The Connectors: Microsoft Azure and Docker for containerized workloads, Resend for programmatic routing, Anthropic API for the intelligence layer and too many other specialized APIs to count.
Eating My Own Dog Food: Business Builds
Why did I spend countless hours learning to build this infrastructure? Because it’s obvious where the future of business is heading, and it’s not buying more bloated legacy SaaS.
Traditional SaaS platforms are designed to be everything to everyone, which means you pay a premium for features you never use. I realized that when you build to solve your exact problem, you see just how bad the legacy options really are. Back in the day, we had to deal with it. Those days are gone.
Here is what I’ve built to replace my SaaS subs, and I’m just getting started.
The Mailchimp Killer (Newsletter Engine): The Operator’s AI Brief ships every Friday from a sending platform I built myself. Contact upload, HTML editing, list management, and delivery all run through Resend and edge functions, which means the marginal cost of a send is API calls rather than a pricing tier that punishes me for growing a list. Five fixed sections every week, so readers know what they are getting before they open it. My Hermes agent builds it, based on a week of historical work context, and sends it to me for approval. SUBSCRIBE
The Trello Killer (EngagementOS): Every project tool I tried made me maintain the tool. EngagementOS inverts that: one system built around how I actually run client engagements, showing me the next action across every account instead of a wall of cards I have to drag. It is the difference between software that stores your work and software that tells you what to do next.
The HubSpot Killer (Mindmoor): I was paying way too much money to bend my sales process around someone else’s idea of a CRM. So I built Mindmoor: React, Supabase, and the Anthropic API, with form fills being the last data entry option. You paste an email, a note, or a business card and the record assembles itself, each field scored for confidence. The home screen is a command center instead of a table of rows: weighted forecast, what I owe people, what people owe me, and a morning brief assembled from inbox and calendar signals. It stopped being a personal tool in July, when the first client signed on for an org-wide deployment running on its own database, its own keys, and its own subdomain.
How I’ve Learned The Most? Personal Builds
If you want to test the limits of your stack, you build things for yourself. These personal projects pushed me to integrate complex APIs, hardware, and OCR (Optical Character Recognition) into seamless applications. I’ve learned that when the outcome matters to you personally, you push yourself harder and work through the pain and frustration.
The Hyper-Local Weather App: The standard weather networks aren’t accurate enough for our home near the shores of Lake Michigan. I was also tired of pop-ups, accidental ad clicks, and premium upgrade requests. So, I built my own. I tuned the app to my exact Latitude/Longitude, parsing disparate JSON data streams from Lake Michigan NOAA buoys, the National Weather Service, and Apple WeatherKit to calculate the exact lake temperature effect on our shore. It’s currently in Apple’s TestFlight with neighbors doing the user testing for me.
The 1965 Karmann Ghia Ledger: The restoration history of our classic car was trapped in a massive, physical folder of receipts, handwritten notes, and work orders. When my mechanic asked a question, I had to rifle through paper. I used AI to scan, digitize, and parse decades of documents, creating a structured, searchable timeline and ledger application. It is now the single digital source of truth for the vehicle.
The NFC Family Organizer: This isn’t your standard shared calendar. It tracks medications, refill dates, and pushes notifications before pickup. But the real flex is the hardware integration: using physical NFC tags around the house. Take a medication? Tap your iPhone to the bottle’s NFC tag to instantly log it in the Postgres database. Running low on coffee? Tap the tag in the pantry, and a webhook instantly adds it to our Costco shopping list.
The Reality Check
More and more executives and peers reach out and ask the exact same question: “How can I start building with AI?”
The reality is that it’s easier than ever to build enterprise-grade solutions, but it requires work.
The characteristics that allowed me to do this aren’t rooted in a computer science degree. They are rooted in being curious as hell, being totally comfortable breaking things, and having a relentless willingness to test new platforms. The short version is that I got really comfortable with being uncomfortable.
While anyone can do what I’ve done, most people simply aren’t driven enough to get there. I’ve seen it firsthand. Out of every ten friends who ask me how to “build with AI”, maybe one actually gets after it. But when that one person dives in and my phone starts blowing up with their questions. That gives me immense satisfaction. It tells me something about who they are, and how they think.
The tools are out there. The bloated software monopolies are vulnerable. What most companies are missing is not talent or budget. It is a starting point.