I set out to build a GitHub search app with React and the GitHub API — just a portfolio project, nothing more. Type a username, hit the API, show the profile, list the repos with stars and forks. Standard stuff. But halfway through, I caught myself obsessing over things no portfolio reviewer would ever grade, and that was the moment the project stopped being about React and started being about my career.

A project that looked completely ordinary

On paper the app was as generic as it gets. A search box, a call to api.github.com/users/{username}, a profile card, and a list of repositories underneath. Stars, forks, primary language, last commit date. I wanted it clean and functional — the kind of thing you drop into a portfolio to prove you can wire a frontend to a real API.

That is exactly the app I built. What I did not expect was which parts of it I would fall in love with.

The details I could not stop tuning

Here is where it got strange. I kept going deeper into problems that did not matter for a portfolio piece:

  • Debounced search, so a fast typist would not fire a request on every keystroke and burn through the GitHub API rate limit.
  • Pagination, because some users have hundreds of repositories and loading them all at once is lazy and slow.
  • Rate-limit handling — reading the response headers and backing off gracefully instead of throwing a cryptic error at the user.
  • Data presentation for technical people — commit counts, language breakdowns, the numbers an engineer actually reads.

None of that was going to impress anyone reviewing a portfolio. Nobody grades your rate-limiting strategy on a demo app. But I could not stop. I did not care whether the UI was beautiful. I cared that the thing worked well for someone technical.

The moment it clicked

At some point I sat back and asked the obvious question: why am I optimizing API rate limiting for a project nobody will ever run in production?

The answer was uncomfortable and clarifying at the same time. I was not building a consumer app dressed up as a React exercise. I was building developer tooling — and pretending it was a React project. Every instinct I had pointed at the same target: make it efficient, make it correct, make it useful for other engineers.

I was building a search bar for people who read commit counts for fun. And I was having the time of my life doing it.

Side projects are a career compass

I did not sit down one day and decide to become a DevOps engineer. My side projects decided for me. Every free weekend, without anyone assigning it, I gravitated toward the same things: APIs, automation, tooling, making other engineers faster. That pattern was louder than any career plan I could have written on purpose.

Because here is what I eventually understood: DevOps is developer tooling at infrastructure scale. The exact pull I felt building a GitHub search app — caring about efficiency, rate limits, clean data for technical users — is the same pull that shows up when you build CI/CD pipelines, internal platforms, and automation a whole engineering org depends on. The search bar was the small version. Infrastructure was the big one. I just had not connected them yet.

What I would tell you

If you are grinding through side projects just to "have something on GitHub," you are half-using them. The code is practice. The pattern is the real output.

Pay attention to what you build when nobody is telling you what to build. Notice which parts you optimize past the point of reason. Notice what you keep coming back to on a free Saturday. That is not procrastination — that is your compass, and it is usually pointing at a career you have not named out loud yet.

For me it was a GitHub search app: React on the front, the GitHub API on the back, and a rate-limiting strategy nobody asked for. That unnecessary rate-limiting strategy turned out to be the most honest career-assessment tool I have ever used.

So the next time you build something for yourself, ask which parts you cared about too much. The answer might just be your whole next decade.