In the last twelve months, I’ve built and shipped a portfolio of AI applications without an engineering team. Two are in production: a multi-domain Next.js platform with NLP-driven web enrichment, lead scoring, and a Rover-competitive marketplace stack; and an end-to-end AI-orchestrated website-build pipeline that turns a five-minute intake form into a live, professionally-written WordPress site with no human in the build loop. Two more are working tools in solo use today: an LLM-driven blog engine that publishes directly into WordPress and a sparse-input website generator that’s the prototype for the next-generation build pipeline. And one is a delivered AI UX prototype for a private-label client.
That’s five distinct AI builds in twelve months. None of them required an engineering team.
I am a product manager. I am, by training and trade, a software engineer, but not for the last 30 years.
This used to be impossible. It is no longer impossible. But the path from “AI tools have collapsed engineering effort” to “I shipped something that’s still running while I sleep” is full of traps, and almost no one writing about this on LinkedIn is being honest about what it actually takes.
Here’s the honest version.
What the AI tools actually do
The story most people tell is “AI codes for me.” That’s not what’s happening. What’s happening is more interesting and more demanding.
Modern AI coding assistants, such as Claude Code, Cursor, and the IDE extensions, are tireless pair programmers who have read everything. They do not replace engineering judgment. They amplify it. If you walk in with no judgment, you get out a pile of plausible code that doesn’t work in the cases you didn’t think to test. If you walk in with three decades of having watched product engineering work, you get out a working system at three to five times the velocity an engineer alone could produce.
The leverage is real. The leverage requires you to know what to ask for, how to read what comes back, and where to look when something breaks. None of those skills are AI skills. They are product and engineering literacy that you build over the years.
The thing nobody tells you about
The hard part of shipping production AI is not the AI. It’s the production part.
When you build something a user touches, you have to handle:
- The case where the API call fails halfway through
- The case where the API returns something close to what you asked for but not quite
- The case where the data you’re feeding in is malformed in a way you didn’t anticipate
- The case where two users do the same thing at the same time
- The case where the cost of running this thing exceeds the value of running it
- The case where a regulator sees what you built and has questions
AI tools accelerate the writing of code. They do not yet accelerate the thinking about all of those cases. That thinking is what makes shipped software different from a demo. It is the work product managers actually do.
What I’ve built
I’ll be specific.
Local.Pet platform. Four domains (local.pet, local.dog, vetsnear.me, veterinariansnear.me) on a single Next.js 14 deployment, sharing one Postgres backend. Map-first UI. Google Places API as the data spine, with grid-cell caching to keep API spend bounded. Apify-driven web scraping to extract pet-friendly attributes that Google Places doesn’t reliably surface. Lead scoring that auto-routes high-signal businesses to outreach. A scaffolded Rover-competitive marketplace layer — booking lifecycle, escrow, three-party reviews, dispute filing with FairClaims handoff — built and gated until activated. Live in production. Full case study: roblewis.com/case-study-localpet-vetsnearme.
LocalValue.co. A WordPress multisite + n8n + Anthropic Claude pipeline that orchestrates an end-to-end website build: scrape any existing web presence with Apify, send it to Claude for analysis, send it to Claude again for full-site copy generation with structured JSON output, fetch hero and about images from Pexels using Claude-extracted queries, verify the prospect via Twilio SMS, provision a WordPress subsite, push everything in, and cut over to the customer’s domain after verification. The plugin alone is around 5,500 lines of PHP, exposing an authenticated REST API for provisioning, verification, and domain mapping. Live in production. Full case study: roblewis.com/case-study-localvalueco.
AutoBlog. An LLM-driven blog engine that drafts, formats, and publishes posts directly into WordPress via the REST API. Two-pass Claude generation (outline + body) with site-specific voice configuration. Working tool in solo use today; productization is downstream of demand signals from existing clients. Full case study: roblewis.com/case-study-autoblog.
AutoWebDev. A prototype for the next-generation LocalValue.co build engine — generates entire websites (page architecture, copy, layout, imagery, brand profile) from sparse intake. Multi-pass Claude orchestration that produces a site specification as an intermediate artifact before any CMS is touched. Working tool in solo use today; the capability folds into the LocalValue.co pipeline as v2 when quality consistency is met. Full case study: roblewis.com/case-study-autowebdev.
Deals Discovery. AI UX prototype delivered to a private-label client; built initially on Abacus.AI.
Two production. Two are working solo. One was delivered to a client. All five were built without an engineering team.
What I had to do that the AI didn’t do
This is the section that doesn’t show up on LinkedIn.
Architectural decisions. Claude can suggest twenty architectures. Picking the right one, the one that fits where the business is going, what the budget supports, and what the operating constraints are, is judgment, and the AI doesn’t have your business context. I made calls like “single Vercel deployment serving four domains via middleware” because I knew what was coming for ops, not because Claude picked it.
API cost control. Google Places, Apify, Anthropic, Pexels, Twilio. Each one has a way to bill you into bankruptcy if you’re not careful. Daily spend caps, grid-cell caching to deduplicate calls, webhook-based async patterns instead of synchronous spending, every one of those is a product decision driven by financial discipline that no AI is going to enforce for you.
Schema design and data modeling. Twenty-five Prisma models in Local.Pet. Decisions about what’s a relation versus what’s an enum versus what’s just a JSON column. AI helped me write the schema once I knew what I wanted. I had to know what I wanted first, because three weeks of work on a wrong schema is three weeks I can’t get back.
Decision logs and PRDs. Every architectural choice I made on Local.Pet lives in a dated decision log with a one-line rationale. Every feature has its own PRD. This is product hygiene that has nothing to do with AI and everything to do with not getting confused by your own past self when you come back to a piece of code in six months. The AI doesn’t write the decision log unless you make it. Most solo builders don’t make it. Then they get confused.
Knowing when to gate. Local.Pet has a full Rover-competitive marketplace built in code, booking, escrow, reviews, disputes. None of it is user-facing yet. I narrowed v1 to “listings + contact form only” because I want to validate the directory and lead model before exposing the marketplace. The code is scaffolded and feature-flagged behind documented gates. That call, to build the code but not ship it to users, is one no AI tool would push you to make. Most solo builders ship everything they build. Then they regret it.
What this actually requires
Here’s my honest read on the prerequisites for shipping production AI as a solo operator:
- Product judgment. Three decades in my case. It doesn’t have to be three, but it has to be enough that you’ve watched things break and learned what breaks them. AI gives you velocity; it doesn’t give you direction.
- Engineering literacy. Not the ability to write a sorting algorithm from scratch, but enough fluency to read code, understand what it’s doing, and notice when it’s doing the wrong thing. This is the gap most “no-code” advocates underestimate.
- Operational discipline. Spend caps, monitoring, error handling, audit trails, decision logs, version control, and deployment hygiene. The AI doesn’t enforce any of this. You have to.
- Patience for the boring 80%. The AI handles the interesting 20%: the algorithm choice, the prompt engineering, and the API integration. The boring 80%, handling errors, validating inputs, writing migration scripts, and debugging why Vercel is doing something weird with the middleware, is yours.
If you have those four, AI tools genuinely make a one-person product team viable. If you don’t, AI tools accelerate your ability to ship something that doesn’t quite work.
Why this matters for the AI consulting market
The implication for the consulting market is direct. Anyone advising SMBs on AI adoption today should have shipped at least one thing. The advice that comes from people who have shipped is materially different from the advice that comes from people who haven’t, and SMB owners can’t tell the difference until they’re three months and twenty thousand dollars into a project that isn’t working.
If you’re an SMB owner: ask the consultant to show you something they’ve shipped. Ask to see code. Ask to see the prompt running in production. The bar is shippable, not articulate.
If you’re a PM thinking about pivoting into AI consulting: ship something. The consulting follows.
If you’re me, you keep shipping.
Rob Lewis is the founder of Local Value LLC and an AI Product Consultant for SMB and mid-market businesses. He has three decades of senior product leadership experience and ships production AI applications. Reach him at roblewis@localvalue.com.