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

Most AI side projects die before seeing a single user. I know because I’ve killed dozens myself. But over the last two months, I shipped three. Not abandoned. Not “almost done.” Shipped. Each had real users (even if only a handful), each taught me something different, and each forced me to confront the gap between the romantic idea of building with AI and the messy reality.

Here’s what I learned — and how you can avoid the same traps.

The Trap: Building the Model Instead of the Product

My first real attempt was a chatbot for developer documentation. I had this grand vision: fine‑tune a LLaMA model on my company’s internal docs, run it on my own hardware, keep everything private. Two weeks in I was still wrestling with CUDA versions and disk space. The chatbot didn't exist. The model wasn't even loaded. I had built nothing.

I killed it.

For the next project I did the opposite: I grabbed an API key and wrote a 50‑line Python script. That script became a tool that summarises pull requests. It shipped in two days.

Lesson: For an MVP, don’t host the model. Use an API. You can always optimise later. The goal is to get something in front of a user, not to flex your MLOps skills.

Here’s essentially the core of that first PR summariser:

import os
import requests
from github import Github

g = Github(os.environ["GITHUB_TOKEN"])
repo = g.get_repo("yourname/yourrepo")

for pr in repo.get_pulls(state="open"):
    diff = pr.get_files()
    # Build a prompt from the diff
    prompt = f"Summarise this PR in 3 bullet points:\n\n"
    for file in diff:
        prompt += f"File: {file.filename}\n{file.patch[:500]}\n"

    response = requests.post(
        "https://api.openai.com/v1/chat/completions",
        headers={"Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}"},
        json={
            "model": "gpt-4o-mini",
            "messages": [{"role": "user", "content": prompt}],
        },
    )
    summary = response.json()["choices"][0]["message"]["content"]
    pr.create_issue_comment(f"**AI Summary:**\n{summary}")

That’s it. No vector database, no RAG pipeline, no self‑hosted inference server. It cost about $0.02 per PR. I ran it as a cron job and forgot about it.

Scope Ruthlessly — Then Scope Again

My second project was a personalised learning assistant. Originally it was supposed to: generate quizzes, track progress, suggest resources, send reminders, integrate with Notion, and have a React frontend with auth.

I shipped a minimal version that only answered questions about a textbook PDF. No auth. No reminders. Just a plain HTML form that called an API. That version took me four evenings. The “full” version never existed.

Why? Because once I put the simple thing in front of people, they told me what they actually needed. Most of my grand features were imaginary.

Numbers: After launch I had 14 users. Only 3 used the quiz feature I had planned. But 11 asked for “save my conversation history.” So I added a simple JSON file store in two hours. That’s what shipping looks like: you respond to real signals, not your own assumptions.

Ship Before You’re Ready

The third project was a tool that generates alt‑text for images using AI. I built it in one weekend. The UI is ugly. Error handling is minimal. There’s no loading spinner – it just hangs until the API returns. But it works.

I set a hard deadline: two weeks from idea to first deploy. If it’s not out by then, I scrap it. That timer forces brutal prioritisation. No refactoring. No premature optimisation. Just the shortest path to “someone can press a button and get a result.”

The alt‑text tool ended up serving about 200 requests in its first week. That’s 200 images that got descriptions they otherwise wouldn’t have. If I had waited to polish the dark mode toggle, none of those descriptions would exist.

Infrastructure Choice: Stop Self‑Hosting, Start Pay‑as‑You‑Go

Every project I killed before these three died because I tried to run the models myself. Even when it’s “easy” with ollama or vLLM, you still have to manage a server, deal with memory constraints, and handle scaling when (if) you get traffic. For a side project that isn’t earning money yet, that overhead is deadly.

I now use API aggregators almost exclusively. They give me access to multiple models without provisioning anything. I can swap from GPT‑4o to Claude to a smaller model with one line of code. Billing is pay‑as‑you‑go, which means I pay cents per request instead of a flat GPU rental.

By the way, the one I’ve been using lately is tai.shadie‑oneapi.com. It’s not a sponsorship – I just genuinely needed something that worked out of the box, didn’t lock me into one provider, and let me experiment without a monthly commitment. It’s been reliable for my tiny traffic and the pricing is sane. If you’re building an AI side project today, I’d recommend starting with an aggregator like that rather than hosting your own stack. You can always migrate later when you actually have users and revenue.

What I’d Do Differently (and Same)

If I started over:

• Same: Use an API from day one.
• Same: Ship a single feature, not a platform.
• Different: Add rudimentary analytics from the start. I had no idea how people used my tools until I manually asked them.
• Different: Charge something, even $1. It changes how seriously you take the project and filters out tire‑kickers.

The Real Takeaway

Shipping an AI side project is not about the AI. It’s about finishing. The hardest part isn’t the model – it’s deciding what not to build and then actually pressing deploy.

I shipped three MVPs in two months. None of them are unicorns. One has maybe 50 users. But each one taught me more about building than any course ever could. And each one exists in the world, not in a “coming soon” folder.

Your turn. Pick an idea so small it’s embarrassing. Use an API. Give yourself two weeks. Ship it.

You’ll learn more from that one ugly, working thing than from a year of planning the perfect architecture.

Comments

[Luis Cruz]

I really appreciate the emphasis on using APIs for MVPs, as seen in the PR summariser example, where leveraging the OpenAI API allowed for a quick and cost-effective solution, with a cost of only $0.02 per PR. This approach highlights the importance of prioritising getting a working product in front of users over perfecting the underlying infrastructure. The fact that the API-based approach allowed for a simple and efficient solution to be deployed in just two days is a great illustration of the benefits of this approach. By using APIs, developers can focus on building the product rather than getting bogged down in MLOps details, and then optimise later if needed. What are some other examples of APIs that can be used to simplify the development process for AI-powered MVPs?