10 min

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.

LAYERFREE TIERBREAKS ATInferenceGroq · Geminirequests + tokens per minuteGPUColab · T4, 16GBsession death, ~15-30 GPU hrs/weekDatabaseSupabase · pgvectorstorage, and pausing when idleAlways-onOracle · 2 OCPU / 12GBhalved June 2026, plus capacity
The whole stack, and the wall each layer runs into first. Every quota here moves, sometimes silently: treat it as the shape of the tier, then check the provider.

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

The playbook's stack guide goes tier by tier with the current limits and the workaround for each one, and every one of its sixteen project specs is scoped to run inside them.

Also here.

  1. 9 min

    The AI engineer portfolio projects that actually get you hired

    Two projects you can defend for ten minutes beat eight you can only describe. Here is what separates a portfolio that gets a callback from one that gets skimmed.

  2. 11 min

    RAG with an eval harness: the questions interviewers actually ask

    RAG is the most common project on AI engineering resumes and the one candidates are least able to defend. The gap is always evaluation.

  3. 8 min

    How to make a private repo credible to a recruiter who cannot see the code

    Work you cannot show is not the same as work you cannot prove. The trick is to move the evidence out of the source and into artefacts a reader can check.