The advice on portfolio projects for self-taught developers has been the same for years. Build a todo app. Build a weather dashboard. Build a clone of an existing service. By 2026 this advice produces portfolios that look exactly like every other self-taught developer’s portfolio, which is to say, mostly indistinguishable.

The portfolios that actually land interviews in 2026 look different. They’re smaller in number of projects, higher in quality per project, and oriented toward what recruiters and hiring engineers actually look at when evaluating candidates.

This is what I’ve seen work and not work, drawn from feedback to my own writing about self-taught development and from conversations with the developers who’ve come through the path successfully.

The shift in what hiring engineers look at

The hiring landscape has shifted in two specific ways since AI coding tools became widespread.

The bar for “can you code at all” has gotten lower in the sense that many people can produce working code with AI assistance, regardless of whether they could without. The portfolio project that was impressive in 2022 — “I built a working CRUD app” — is no longer evidence of much because anyone can build a working CRUD app.

The bar for “can you actually engineer” has gotten higher. Hiring engineers want to see evidence that the candidate understands what they built, made deliberate decisions, and can defend those decisions. The portfolio that’s clearly a wrapper around AI-generated code with no understanding behind it is a negative signal, not a positive one.

This shift changes what works in a portfolio. Quantity and surface impressiveness matter less. Depth of understanding and quality of reasoning matter more.

What actually lands interviews

The portfolio elements that consistently work in 2026:

A small number of projects (2-4) that are genuinely complete, deployed, and functional rather than a long list of incomplete experiments.

Projects that solve a real problem, even if a small one, rather than tutorial-style demos.

Detailed README files that explain the decisions made in building the project — why this architecture, why this technology choice, what was hard and how it was solved.

Working deployments at real URLs that the reviewer can interact with, not just GitHub repos.

A demonstrable understanding of why the code looks the way it does, defensible in a follow-up conversation.

Some evidence of debugging and iteration — commit history that shows real development work, not a single perfect commit that drops the entire project.

Some indication of why the developer found this project interesting and what they learned from it.

What doesn’t land interviews

The portfolio elements that don’t work:

Long lists of small incomplete projects that look like coursework dumps.

Tutorial reproductions that the reviewer has seen ten times.

Projects with elaborate frontend showing-off but trivial backend, or vice versa.

Portfolios that obviously contain AI-generated code with no understanding — copy-paste obvious, generic comments, inconsistent style across files that shouldn’t be inconsistent.

Projects without working deployments, where the reviewer is asked to take the candidate’s word that the code works.

Portfolios without any explanation of why the projects exist or what was learned.

Projects that try to be impressive on dimensions the reviewer doesn’t care about (animations on the portfolio site itself, fancy UI on a learning project) instead of dimensions they do (correctness, architecture, code quality).

The project quality question

The single biggest factor in what works is project quality rather than project quantity.

A portfolio with two genuinely good projects beats a portfolio with eight tutorial reproductions. The reviewer is going to look at one or two projects in any depth. Making those one or two projects worth looking at is the priority.

What makes a project genuinely good for portfolio purposes:

The problem is real. Even a small real problem beats a contrived problem. A tool that solves the developer’s own actual annoyance is more interesting than a generic CRUD demo.

The implementation is thoughtful. The code is structured in a way that suggests the developer thought about it, not just got it working.

The deployment is operational. Not just running locally but actually deployed somewhere the reviewer can use.

The README explains the thinking. Why these technology choices, what was hard, what would be done differently in retrospect.

The history is real. Commits over time that show development happening, not a single dump of finished code.

Each of these elements is achievable through deliberate effort. The portfolio that has all of them on two or three projects is much stronger than the portfolio that has none of them across many projects.

The “real problem” question

The advice to solve a real problem confuses many self-taught developers. The interpretation that produces good portfolios is to look for problems the developer actually has, even if small.

Examples of small but real problems that have produced good portfolio projects:

A developer who runs a small Discord server built a bot to handle a specific moderation pattern that bothered them.

A developer who tracks their reading built a tool to organise the data the way they wanted to see it, rather than using existing book-tracking apps.

A developer who runs marathons built a training log with the metrics they cared about that the major running apps didn’t surface.

A developer who manages their own finances built a small visualisation tool for transaction patterns they couldn’t see in their bank’s app.

These are all small. They all have an obvious owner-user (the developer themselves). They all involve actual decisions that the developer can talk about because they made them for their own reasons.

The contrast is with projects like “I built a clone of Twitter” or “I built a clone of Instagram.” The latter type of project doesn’t have a real problem behind it. The technology choices are arbitrary because there’s no real user. The decisions can’t be defended because they weren’t really decisions.

The technology choice question

Self-taught developers often agonise over technology choices for portfolio projects. Should I use Next.js or Remix or Astro? Should I use Postgres or MongoDB or SQLite? Should I deploy to Vercel or AWS or Railway?

The reality is that the specific technology choices matter less than the reasoning behind them and the consistency with which they’re used. A portfolio project built well in any reasonable technology stack works for portfolio purposes. A portfolio project built poorly in the trendiest stack doesn’t.

The reasoning behind technology choices is what reviewers care about. “I chose Next.js because I needed server-side rendering for SEO and the static-plus-dynamic hybrid worked for my use case” is good reasoning. “I chose Next.js because it’s popular” is not.

The simpler the technology stack, the better in many cases. A portfolio project that’s understandable end to end on a simple stack is more convincing than a project on a complex stack where the developer can only explain part of it.

The deployment question

Working deployments matter substantially. The portfolio with two working deployed applications outperforms the portfolio with five GitHub repos that may or may not work.

The deployment doesn’t have to be elaborate. Vercel, Railway, Render, and similar platforms make deployment cheap and quick for typical web applications. The deployment is part of the portfolio investment, not separate from it.

For projects with serious infrastructure (databases, queues, authentication), getting the deployment right is part of demonstrating real engineering capability. The reviewer who clicks through and sees a working application that handles the full stack is meaningfully more impressed than the reviewer who sees a README claiming the application would work if deployed.

The AI tools question

The use of AI coding tools in portfolio projects is contested. The honest position in 2026 is that AI tools are normal and using them is fine, but the portfolio has to demonstrate that the developer understands what was built.

The way to handle this in a portfolio is to be transparent about the development process and to demonstrate understanding through documentation, commit messages, and the ability to defend decisions in conversation.

The portfolio that hides its use of AI and produces code the developer can’t explain is a negative signal. The portfolio that incorporates AI into a reasonable development process and produces code the developer understands is a normal signal.

The recruiters and hiring engineers I’ve talked to in 2026 are mostly comfortable with AI use in portfolio projects. They’re uncomfortable with developers who can’t explain what their code does. The distinction is what matters.

What to actually build

For a self-taught developer building a portfolio in 2026, the practical recommendation is to:

Pick two or three projects that solve real problems, even small ones, that you actually want to use yourself.

Build them properly with deliberate technology choices you can defend.

Deploy them somewhere the reviewer can interact with.

Write detailed READMEs that explain the thinking and the lessons.

Maintain a real commit history that shows the actual development work.

Be ready to talk through the projects in detail in interviews.

This is more work per project than the tutorial-cloning approach. The total work for a strong portfolio is comparable, just concentrated in fewer projects of higher quality.

The portfolios that come out of this approach are differentiated, defensible, and actually land interviews. The portfolios that follow the older “long list of small projects” advice produce a lot of work without the differentiation that converts to interviews.

The investment in fewer, better projects is the key lever. The advice to build a hundred small things is from an earlier era. The advice that works in 2026 is to build three things really well.