Let me guess: You've been learning React for a while already. Now it's time to build a portfolio of advanced React projects. And you're looking for inspiration.
The thing is you can't just build any project. Your portfolio has a purpose:
Your goal is to get a job.
Unfortunately, you'll hit one major roadblock on your journey: the Hiring Manager (capital letters).
They are the gatekeeper who makes the decisions. They invite you to an interview. Or toss your application in the trash. And believe me, they have piles of applications to trash for any entry-level job.
You need to convince the hiring manager that you're ready for the job.
And the best way to prove that is to act like a professional React developer.
Build your portfolio projects with the technologies, libraries, techniques, and workflows that are used in professional dev teams in the real world. The doors to your new career will be wide open.
Simple enough. Act like a professional dev...
But hold on. How should you know all this? You've never worked in a real company before, have you?
No worries. I got your back.
Unlike other articles, I don't just hand you a list of project ideas and call it a day. I want you to understand how you can tailor your projects to impress your future employer. Be it one of the ideas on this page or one of your own.
The idea of this guide is to imitate a real work environment. So you need an idea that resembles a real-world production app.
A Todo or Weather app clearly won't cut it. A social media app is a bit more complex, true. But really? Do you want to build another one of those?
Ideally, you want a portfolio that is different from other candidates'. Just different enough to make the reviewer care about you.
You want a project that has enough complexity to prove your skills. At the same time, it should be small enough to finish within a few weeks.
And finally, it would be awesome to have ready-made designs. This would allow you to imitate professional workflows. And you wouldn't have to waste a lot of time fiddling with the layout.
This list of React project ideas for your portfolio provides exactly that.
All of these projects are business use-cases as they are used in many tech companies:
A UI kit is a set of reusable components such as buttons, inputs, cards, modals, you name it.
I know it's doesn't sound super-sexy. But many companies create their own custom UI library. So this project is very close to the work of a professional frontend developer.
By building a UI kit you demonstrate that you understand modern & professional UI development.
And honestly, it may look easier than it is. From my experience, you can spend a good deal of time on getting the styles right for every dynamic state.
To appear more professional you can
Using Storybook will not only make you look like a pro. It will also improve your developer experience drastically. And as you can see on their homepage you'd be in good company with major players like Airbnb, Lyft, Auth0, or Salesforce.
Where you get it: You can find a great UI Kit here on Figma.
Time required: 1 week
Difficulty: medium
Features
What you'll learn
With Reddit Analytics users can find the best time to create a post on a subreddit. Subreddits are like niche forums that are highly popular among marketers to promote their content.
So this app can be used by marketing teams or individuals who want more people to see their blog posts.
In a nutshell, the user can enter the name of a subreddit. The app then fetches the corresponding data from the Reddit API and displays it in a heatmap.
If you're not familiar with professional workflows yet, this is the ideal starting point.
This project is already prepared for you here on Profy.dev. It includes designs in Figma and tasks in ClickUp. You'll learn and practice the workflows used by many professional teams around the world. Including working with feature branches and Pull Requests.
On top of that, you will get tips to improve your code via code reviews. You'll also be able to compare your code to a professional implementation.
The goal of this project is to not only practice your coding skills but experience what it means to be a professional developer. That will give you a great advantage for your job hunt.
Where you get it: You can find the whole project including designs & tasks here.
Time required: 2 - 4 weeks
Difficulty: advanced
Features
What you'll learn
Error tracking tools like Sentry (screenshot above) or Rollbar are used in every serious software product.
The basic functionality is to report expected and unexpected errors on websites. The user can see the numbers, times, and causes of these errors in a dashboard.
This is how it works in a nutshell:
As a portfolio project, this reduced feature set should be sufficient. Since it's an essential tool in the stack of any production app you'll not only prove your technical skills. You'll also demonstrate a good understanding of professional software development.
To make your life easier, focus on building the frontend and the JS library. You can quickly build the backend with services like AWS Amplify, Nhost, or Hasura.
Where you get it: Unfortunately, I don't have complete designs. But you can find a nice dashboard design here on Figma.
Time required: 3 - 6 weeks
Difficulty: hard
Features
What you'll learn
The idea sounds convincing: your future employer will be more likely to give you a shot if you build your portfolio projects like a pro.
You'll look ambitious. You'll prove that you're eager to learn and level up. Some of the most important traits of a Junior developer.
Unfortunately, this is a catch-22 situation: you don't know how to work like a pro until you've been part of a professional team.
Luckily, I've been on both sides. And I'd like to share my experience with you in this chapter.
We'll focus on the most important areas:
There's a huge difference between working alone and on a professional team. In a team, your co-workers depend on your work the same way you depend on theirs. That's why you need to work with much more structure and transparency.
But let's start with a story of a lone developer building a project. This is me at the beginning of my career in tech. Be careful, you might recognize yourself.
When I built my first projects I started with an idea. Let's say an Airbnb for pet owners (no joke, I really built this).
I thought about the features it should have. The user should be able to create and update their profile. And there should be a list view that shows all the available apartments. Ideally searchable.
Fair enough. Off I went into code-land. That's the fun part after all, right?
Soon another interesting feature would pop into my head. I'd lose focus and start working on it straight away. Leaving me with a bunch of half-baked code. Entangled as the infamous spaghetti.
The layout was another kind of problem. I'd obviously have a look at Airbnb and similar competitors to get design ideas. Then I'd start writing CSS.
I'd fiddle around with my styles. I would move elements pixel by pixel. I'd change some colors here and increase some text size there. Make it bold, make it italic.
Only to find out that it's actually harder than expected to make a website look good...
You see the problem? I'd make a plan, yeah. But only a very rough one and only in my head. I'd waste a lot of time with unnecessary features and fiddling around with CSS details. And the awesome web app that I had in mind looked more like... ehm...
So how does working on a professional dev team compare to that?
Professional frontend developers get two things before they start coding:
In a real-world job, it's not the developer's responsibility to come up with features or designs. Typically a product manager decides what has to be built. And a designer prepares the designs.
It's the dev's job to turn them into working code.
The good news is, you can work the same way as the pros. You start with designs. Then create the tasks. Only then you start to code.
First, the designs.
Of course, you don't want to hire a designer just to build a couple of portfolio projects. And as I said, you shouldn't create the designs yourself either. That's not your responsibility on the job.
So where to get designs from?
A good place to start is the Figma Community. You'll find many professional designs that you can simply clone into your free Figma account. You might find a ready-made app design that you like. If not, you can use one of the UI kits to build a custom design yourself. Simply drag & drop the elements into place.
Next, you create the tasks.
This is how it works in a nutshell.
Now you can start coding.
If you structure yourself this way you'll be much closer to a real job experience. Instead of randomly writing code for different parts of your app you'll start to think and work like a professional developer.
And that in turn is impressive for any employer.
If this sounds like too much work you can check out the Reddit Analytics app in the ideas chapter at the end of this guide. I've prepared this project for you including designs and tasks. But even if you put in the work yourself I'm sure it'll pay off in the long-term.
Now that you know how to prepare your project and work on it like a pro let's dive into more technical topics.
You might be tempted to use a UI library like Material UI or Bootstrap. And you're right, these are great libraries. They can be very valuable if you need to build an app quickly. For example, if you're working in an early-stage startup or building websites for clients as a freelancer.
But most development teams work differently.
Unique branding is super important for companies. That's why a designer prepares custom designs and styleguides. At least for the user-facing parts of the application.
And as we mentioned in the last chapter, it's the developer's job to turn those designs into code.
So to stay close to real production apps write custom CSS instead of using ready-made UI libraries. Writing CSS is a much more flexible skill that you will use in any job.
But UI libraries not only provide ready-made elements. They also simplify your life by taking the burden of responsiveness off your shoulders. Again, this might be good to get off the ground quickly.
But you want to prove that you can work as a React developer under realistic conditions. And being able to build responsive layouts with CSS is very important nowadays.
In most cases, it's not very hard to make your app responsive. Let's say you have designs for desktops only. Make sure to test your app on different screen sizes e.g. using the Chrome dev tools' responsive mode.
Apart from writing custom CSS and keeping responsiveness in mind I have one last advice regarding styles:
Don't use global classes.
I see global CSS classes quite often when reviewing Junior React developer's portfolio projects. It makes me question the knowledge of the candidate.
The problem is that global class names are not scalable. Once you have a larger application you'll run into naming conflicts. You'll have to use more specific names. Finally, you'll end up using a naming convention like BEM. That's so 2015!
Good news, this is really easy to fix. The simple solution is to use CSS Modules which works out of the box with Create React App, Next.js, or Gatsby. If you want to take it a step further have a look at one of the modern CSS-in-JS libraries like styled-components. You might need to tweak your app's setup slightly but there should be tutorials in most cases.
In case you want to see an example, here you go.
// don't use global classes like thisimport './index.css';const MyComponent = () => (// this will become class="box" in the HTML<div className="box" />)// but rather scoped classes with CSS Modulesimport styles from './Box.module.css';const MyComponent = () => (// this will become something like class="Box—box-3MbgH"<div className={styles.box} />)// or styled-components (even better imo)import styled from 'styled-components';const Box = styled.div`background: red;`const MyComponent = () => (// this will be similar to class="Box—box-3MbgH"<Box />)
Application logic (aka your JS code) is what makes the difference between a website and a web application.
If you plan to become a real software developer you need to prove that you can build more than a simple static website. That's one of the reasons I'd recommend not to waste a lot of time on a portfolio website (as do 60+ hiring managers in this survey).
Any real-world application touches three important areas: routing, state, and data. These are also the areas you should prove your skills in. As a bonus point, let me mention automated tests since they are super important in the daily life of many developers.
useState
, useReducer
, or useContext
should be sufficient.map
, filter
, or reduce
.As a software developer, you'll have to work with other developers eventually. And the one tool essential to collaboration among devs is Git.
So starting to use Git in a proper way can't hurt in any case. But it might also impact your chances of getting a job.
When I review a portfolio project to assess a candidate's skill level I tend to have a look at the commit history.
Imagine looking at a project's Git history and seeing commits like these:
This looks very unprofessional.
I'll admit, I have commits like these in my personal projects as well. We all get tired or commit too many changes at once to find a proper name.
But you want to impress potential employers with your portfolio project, right? So rather write concise yet descriptive commit messages.
Look at this. Now it's immediately clear what this commit is about. Even though it's not proper English 🙂
If you want to take a step further consider working on branches and using Pull Requests on GitHub to merge your branches.
This will signal that you have a grasp of professional development workflows. If you're interested in a professional Git workflow have a look at my free course.
In this part, we wanted to answer one question: How can you build your React portfolio projects like a pro? The goal is to impress your future employer and convince them that you can be a valuable member of their team.
Here a short overview of the tips in this part:
Let's say you built your portfolio project. You used all the advice from part 1. The code quality is alright. In short: You're a great candidate for a Junior React position.
Finally, you take the leap and send out job applications. You're confident that you'll get some interviews soon.
But nothing happens. Nada. No replies. No interviews. Just crickets...
If only somebody could tell you what's going on.
The thing is, you need to understand how the hiring process works. Entry-level positions get swamped with applications. And the people reviewing the applications on a technical level (e.g. team leads or developers) have other things to do.
See for yourself. Let's switch sides for a moment.
Let's pretend you're a developer at a company. A Junior dev applied for an open position. And you're the one who has to review the portfolio projects.
You have a busy day. You're in-between meetings and need to finish a feature you've been working on. Not much time to spend on this candidate.
Now try to observe yourself:
How do you scan the information in this repository?
My eyes quickly scan the folders and files. The folder structure looks pretty standard for a React project at first glance.
In a matter of split seconds, they arrive at the bottom where we can see the content of the README file.
This project obviously was created using create-react-app. The README wasn't changed, so we can dismiss it. Not much information there.
If we were carefully investigating the repository we'd see that there are open issues, pull requests as well as a dozen branches. This might indicate a good workflow.
But let's face it. We're in a hurry, so probably we won't even notice these details.
So what would you being the reviewer do next?
You only have a few options. The most likely ones are
My guess: Most people would start opening files.
Now it all depends on how much time you invest and how quickly you get bored. In any case, you are likely to miss some impressive code hidden in the file structure.
You (the reviewer) have to decide by chance if I'm a great candidate for that Junior position.
How can we fix this?
Let me show you another version of the same repository.
This is the same repository. I only changed the README and the About section at the top right.
As a reviewer, my eyes again would quickly arrive at the README content at the bottom. But instead of dismissing it right away, I'd stop and start reading the section "How I worked on this project":
"Oh wow, this guy knows his sh... On his resume, I saw he has no job experience. But that's pretty much how we work in our team. I bet he'd quickly be productive." - Made-up conversation with myself.
The next section "How to navigate this project" points me to the most important parts of the application. If the code behind these links looks OK, I'm ready to give this candidate a go.
The section "Why I built the project this way" reveals information about the reasoning behind some technical decisions. That's really great because it allows the reviewer to tap into your thought process.
A final section "If I had more time I would change this" shows that you can take a step back and self-reflect. Very important for working in a team.
Only at the very bottom, you can see the available scripts. These almost don't matter anymore. Probably nobody will download the project and run it anyway. But it's good documentation practice to have them.
There's one final advantage of writing such a README that I didn't mention yet:
By writing all this documentation you not only guide the reviewer through the project. You also prove your communication skills. Any experienced hiring manager knows how important yet rare these are among engineers.
So invest some time into writing a clear and descriptive README. Write it. Let it rest. Then return a couple of days later to review it with a fresh pair of eyes.
In short: a clean and informative README will let you stand out from other candidates.
I hope you have everything you need to build React portfolio projects that are stand-out professional.
Here is a final summary of all the important aspects mentioned in this guide: