Building an AI Side Project That Actually Ships — Lessons from Shipping 3 MVPs

We all know the drill: you see a new frontier model drop, get that spark of inspiration at 11 PM, and three hours later you've got a repository with a vague README, a half-baked prompt, and a dream. Two weeks pass. The repo gathers dust. You never told anyone about it.

I've been there. More times than I'd like to admit.

But somewhere over the last two months, something shifted. I actually shipped three AI-powered MVPs. Not as part of some content-creation challenge, but as genuine experiments. And all three have real users today — not thousands, but dozens. People I didn't know. People who found them organically.

This isn't a "how I got 10,000 users" post. This is a post about the messy reality of building AI things that survive the first week.

The lie we tell ourselves about AI side projects

Here's the uncomfortable truth: most AI side projects fail not because the idea is bad, but because the builder treats it like a puzzle to solve rather than a product to launch.

I remember my first attempt. I spent two weeks building a "meeting notes summarizer." I wired up Whisper for transcription, used some elaborate RAG pipeline for context, fine-tuned the prompts. Beautiful architecture. Truly impressive stack.

I didn't ask a single person what they actually needed.

The result? I had the product hunt equivalent of a technical demo. Nobody used it because nobody was looking for it. The "solution" I built solved a problem I invented.

When I sat down to rebuild this round, I forced myself to follow a different set of rules.

Rule 1: The 72-hour deadline beats the perfect architecture

My first shipped MVP started with a conversation on a Discord server. Someone complained about having to manually extract pricing data from competitor websites. It was a boring, boring problem. Perfect.

I set a timer: 72 hours from idea to launch. Not 72 hours of coding — 72 hours of anything, including sleep and my day job.

Here's what that constraint does mentally: it strips away every "nice to have" and leaves only the bare expression of the idea. You stop thinking about database optimizations and start thinking about "what's the absolute minimum thing that solves this?"

# This is the entire core of my pricing extractor MVP
# It's ugly. It's naive. It works.

import re
import requests
from bs4 import BeautifulSoup

def extract_pricing(url):
    """Grab any dollar amounts from a pricing page. That's it."""
    try:
        resp = requests.get(url, timeout=10, headers={
            "User-Agent": "Mozilla/5.0 (side-project-bot)"
        })
        soup = BeautifulSoup(resp.text, "html.parser")
        # Remove script and style tags to reduce noise
        for tag in soup(["script", "style"]):
            tag.decompose()

        text = soup.get_text()
        # Look for common pricing patterns
        matches = re.findall(
            r"\$\s?\d+(?:\.\d+)?(?:/mo(?:nth)?)?|\d+\s?€|\d+\s?£",
            text, re.I
        )
        # De-duplicate, keep most common
        return list(dict.fromkeys(matches))[:10]
    except Exception as e:
        return {"error": str(e)}

No vector database. No caching layer. No model fine-tuning. Just requests, BeautifulSoup, and a regex. It's 30 lines of code.

I wrapped that in a simple Flask endpoint, made a bare-bones frontend, and deployed it to a free tier on a cloud provider. Total cost: my Sunday.

That little tool has been used over 1,200 times since. Not because the code is beautiful, but because it solved a real, boring problem — and I got it in front of people fast.

Rule 2: Call the API, don't host the model

My second MVP was a "resume tailor" — you upload a resume and a job description, get a rewritten version back. The obvious move here would be to fine-tune on resume data. I know a thing or two about transformers, so it was tempting to go down that rabbit hole.

I didn't. I called an existing model API and wrote better prompts instead.

The hardest lesson I've had to re-learn in the age of AI is this: your model is not a differentiator. The workflow around the model is. The UX, the prompt engineering, the iteration speed — those matter.

For the resume tool, my entire "AI layer" is this:

// Resume tailoring endpoint — the prompt does the heavy lifting
const result = await openai.chat.completions.create({
  model: "gpt-4o-mini", // cheap, fast, good enough
  messages: [
    {
      role: "system",
      content: `You are an expert career coach. Rewrite the candidate's
      resume bullet points to match the target job description.
      Rules:
      - Preserve all factual claims. Never invent experience.
      - Use the exact keywords from the job description.
      - Keep bullet points under 140 characters.
      - Output as JSON array of strings.`
    },
    {
      role: "user",
      content: `JOB: ${jobDescription}\n\nRESUME:\n${resumeText}`
    }
  ],
  temperature: 0.3,
});

That's it. Two messages, one system prompt with explicit constraints, and a JSON output requirement. No fine-tuning, no embeddings, no semantic caching.

The prompt discipline matters more than any architecture choice: I gave the model rules (preserve facts, use keywords, limit length) instead of relying on its judgment. That single prompt has processed 900+ resumes with a 4.6/5 user rating, which is honestly way better than I expected.

Rule 3: Ship to one person, not to "the market"

My third MVP came from a direct ask. A friend who runs a newsletter mentioned she spent an hour every Sunday rewriting the previous week's stories into a summary. I built her a tool that takes the raw article list and produces a draft in a consistent style.

For the first week, I was the support team, the QA department, and the product manager for exactly one user. Every Sunday, I'd get her feedback and tweak something. The tone settings. The length limits. The output format.

After two weeks of that daily-close feedback loop, the tool was in decent shape. Only then did I share it more broadly. A couple of small subreddits she participates in, her community, a mention in her newsletter.

That third project now has one paying customer (my friend) and about 30 free users. It's not a business. It was never supposed to be. But it's a real product with real usage patterns.

What I'd do differently (and what I'll keep)

If I'm honest, there are things I'd change retroactively:

• I should have put analytics in from day one. Not for vanity metrics, but to see where users stopped and interacted. I added them after launch to the second and third projects, and the insight was immediate: people were dropping off exactly at the "explaining methodology" paragraph in the output. Too much noise.
• I over-built the first project's backend. A simple SQLite file would have handled 100 users just fine. I used Postgres with an ORM. That didn't help anything. The second MVP used a JSON file for storage. Less code, fewer things to break.

Things I'll keep doing:

• The 72-hour deadline. It's non-negotiable now.
• Copying boring patterns: every MVP has a simple email-to-support address instead of a ticket system. When it grows, I'll switch.
• Talking to actual humans before coding. The price-extractor exists because of that Discord conversation. The resume tailor exists because I watched a friend spend 20 minutes deleting buzzwords from their CV manually.

On infrastructure: don't be a hero

A note on the technical side — one of the biggest traps in the AI side project world is the urge to self-host everything. Look, I get it. Running your own models is a cool flex. I've played with Ollama and local inference. It's fun. It's educational.

But for anything you want to ship, it's usually a bad idea. You're now managing GPU resources, model updates, and uptime — all of which have nothing to do with whether your users get value.

That's why I use hosted, pay-as-you-go APIs for inference. I want my cost to scale with actual usage, not with idle hours of a spinning GPU. And I want to focus my limited brain space on the product itself, not on keeping a service alive.

This is the pragmatic choice, and I'll die on this hill: call the API, write good prompts, iterate on the experience. That's the whole game.

For the resume tailor specifically, I initially tried hosting a small model on a rented GPU. It was cheaper per hour than the API, but the output quality was noticeably worse, and I spent time with monitoring instead of prompt iteration. I switched back within a week.

Incidentally, this is exactly the philosophy behind tai.shadie-oneapi.com — a unified API gateway I've settled on that lets me swap in different models behind a single endpoint without changing my application code. Pay as you go, no fixed upfront costs, and I can switch from one model to another based on what the task needs (cost per token, output quality, whatever). Honestly, it's saved me from the worst of the "lock-in" anxiety.

The real lesson

After three ships, here's what I actually believe:

AI side projects are not about the AI. They're about the side project part. The discipline of shipping, the humility of talking to users, the courage to release something imperfect and improve it in public.

The model is a tool. It's an incredibly powerful tool, but the value is in what you build around it: the problem you choose, the workflow you design, and the speed at which you iterate.

My next project is already in the 72-hour pipeline. This one's a simple chat interface for a set of internal documentation pages. Boring. Necessary. And I know exactly who's going to use it — because I already asked them what they were struggling with.

That's the whole secret. Ask. Build fast. Ship fast. Repeat.

If you've been sitting on an idea, I'll let you borrow my rule: the next 72 hours are all you get. It won't be perfect, but it'll exist. And existing beats perfect every single time.