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

I’ve lost count of how many times I’ve started an AI project with a burst of excitement, only to abandon it two weekends later. The pattern was always the same: a brilliant idea, a deep dive into fine-tuning a model, a week of wrestling with CUDA drivers, and then—silence. The repo goes cold, the README stays half-written, and I’m back to scrolling Twitter.

But something shifted for me over the last two months. I shipped three AI MVPs, got real users on two of them, and actually learned what it takes to cross the finish line. It wasn’t about smarter engineering or better prompts. It was about brutally cutting scope and embracing the unglamorous parts of building.

Here’s what that journey looked like, warts and all.

The Wake-Up Call: My First "AI" Project Was a Disaster

Let me rewind to January. I had this idea for an AI-powered meeting summarizer that would integrate with Slack. The vision was grand: it would identify action items, assign owners, and even draft follow-up emails. I spent three weeks building a custom pipeline using LangChain, vector embeddings, and a local fine-tuned model because I thought that was the "real" way to do it.

The result? It worked—sort of. The summaries were 60% accurate, the latency was terrible (15 seconds per call), and I spent more time debugging the infrastructure than actually using the tool. I showed it to two friends, both nodded politely, and then never opened it again.

I had fallen into the classic trap: I was building an AI system, not a product. The user didn't care about my custom tokenizer. They cared about not having to read a 45-minute meeting transcript.

The Pivot: Shipping Small and Dumb

After that failure, I set a new rule for myself: The MVP must be buildable in a single weekend. No exceptions. If I can't demo it by Sunday night, I'm not building it.

This forced me to think differently. Instead of asking "What can I build with AI?", I started asking "What's the smallest annoying problem I can solve with one API call?"

MVP #1: The Resume Screener (Weekend 1)

A friend of mine was drowning in resumes for a junior developer role. She had 200 applications and no time. My idea was dead simple: a web app where she pastes the job description, uploads PDFs, and gets a ranked list based on keyword and semantic similarity.

Here's the core logic—it's embarrassingly simple:

from openai import OpenAI
import pandas as pd

client = OpenAI()

def rank_resumes(job_description, resumes):
    scores = []
    for res in resumes:
        response = client.embeddings.create(
            model="text-embedding-3-small",
            input=[job_description, res],
        )
        emb1, emb2 = response.data[0].embedding, response.data[1].embedding
        similarity = sum(a*b for a, b in zip(emb1, emb2))
        scores.append(similarity)
    return scores

That's it. No vector database, no LangChain, no fine-tuning. Just cosine similarity on embeddings. It took me four hours to build the backend and three hours to throw together a basic HTML form. Total time: 7 hours.

She used it to shortlist 20 candidates in an afternoon. It wasn't perfect, but it saved her a day of work. I didn't monetize it, but I learned something crucial: the "dumb" solution is often the best one.

MVP #2: The Changelog Generator (Weekend 3)

After the first success, I wanted to push a bit further. I was working on a small SaaS product and hated writing changelog entries. So I built a tool that takes a GitHub diff and generates a human-readable summary.

The trick was to stop thinking about "understanding the code" and instead just feed the diff text into a prompt. The key was in the system message:

You are a technical writer. Given the following git diff, write a concise changelog entry for a non-technical audience. Focus on user-visible changes. Ignore formatting and refactoring. Use bullet points.

I used the gpt-4o-mini model for this because it's cheap and fast. The whole thing runs in a single Python script that I wrapped in a Flask app. The hardest part wasn't the AI—it was parsing the git diff output into a clean string.

This one took me about 6 hours across two evenings. A few friends started using it, and one even said it saved them from writing boring release notes for their client work.

The Reality Check: What Actually Mattered

Here's the thing that surprised me. In all three projects, the AI part was maybe 20% of the work. The other 80% was:

• Handling edge cases: What if the PDF is scanned? What if the diff is 10,000 lines?
• Making it fast: No one cares about a smart AI if it takes 30 seconds to respond.
• Simple UI: I used plain HTML and a tiny bit of CSS. Nobody complimented my frontend skills, but they didn't complain either.

The biggest lesson? Prompt engineering is more important than model choice. I spent hours comparing gpt-4 vs claude-3 vs llama-3 on benchmarks. In the end, the winning factor was always how I structured the prompt, not which model I used. For 95% of use cases, a cheap model with a great prompt beats an expensive model with a lazy prompt.

The Infrastructure Trap I Almost Fell Into

On MVP #3—a content repurposing tool that turns blog posts into Twitter threads—I hit a wall. The API costs were creeping up, and I thought, "I should just self-host a small model to cut costs."

I spent an entire weekend trying to get a quantized model running on a rented GPU. I installed Docker, fiddled with vLLM, battled with CUDA version mismatches. I even got it working—once. Then the GPU instance rebooted and I lost all my environment setup. I rage-quit and went back to the API.

That weekend taught me a valuable lesson about opportunity cost. I could have spent that time marketing the product or improving the prompt. Instead, I was fighting infrastructure battles that had nothing to do with my users' problems.

The Numbers That Keep Me Honest

Here are the raw numbers from my two-month experiment:

• Projects started: 5
• Projects shipped: 3
• Projects with external users: 2
• Total API spend: $47.32
• Time invested per project: 6-10 hours
• Lines of code per project: 200-400

The most successful project wasn't the one with the most complex AI. It was the one that solved a specific, painful problem for a specific person. The resume screener got 3 users in a week. The changelog generator got 15 users because I posted it on a niche Slack group.

What I'd Tell My Past Self

If I could go back to January, I'd tell myself:

1. Start with the API, not the model. Don't even think about self-hosting until you have paying users. And even then, question it.
2. Time-box the AI part. If you can't get the core AI feature working in 2 hours, you're overcomplicating it.
3. The prompt is the product. Spend 30 minutes crafting your system prompt before you even write a line of code.
4. Show it to one person early. The resume screener was built for my friend, not for "the market." That clarity changed everything.

The Practical Side: What I Use Now

Since that GPU nightmare, I've been a firm believer in using managed, pay-as-you-go APIs. I don't want to think about provisioning, scaling, or keeping models warm. I want to spend my weekends building features, not debugging nvidia-smi.

These days, I default to using a single aggregation endpoint that gives me access to multiple models without the overhead of managing separate API keys and billing. It's been a lifesaver for rapid prototyping. When I want to test if a cheaper model works for a task, I can just swap it in with a config change instead of rewriting code.

I've been using tai.shadie-oneapi.com for this. It's not the flashiest tool, but it does exactly what I need: one API key, multiple models, and no surprise bills. For someone who ships MVPs on a weekend, that's worth more than any fancy feature.

The bottom line is this: AI projects don't fail because the AI isn't good enough. They fail because we get lost in the technology and forget we're building a tool for humans. Ship something small, get it in front of someone, and iterate. The rest is just noise.