From Zero to Job Offer with AI Projects: A Complete Playbook from a Former Amazon Engineer

Almost everyone breaking into AI gets the same advice: "build projects." But the real challenge is the massive gap between following a tutorial (where someone else has already made every decision for you) and building something genuinely from scratch.

A YouTuber who built production-grade AI/ML systems at Amazon and other companies shared the complete workflow he actually uses — from figuring out what's worth building, to testing and deployment, to leveraging a shipped product to unlock job opportunities. This methodology is invaluable for anyone trying to break into AI through a portfolio.

Start With Clarity: Why Are You Building This?

Before writing a single line of code, you need to be clear about what the project is actually meant to accomplish. A project can do three very different things:

• Learn skills: Maybe you just want to learn how to call a vision model.
• Prove capability to employers: The bar here is noticeably higher — you need to build a more robust system and demonstrate that you exercised good judgment throughout, rather than letting Claude "vibe-code" everything for you.
• Gain real experience: If actual people use it, it can go in the work experience section of your résumé — or even become a monetizable product.

The author emphasizes that the best portfolio projects aren't necessarily the most technically impressive ones — they're the ones you have a personal connection to. That connection keeps you motivated throughout, and that passion comes through naturally in interviews. He cites near-unanimous agreement from every hiring manager he interviewed for his ML career book: they care deeply about passion and decision-making ability, and those qualities only show when the idea genuinely came from you.

Start From the Problem, Not the Technology

Many people get stuck on "I don't know what to build" — either their ideas feel too simple to be impressive, or too ambitious to even start. The root cause, the author argues, is that people tend to start from the technology they want to use — they learn RAG, Agents, or some new model, then go hunting for problems to apply it to.

The right direction is the opposite: start from a problem you genuinely understand, then work backwards to figure out what technology actually makes sense. Your own life is the best starting point, because you already know what frustrates you and what a good solution would look like.

His example is an app he rebuilt called "Shelf Scanner": walking into a bookstore and feeling lost in front of shelves full of unfamiliar books, he wanted to snap a photo of the shelves, tell the system his reading preferences, and get a recommendation on what to buy. He's explicit: don't copy this app — the goal is to learn the framework, not to walk away with a ready-made project.

Turn a Fuzzy Idea Into a Decidable Scope Document

Before opening any coding assistant, the author converts a vague idea like "an app that recommends books from a photo" into a problem statement concrete enough to make decisions from. The critical point: the human makes the decisions, not Claude.

He uses a template refined over his entire career, covering product requirements, data, models, evaluation, infrastructure, security, deployment, monitoring — everything a production AI system touches. But at this stage, he only fills in the initial scoping section, intentionally leaving most of it blank because there's no evidence yet that those sections are needed.

One critical question that too many people skip: Does this project actually need AI? If regular software could solve the problem just as well, adding a language model only brings extra cost, unpredictability, and security risk.

An MVP Answers Your Biggest Question, Not a Rough Full Version

The author has a sharp take on MVPs: it's not "build a rough version of the complete app" — it's the smallest thing that answers your biggest current uncertainty about whether the project is feasible.

Shelf Scanner had two potentially fatal unknowns:

1. Can a cheap vision model accurately read book titles from a typical shelf photo? (Spines might be angled, tiny, partially blocked, or poorly lit.)
2. Can a reasonably priced language model give good recommendations given the books found and very minimal preference data?

So the first MVP was just a command-line script: feed it a photo, one model reads the titles, another model combines that with preferences and makes recommendations. That's it.

Evaluate Like an Experiment, Not a Gut Check

The author insists on running real experiments rather than eyeballing results. He logs every model call — the model used, the prompt, the response, cost, and latency — and sets up a logging schema in Supabase.

He evaluates the shelf reading and book recommendation stages separately, because a model that's great at reading small text in images isn't necessarily great at recommending books. He uses OpenRouter to call multiple providers through a single interface, and runs a small-scale comparison across five shelf photos. Key findings:

• Claude Sonnet and Gemini Flash read nearly all legible titles without hallucinating; smaller models missed more and hallucinated more.
• Cost mattered less than expected — the well-performing models all fit within budget.
• Latency was the real problem: some calls took 10–20 seconds just to read a shelf, while the target for the overall experience was around 15 seconds.
• In the recommendation phase, the cheaper GPT model actually aligned better with his own preferences than the more expensive model.
• He also discovered a privacy issue: source images contained GPS metadata in their EXIF data — something he didn't want to store.

This MVP taught him: this is a real problem solvable with existing models at reasonable cost and latency; the recognition and recommendation stages should be decoupled; and he picked up lessons about prompt design, parameter tuning, and privacy considerations.

OpenRouter is an API aggregation platform that lets developers call models from OpenAI, Anthropic, Google, Meta, and dozens of other providers through a single unified interface — no need to manage separate API keys or adapt to different calling conventions. For evaluation scenarios that require side-by-side model comparisons, this dramatically reduces switching overhead. Supabase is an open-source backend-as-a-service platform built on PostgreSQL, offering a database, authentication, real-time subscriptions, and storage — allowing developers to stand up a data layer without running their own servers. Using it to log model calls in an AI project gives you the flexibility of structured queries with the convenience of managed deployment, which is exactly why the author chose it over simply writing to local files.

Resist the Urge to Stack Technologies

With the MVP learnings in hand, the author revisited the scope document and explicitly decided what technologies not to use:

• No RAG: The books come from the current shelf. Any supplementary information can be fetched via a standard catalog lookup. There's no retrieval problem to solve.
• No Agents: The workflow is fixed (read shelf → look up → recommend). There's nothing for a model to decide dynamically — adding Agents would only make things slower, more expensive, and less predictable.
• No fine-tuning: Off-the-shelf models work well enough.

He calls out a common trap: to make an AI project look more impressive, many people cram in every technique they've learned. But you don't get credit for stacking technologies. If the problem doesn't require it, leaving it out is the better decision. Similarly, features like login, accounts, and purchase links were all cut from V1 to stay focused.

RAG (Retrieval-Augmented Generation) is an architecture that has the language model retrieve relevant content from an external knowledge base before generating a response — useful when you need access to large volumes of private documents or real-time information. Agents let the model autonomously decide which tools to call and in what order to complete multi-step tasks — suitable when the workflow itself is uncertain and requires dynamic planning. Fine-tuning involves further training a pre-trained model on domain-specific data to shift its output style or specialized capability. Each technique addresses a specific type of problem: RAG handles knowledge boundary problems, Agents handle workflow uncertainty, and fine-tuning handles style or domain adaptation. When a project has a fixed workflow, limited knowledge requirements, and a general-purpose model that already performs well enough, introducing any of these adds system complexity without delivering real value.

Phased Builds + Dual Quality Checks

The author breaks the project into phases where, at the end of each phase, the system still runs end-to-end — it just has one new capability. He sets rough deadlines to prevent scope creep. Every change has a spec and a task list; every commit is tied to a specific task, making it easy to track progress, review decisions, and roll back.

On correctness, he distinguishes two kinds:

• Conventional software correctness: Code that strips GPS metadata from photos is deterministic — you can write standard unit tests for it.
• AI behavior correctness: After you tweak a prompt, the vision model might miss half the book titles. A normal test won't catch that. This requires an evaluation set.

He uses GitHub Actions for CI/CD — tests run automatically on every push or pull request. He also maintains a separate evaluation set for AI behavior. To improve robustness, he deliberately creates degraded versions of the original photos: blurry, glare-heavy, rotated, low-resolution — and adds more shelf photos to cover a wider range of real-world conditions. Whenever a change might affect model behavior, he reruns the evaluation and compares against the last known-good version.

All of this depends on prompt versioning — one of the most important steps that beginners overlook. The insidious thing about AI systems is that the code can be entirely valid while behavior quietly degrades. Nothing crashes. Results just get worse.

CI/CD (Continuous Integration/Continuous Deployment) is a software engineering practice where every code change automatically triggers a series of tests and build steps, followed by automatic deployment to production once those pass. GitHub Actions is GitHub's built-in automation tool that executes predefined scripts when events like code pushes or Pull Requests occur. For AI projects, CI/CD matters especially because changes to prompts or model configurations don't cause programs to "crash" — they can silently degrade output quality. Without automated test gates, that kind of regression is extremely hard to catch in time. Prompt versioning (treating prompts like code, tracking every change in version control) paired with an evaluation set is what creates a traceable quality assurance loop.

Post-Launch Monitoring and Learning From Real Users

Production surfaces different problems: people upload strange photos, providers slow down, rate limits get hit. The author doesn't need enterprise-grade observability — just enough information to answer "what changed, and do I care?"

Fortunately, the decision made early on to log every model call now pays off, telling him which model handled the request, how long it took, what it cost, which prompt version was used, and whether it failed. He built a simple dashboard from that data. Going further, he uses failure cases to continuously improve the system, and collects simple feedback signals in the product (like users saving a recommendation or marking one as "not for me").

He gives an interview-framing example: if asked "why did you add caching?" he doesn't want to say "production apps have caching" — he wants to point to observed latency spikes and a data-driven prioritization call.

For deployment, he uses Vercel — connect the GitHub repo, click a few buttons, and every subsequent change deploys automatically after passing pre-deployment checks.

Making the Project Actually Help Your Job Search

When you look at just the app, you can't see all the work behind it. That's why the author emphasizes that presentation matters just as much. He spent time rewriting the README to explain what he built, the tradeoffs he made, and even added an architecture diagram.

More critically, he focused on getting real users. Even a few dozen people using your app will teach you an enormous amount and give you compelling stories to tell in interviews. And if you reach hundreds or thousands of users, you're starting to approach professional-level experience — the author's view is that if you've built a product with real users or even paying customers, it belongs in the work experience section of your résumé, not the projects section.

This is exactly how you break the "you need experience to get experience" deadlock: build a real product, and you create the opportunity for yourself. His final reminder: don't copy Shelf Scanner. Copy the process.