A repeatable, product-minded process for turning a blank repo into a real AI application — used building production AI/ML systems at Amazon, and demonstrated end-to-end by rebuilding the "ShelfScanner" bookshelf-recommendation app.
Click any step to expand the reasoning behind it.
A project can teach a skill, demonstrate skills to employers, or — if real people use it — become experience or a product. These are different goals with different bars.
A learning project can be simple. The same project on a résumé needs robustness and visible good judgment — especially proof that the AI didn't just "vibe code some slop."
Most people start with tech (RAG, agents, a new model) then hunt for a problem. Do the opposite: start with a problem you understand and work backwards to the technology.
Source problems from your own life, people around you, or a community (Reddit/Discord). Personal connection keeps you motivated and shows the enthusiasm and decision-making hiring managers actually look for.
Turn a vague idea into a decision-ready problem: who it's for, constraints, input/output data, success metrics, latency, budget. A template captures this — most stays blank on purpose.
The question people skip: does AI even make sense here? If normal software solves it just as well, a model adds cost and unpredictability and makes you look inexperienced.
Use coding assistants properly. The point of a portfolio project is to learn and demonstrate learning — outsourcing decisions to Claude means you can't defend them in an interview.
You will work with data, so you need somewhere to store it. The example uses Supabase (Postgres + file storage, generous free tier) matching scoping needs.
.envAn MVP is not a crappy version of the whole app. It's the smallest thing that answers the project's biggest unknowns — here, whether vision can read book spines and whether an LLM can produce useful recommendations.
ShelfScanner's first MVP was a command-line script: photo in → titles read → five recommendations out. That's it.
Don't go by vibes. Log every model call: which model, which prompt, what it returned, latency, rough cost, and whether it failed.
Keep shelf-reading and recommendation stages separate — the best OCR model isn't necessarily the best recommender, and separating them lets you compare each problem cleanly and swap models later.
Begin with ~5 photos you already have. That can't prove the system works — it only answers "is this promising enough to continue?"
Write labels against a consistent rubric. Rules needn't be perfect, but they must be applied the same way, or grading becomes random and useless.
No points for cramming every technique into one repo. For ShelfScanner the author deliberately dropped:
Break work into phases that each leave something working end-to-end. Order matters more than the exact phases: tackle risky parts early enough that they can still change the design.
ShelfScanner: Phase 1 model router + automated quality check → Phase 2 smallest useful app (photo → titles) → Phase 3 preferences → …
Rough deadlines guard against scope creep. The rebuild: ~100 commits, ~10–15 hrs/week over 8 weeks — less than half spent actually coding, the rest studying.
Vercel + GitHub gives near-click deployment with auto-deploys on change; a custom domain (shelfscanner.io) made it feel real.
The engineering is invisible from the outside, so a well-written README (trade-offs, functionality, architecture diagrams) is essential. Then get real users — even a few dozen teach you a lot and give interview stories. At scale, a real product can move from the "Projects" section to "Experience."
| Change type | Deterministic code | Model / prompt behavior |
|---|---|---|
| GPS strip from photos | Unit / normal test | Not relevant |
| Prompt tweak (vision) | Not relevant | Eval set needed |
| Config change | Some coverage | Eval flagged a failure |
| Saved books ownership | Unit / normal test | Not relevant |
Don't copy ShelfScanner. Copy the process.
The project is a framework, not a template — the value comes from making your own decisions.
Product requirements, data, models, evaluation, infrastructure, security, deployment, monitoring and more — but most of it stays blank at the start. Early on you fill only what helps you understand the problem: user, constraints, input/output data, and success metrics. The rest gets filled in as evidence arrives from the MVP.
There's no reason the model best at reading tiny text in an image is also the best at recommending books. Separating reading from recommending lets you compare each problem independently rather than treating a provider as one big package — and makes it clean to swap one model without touching the rest.
Not every project needs all of these — they're a menu, not a checklist.
Plus an assistant review of the change against the spec — another set of eyes. Most of this becomes boring once automated, which is the point.
The finished ShelfScanner is a web app, not a native mobile app, and "not perfect." To hit the deadline the author still used AI more than a pure learning project would justify. The point was to demonstrate the process, with plenty left to optimize later.