Building an ML portfolio on $0: the free-tier stack, and where it breaks.
You do not need a budget to build a portfolio. You do need to know which free tier fails first, because designing around the wrong one wastes weeks.
The excuse
“I cannot afford the compute” is the most common reason people give for not having a portfolio, and it is almost never the real constraint. Between hosted inference, notebook GPUs, managed Postgres and a permanent free VM, you can build and run every project described in the roles-to-projects breakdown without paying anything.
What does cost you is picking the wrong tier for the workload and discovering the limit in week four. So this is organised by the limit, not by the marketing.
Every quota below moves, sometimes without an announcement. Treat these as the shape of each tier, then check the provider before you design around a number.
Inference.
Hosted APIs
Self-hosting a model is the most common early mistake. It burns your GPU allowance on serving rather than on the one thing you genuinely need a GPU for, and “I ran a 7B model on a T4” is not a hiring signal in 2026. Nobody is impressed that you can run inference; they want to know what you built on top of it.
Groq
A free API tier with unusually low latency, which makes it the right default for anything interactive: agents, chat surfaces, anything where a user is waiting. Breaks at: requests and tokens per minute. Fine for a demo and for your eval runs; not fine if you plan to batch a hundred thousand documents through it in one afternoon. Design your eval harness to checkpoint and resume.
Gemini API
A free tier covering both generation and embeddings, which matters more than it sounds: embedding a corpus is usually the first thing that would have cost you money. Breaks at: daily request caps, and free-tier usage generally being available for product improvement, so do not push anything sensitive through it. For a portfolio project on public data, that is a non-issue.
GPU.
Training only
Colab’s free tier gives you an NVIDIA T4 with 16 GB of VRAM. Sessions run up to roughly twelve hours, and the weekly GPU allowance is dynamic rather than published, observed by various trackers in the region of fifteen to thirty hours a week and lower during peak demand. Some days you will not get a GPU at all.
Breaks at: session death. This is the failure that costs people a week, and the fix is entirely in how you write the training loop.
- Checkpoint every epoch to Drive or object storage, and make resume the default path, not an emergency one.
- Never keep your dataset only in the session filesystem. It goes away with the runtime.
- Log metrics to something external (Weights and Biases has a free personal tier), or a disconnect takes your results with it.
- Fit within 16 GB by design: LoRA or QLoRA rather than full fine-tuning, gradient accumulation rather than a large batch, mixed precision on by default.
With those four in place, a T4 is enough for every fine-tune a portfolio project realistically needs.
Database.
Supabase
Managed Postgres with auth, plus pgvector, on a free tier. The vector support is the reason it beats a bare Postgres container for AI work: your embeddings and your relational data live in one place, and you get to write the join.
Breaks at: two things. A modest storage ceiling, which is generous for text and immediately tight if you store raw files (put those in object storage and keep only the reference). And inactivity: free projects pause after about a week without traffic. A recruiter opening your demo two weeks after you sent the link finds a dead app, which is worse than not having sent it. Either keep a small scheduled ping against it, or state on the case-study page that the demo takes a moment to wake.
The server.
Oracle, with a caveat
Oracle’s Always Free tier is the only mainstream option that gives you a genuinely permanent ARM VM rather than a trial credit, which makes it the natural home for anything that has to stay up: a scheduled pipeline, a webhook receiver, a demo API.
In June 2026 Oracle halved the Always Free Ampere A1 allowance from 4 OCPUs and 24 GB to 2 OCPUs and 12 GB, with no announcement. Plenty of guides still quote the old figures.
Two cores and 12 GB is still a real server and still more than most portfolio projects need, but if you planned a workload around 24 GB you should replan now rather than at deploy time.
Also breaks at: capacity. A1 instances are frequently unavailable in the busiest regions, sometimes for days. Pick a quieter home region when you create the tenancy, because changing it later is painful.
The rest.
Often forgotten
- CI GitHub Actions is free for public repos. This is the cheapest credibility on the list, and the one most often skipped.
- Frontend hosting A hobby tier is enough for a demo and a case-study page. This site runs on one.
- Object storage For datasets and checkpoints, so nothing important lives inside a Colab session.
- Experiment tracking A free personal tier is plenty, and having runs you can link to is itself an artefact.
The ceiling.
What $0 cannot do
Being straight about the limit, because designing past it wastes months:
- Pre-training anything. Fine-tuning yes, pre-training no.
- Serving real traffic. Free tiers are for a demo a handful of people open, not for users.
- Genuinely large-scale data work. You can demonstrate a pipeline that would scale, on a sampled dataset, with the scaling argument written down. That is the honest version and it interviews well.
- Anything with a real uptime requirement.
None of those are needed to prove competence. What is needed is a system that runs, a measurement that shows it works, and a write-up that survives questioning. That fits inside $0 comfortably.
If the project you build this way ends up in a private repo, the artefacts that keep it credible are a separate problem worth solving early.
The long version.
Playbook