Fall in love with the problem. Not the solution.

LinkedIn

A sales guy who probably shouldn't be building software.

25 years in enterprise sales. No CS degree. No dev team. Just real problems worth solving and enough curiosity to be dangerous. Building AI-powered applications on my own time, with my own money, sharing everything I learn along the way.

A lot can happen in a few weeks. Apparently.


I published my first post fourteen days ago or so. Since then I built and got demo-ready a white-labelled version of my platform, launched a community website for a small coastal community, refactored my main codebase in a way that finally made me feel like I knew what I was doing, started an apparel line to raise money for a child in need, and learned something genuinely useful about how AI reads instructions. My accountant remains unmoved. The fish are still not biting.

Here's what happened.

  1. The real test is when someone else's name is on it I built a white-labelled version of my sales intelligence platform. Different branding, scoped data, real stakes. There is a specific kind of focus that arrives when you know someone else is going to click your buttons in front of their boss. Everything I had been casual about suddenly demanded attention. Error handling. Loading states. Fringe cases. Ship for yourself, learn for yourself. Build for someone else, learn faster.
  2. Not everything you build is for work Sixty households in a small coastal community have a Facebook group. Now they have a proper community site with a bulletin board, events, RSVPs, a photo gallery, a document library, a member directory, an admin panel, and Auth0 for secure login. It runs on Flask and Supabase and costs almost nothing to operate. I built it because someone needed it. That turned out to be a better reason than most.
  3. The file was too big and it was my fault I pulled 344 lines out of my main application file and distributed them to where they actually belonged. This is called separation of concerns. I know that now because I violated it for six months first. The first version worked. The second version was cleaner. The third version was honest. The lesson isn't the refactor. The lesson is that you can't see the mess until you've lived in it long enough.
  4. The apparel line was not in the plan There is a child in my community who lost his Mom two and a half years ago and his Dad on February 27th this year. He needs support. That was the plan. One conversation about how to raise money turned into a geometric logo, which turned into a cap design, which turned into a Shopify storefront. Richardson 112s. Gildan hoodies. A K mark that actually looks good. One hundred percent of proceeds go where they're supposed to go. I don't know what that has to do with AI tools. But it felt like the right thing to build next, so I built it.
  5. Instructions are a design problem I spent time this week learning how AI reads structured instruction files — documents that tell an AI model exactly how to behave for a specific task. Think of them as a recipe the AI follows before it starts cooking. Getting them right is harder than it sounds. The words matter. The order matters. What you leave out matters as much as what you put in. Writing clear instructions for a machine turns out to be excellent practice for writing clear instructions for humans. I'm working on both.

A few weeks. Five things. Zero regrets and one mild panic when I couldn't remember if I'd cleared the test data from a demo build. I had.

Thanks to Ryan Clark, Stephen Thorne, Rob Wyse, Kevin West and Shamis Thomson. And to everyone who read the first post and said something kind about it. That didn't have to happen and I noticed.

#AI#BuildingWithAI#LearnWithMe#ClaudeCode#Python#BuildingInPublic#AILeadership#Google Gemini

Every two weeks a new entry drops. Honest. Humorous. Useful. The wins, the rebuilds, the 11 PM debugging sessions, and whatever the AI taught me that I probably should have already known. No polish. No filter. Just the actual journey.

Nobody taught me how to build software. In fact I still don't know how to build software.....Yet

Maybe one day soon. Definitely.

I'm a 25-year sales professional who would honestly rather be standing in a river chasing steelhead. But the fish aren't biting and the AI is.

Over the last six months I've built four AI-powered applications, on my own time, with my own money, learning everything from scratch. My accountant is not impressed. But some of my peers are. That's good enough for me. For now.

If you're curious about how to do the same, here's what someone told me:

01. Start with the spec, not the code Draw your data model before you write a single line of code. Map your entity relationships. Define how your data moves between services before those services exist. The functional design document isn't paperwork. It's the moment you find out whether you actually understand the problem. Skip it and you'll rebuild the same thing twice. I know this because I rebuilt the same thing twice. Or more.
02. Treat security like it's day one Because it is. Identity management, MFA, role-based access control. These aren't features you add later. They're decisions that shape everything underneath them. By the time you're thinking about security at the end, your architecture is already working against you. And so is your sleep schedule.
03. Your framework is a long-term relationship Whatever you choose, understand what you're committing to. Flexibility early has a cost as complexity grows. Changing it later isn't refactoring. It's starting over. With coffee. Lots of coffee.
04. Stop thinking about single models Start thinking about systems. I use Perplexity for real-time research, Claude for reasoning and strategy, and Gemini when I need a different perspective on a hard problem. A visual workflow automation tool ties it all together. Google NotebookLM turns documents into audio intelligence. The real power isn't any one tool. It's knowing how to connect them.
05. Data design is the job nobody talks about How your services pass information to each other, what goes in, what comes back, what gets stored, determines whether your system is reliable or fragile. Get the contract right. Your future self will either thank you or have some very strong feelings about your past self. I'm prepared for harsh words from my future self.

And the one thing no tool gives you: knowing the problem deeply enough to build the right solution. That still comes from you.

I'll keep sharing what I learn as I build. If this is useful, follow along.

Thanks to Ryan Clark, Stephen Thorne and Kevin West. And to Rob Wyse and Shamis Thomson.

#AI#BuildingWithAI#LearnWithMe#ClaudeCode#Python#Auth0#AILeadership#BuildingInPublic

Every two weeks a new entry drops. Honest. Humorous. Useful. The wins, the rebuilds, the 11 PM debugging sessions, and whatever the AI taught me that I probably should have already known. No polish. No filter. Just the actual journey.