What I Actually Built With AI - How I Ended Up Here (Part 3)

Most of the AI content I see online falls into two categories. The first is hype: “AI will replace your entire team” headlines written by people who haven’t replaced a single process. The second is surface-level: chatbot demos, summarization tricks, prompt templates. Neither tells you what it actually looks like when a founder uses AI to build real tools for a real business.

So let me show you what I built.

I mentioned this briefly in Part 1. At tradeshows, our sales staff were still taking orders on handwritten forms, walking them to a counter where someone would manually key everything into Shopify while the customer waited. The customer just committed to spending $700 or more on a standing desk, and their first post-purchase experience was watching someone squint at handwriting and type it into a laptop.

This was 2025. Not 2005.

The process technically worked. Orders got entered. Payments got processed. But it was slow, error-prone, and it created a bottleneck at the counter during peak traffic. I’d wanted to fix it for years, but scoping and building a custom Shopify POS extension felt like a project that needed a developer, a timeline, and a budget I couldn’t justify.

With Claude Code, I built it in a few days. A proper POS extension that let our sales staff enter orders directly on tablets on the showroom floor. Product selection, customer details, payment processing, all flowing straight into Shopify without the handwriting step. No middleman. No transcription errors. No customer standing around waiting.

The total cost was my time and a Claude subscription. The alternative would have been hiring a Shopify developer for a custom project, quoting weeks and thousands of dollars.

This is the one that changed my mornings.

I used to spend roughly two hours every day pulling numbers from Shopify, Klaviyo, Meta Ads, and our internal systems, then assembling them into something that told me how the business was doing. Revenue by channel. Ad spend and ROAS. Email performance. Stock levels. Cashflow position. Two hours before I could even start making decisions.

I built a daily briefing system with Claude. It pulls from our key data sources, processes the numbers, and delivers a structured morning report. The whole thing runs automatically. What used to take two hours now takes five minutes to review.

Five minutes. Same information. Same level of detail. But instead of spending my first two hours as a data entry clerk, I spent them as a CEO.

The philosophical shift mattered more than the time savings. I went from being the person who assembled the reports to the person who acted on them. That’s a different job. A better one.

The same pattern repeated across the team. My direct reports were each spending significant time on weekly reports: compiling data, formatting updates, summarizing what happened and what’s planned. The reports were useful, but the process of creating them was eating hours that could have been spent on actual work.

We rebuilt the reporting workflows so the repetitive data compilation happened automatically. The team went from spending hours compiling data to spending their reporting time on interpretation and decisions, not on pulling numbers from spreadsheets and formatting them into slides.

The result: roughly 80% reduction in reporting time across all seven direct reports. Not 80% less information. The same information, assembled in a fraction of the time.

A few months into my AI exploration, someone came to me with a business concept. They had the domain expertise and the market insight, but no way to visualize the product or build the underlying system. They needed a UI/UX design, a functional prototype, and a recommendation engine that could learn from user behavior.

I built all of it. The full interface design, the user flow, and a self-learning recommendation algorithm that improves as it collects data. Not a mockup. A working system.

This wasn’t a favour. It was a proof of concept for what I’d been thinking about: what happens when someone with operational experience and AI tools sits down with a founder who has domain knowledge but no technical capacity? You get real output. Not a slide deck. Not a strategy document. A working product.

That project became the clearest illustration of what my future could be. Not advice. Implementation. A founder-operator who’s done the work on his own P&L, now doing it alongside other founders on theirs.

I want to step back and name what’s actually happening across these examples, because it’s not what most people assume.

I’m not a developer by profession. I can code. I’ve built ecommerce stores, written CSS and JavaScript, understood enough web development to evaluate what a developer was building. But I’m not someone who would have attempted a custom Shopify POS extension, a self-learning recommendation engine, or an automated financial reporting system before Claude Code.

What changed wasn’t my skill level. It was the gap between what I could conceptualize and what I could actually build. Before AI, I could see the solution clearly but couldn’t execute it without hiring someone. Now I can go from “this process is broken” to “here’s the working fix” in days, sometimes hours.

Claude Code didn’t make me a developer. It made my existing knowledge productive. I know what good data architecture looks like because I spent years in SAP consulting. I know what a good POS workflow looks like because I’ve run tradeshows. I know what a CEO morning briefing should contain because I’ve been assembling one manually for seven years.

That’s the thesis. Not “AI replaces people.” Not “AI makes everyone a programmer.” AI amplifies what you already know. If you know your business deeply, AI gives you the tools to act on that knowledge at speed. If you don’t know your business, AI gives you faster nonsense.

Every founder I talk to has a version of my tradeshow POS problem. Some process that’s been bugging them for years, that they know how to fix conceptually, but that they’ve never had the time or budget to actually build the solution for.

The calculus has changed. The question is no longer “can I afford to hire a developer for this?” The question is “can I describe what I need clearly enough to build it myself?”

If the answer is yes, and you have the domain knowledge to evaluate whether what you’ve built actually works, you’re probably sitting on a dozen quick wins right now. Not moonshot AI projects. Practical fixes that save hours, reduce errors, and let you stop being the bottleneck in your own company.

That shift, from operator to architect, is what the rest of this series is about.

The free section told you what I built. This section shows you how to build your own. These are the patterns I’ve refined over dozens of builds since January 2026.

Start with the pain, not the technology. The worst AI projects begin with “what can AI do?” The best ones begin with “this specific process wastes X hours per week and produces Y errors.”

The scoping framework: 1. Identify the friction. What process do you or your team dread? What takes too long? What produces errors? Write it down in plain language. 2. Map the current workflow. Every step, including the manual ones nobody wants to admit exist. The handwritten tradeshow forms. The copy-paste between spreadsheets. The “I just remember to do it” steps. 3. Define “done.” What does the fixed version look like? Not “better.” Specific. “Orders entered on tablets in under 2 minutes” or “morning report delivered by 7am without manual input.” 4. Estimate the stakes. How many hours per week does this consume? What’s the error rate? What’s the cost of those errors? This tells you whether the build is worth your time.

If you can’t describe the pain specifically, you’re not ready to build. Go observe the process for a week first.

What it’s good at: - Building web interfaces and applications - Processing and analyzing data from CSVs and APIs - Creating automation scripts that connect existing tools - Iterating quickly on prototypes - Writing code in JavaScript, Python, HTML/CSS, and most common languages

What it’s not good at: - Anything requiring real-time access to your production systems (you need to export data or build API connections) - Replacing judgment calls that require deep business context (it amplifies your judgment, it doesn’t replace it) - Building at enterprise scale without additional architecture - Tasks where you can’t evaluate the output (if you can’t tell whether the result is right, AI won’t help)

The pattern is consistent: Claude Code is a multiplier, not a replacement. It multiplies whatever knowledge and judgment you bring to the conversation.

Build when: - The process is unique to your business (no off-the-shelf tool does exactly this) - The cost of a custom solution from a developer would be $5K+ and weeks of timeline - You can describe the requirements clearly and evaluate the output yourself - The build is scoped to a specific, contained problem

Buy when: - A well-established tool already solves 80%+ of the problem - The problem requires ongoing maintenance and updates you can’t commit to - Compliance, security, or reliability requirements exceed what a solo build can guarantee - The time to build exceeds the time saved within a reasonable payback period

Most of what I built falls in the “too specific to buy, too expensive to hire for” category. That’s the sweet spot for AI-assisted building.

Core: - Claude Code for development and analysis - Shopify as commerce platform - Klaviyo for email marketing - Meta Ads for paid acquisition - Google Sheets for data that needs to be shared with the team

The workflow: 1. Export data from the relevant platform (Shopify, Klaviyo, Meta, whatever) 2. Feed it to Claude with a specific question or task 3. Iterate on the output until it matches what I need 4. Deploy the result (whether it’s a tool, an analysis, or a process change) 5. Test with real data before rolling out to the team

Nothing exotic. No custom AI infrastructure. No machine learning pipeline. Just a founder, an AI tool, and the willingness to describe what needs fixing.

If you’ve never built anything with AI, start here:

The first build is rarely elegant. It doesn’t need to be. It needs to work, and it needs to show you what’s possible.

Once you’ve built one thing, you’ll see the second and third opportunities immediately. That’s how it went for me. The POS extension led to the financial model, which led to the team reporting overhaul, which led to the attribution audit. Each build made the next one faster because I understood the tool better and could scope the problems more precisely.

What’s the most annoying process in your business right now, the one you’ve been putting off because it felt too complicated or too expensive to fix? I’d genuinely like to know.

Next week: Part 4, “AI Isn’t the Moat. Domain Knowledge Is.” Why most AI consultants are selling hype, and what happens when the founder who did the work on his own P&L decides to help other founders do the same.