How to build React portfolio projects that get you a job + 3 project ideas (2023)

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.

React project ideas for your portfolio

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
• an error-tracking tool
• a web analytics app.

UI Kit

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

1. use this Chrome extension to make your CSS pixel-perfect
2. document the components with a tool like Storybook.

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

• static & interactive components
• many different dynamic states

What you'll learn

• work with designs like in a professional team
• advanced CSS
• UI documentation with Storybook

Error Tracking Tool

Error tracking tools like Sentry or Rollbar are used in every serious software product. The basic functionality is to report errors on websites or applications. The user (aka the developer of the app) can access this information via a dashboard. There they can see an overview of all errors including how often and when they occurred as well as a stack trace that helps to debug the issue.

Such an app makes a great portfolio project. Every hiring manager or developer knows the use case. And adding it to your portfolio shows that you have a good understanding of professional developer tooling.

The design above belongs to an error-tracking app called ProLog that is part of the React Job Simulator here on Profy.dev.

Obviously you can build this app from scratch on your own. There are many free dashboard designs that you can use (I share one below). But if your goal is to prepare yourself and your portfolio for the job hunt the ProLog project is made for you.

Here are a few advantages that you get from the React Job Simulator compared to building a portfolio project on your own:

• You work on an existing codebase with a scalable architecture. It was created by a dev with 7+ years of production experience with React.
• You're exposed to professional workflows, tools, and techniques as they're used in many real-world teams.
• You can focus on deepening your frontend skills as you get a functioning REST API.
• You work with professionally made designs.

Most Junior developers never experience any of this before they start applying for jobs. After all, these are experiences that you usually get on the job. So working on this project helps you make a professional impression in the application and interview process. And it helps you to hit the ground running once you start your first job.

Where you get it: Alternatively, you can find a free dashboard design here to build an error-tracking app from scratch.

Time required: 2 - 4 weeks

Difficulty: advanced

Features

• data visualization (table & graph)
• interaction with a REST API
• a small UI kit
• static marketing page based on a CMS

What you'll learn

• work on an existing codebase
• work with designs & tasks as in a professional team
• advanced CSS & styled-components
• data fetching
• writing tests with Cypress
• professional Git workflow using feature branches & pull requests

Web Analytics Tool

Analytics apps are another common tool used by most businesses. Any hiring manager or developer will be familiar with these tools which makes it a great portfolio project.

Obviously, you don't need to build a full-blown Google Analytics clone. A reduced version similar to new and privacy-friendly tools like Plausible.io is more than enough.

You can either build a server with mock data or build the complete project end to end. This includes

• A small JS library that can be added to a website. This library sends the analytics data to the server.
• A server that stores the data and exposes it via an API.
• A React dashboard that visualizes this data.

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

• separate tracking library or npm package
• dashboard with chart & table

What you'll learn

• building and publishing a JS library (e.g. on npm)
• sending and fetching data from an API
• advanced CSS & data visualization

How to build your React portfolio projects like a pro

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:

• working like a pro
• styles
• application logic
• Git

Professional workflow

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...

(Video) 4 Developer Portfolio Projects to Get Hired

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:

• tasks
• designs.

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.

1. You take the designs and break them into smaller parts (aka features).
2. For each feature, you create a task. You can use a free tool like GitHub project management, ClickUp, or simply Trello.
3. For each task, you collect the requirements. What is the feature supposed to do? How can the user interact with it? Where does the data come from?
4. If a task gets too big you can break it down into smaller subtasks.

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 ProLog error tracking app in the ideas chapter at the beginning 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.

Styles

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 style guides. 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 piece of advice regarding styles:

Don't use global classes.

I see global CSS classes quite often when reviewing Junior React developers' 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 this
import './index.css';
const MyComponent = () => (
 // this will become class="box" in the HTML
 <div className="box" />
(Video) 3 React Projects You Should Have In Your Portfolio (UK)
)
// but rather scoped classes with CSS Modules
import 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

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.

1. Routing: You can use the de facto standard React Router. A route with URL parameters would be nice to have.
2. State: Any dynamic app relies on state. But no need to go fancy here. Since GraphQL or React Query I see more and more applications move away from state management solutions like Redux. So in my opinion, the native React hooks useState, useReducer, or useContext should be sufficient.
3. Data: Your app should at least fetch some data from an API and render it. Ideally, the user can trigger requests dynamically. For example, by applying a filter or submitting a form. You can prove that you understand the data flow, that you can structure your data, and that you know the basic JS array functions like map, filter, or reduce.
4. Tests: Automated tests are essential for any serious software product. And Senior developers value testing very highly. At the same time, most Junior developers have no experience in testing whatsoever. That can be your advantage. If you cover at least parts of your code with tests you'll have a huge advantage over other candidates. Take my word on it and give React Testing Library a try. Here you can find a beginner's guide to testing React apps.

Git

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.

Summary

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:

• Workflows: Write your code based on designs and tasks.
• Styles: write custom & responsive CSS, use styled-components or CSS Modules.
• Logic: your app should have multiple pages, be stateful, and fetch data from an API. I'd highly recommend covering at least part of your code with automated tests.
• Git: Write clear commit messages. Ideally use branches and Pull Requests.

How to present your React portfolio project

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.

How a reviewer looks at your project

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

1. Start opening files more or less randomly.
2. Have a look at the commit history.

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?

Use the README file to stand out

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.

Sections of a good README

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.

Summary

• the README might be the most important page of your project
• you can make sure that the reviewer sees what they need to see
• you can impress the hiring manager with your communication skills
• you will appear a lot more professional

In short: a clean and informative README will let you stand out from other candidates.

Wrapping it up

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:

• Ideas: Check out the error tracking app ProLog here on Profy.dev to take a deep dive into professional React development.
• Workflows: Write your code based on designs and tasks.
• Styles: write custom & responsive CSS, use styled-components or CSS Modules.
• Logic: your app should have multiple pages, be stateful, and fetch data from an API. I'd highly recommend covering at least part of your code with automated tests.
• Git: Write clear commit messages. Ideally use branches and Pull Requests.
• Presentation: Use the README to guide the reviewer through your project. Make sure to point at the most relevant places (e.g. each item in the list above).