Building a Software Career on a $180 Chromebook

People often say software is a skill-based industry, and that’s true. Compared to many careers, the cost to start is low: a computer, internet access, and persistence can take you far.

But there’s a harder version of that story: what if your hardware is barely good enough to begin?

In 2018, I was living in Baltimore County with three roommates, working as a dishwasher, and starting computer science at the Community College of Baltimore County. Money was tight, so before my first semester I bought a $180 Chromebook. It was what I could afford, and it got me online. That was about it.

Working Around the First Wall

My early classes used Java, and running a full local setup on that Chromebook was a struggle. So I adapted: I used AWS Cloud9 as my development environment, wrote code in the cloud, exported files, and submitted assignments from there.

Not ideal, but it worked.

I also hit environment mismatches early, including timezone and locale issues. That was one of my first lessons that still applies today: code quality includes understanding where code runs, not just what it does.

Making the Chromebook More Capable

As classes became more demanding, browser-only workflows stopped being enough. I needed better tooling and more control, so I used crouton to run Ubuntu in a chroot on ChromeOS.

It was a workaround, not a perfect setup. Some tools were unstable. But it let me keep building, and it carried me through my first semesters after transferring to the University of Maryland.

Moving Compute to the Cloud

My next major challenge came in a data science course using R. At that point, local hardware limits were unavoidable.

So I shifted compute off-device and into the cloud with DigitalOcean droplets running RStudio. My workflow was simple:

• provision a droplet
• do assignment work remotely through the web IDE
• push to GitHub for persistence
• tear down the droplet to control cost

That approach worked, and it helped me earn top results in the course.

I also learned an infrastructure lesson early: secure defaults matter. At first I used password authentication and quickly saw why SSH keys should be standard practice.

Turning Constraints into a Portfolio

Grades mattered, but my main goal was clear: graduate into an engineering role.

To make that possible, I built a portfolio project that proved end-to-end execution:

• React frontend
• Express backend
• MongoDB-backed forum
• custom security challenge modules

Because my local machine was still limited, I used remote development workflows over SSH to build and iterate.

I later demoed that project at a university job fair, and it directly helped me land my first industry role as a React developer.

A hiring manager told me:

“You were the only person who applied who demonstrated you could build an app from start to finish.”

That sentence stuck with me.

The Real Takeaway

At the time, this didn’t feel like a big narrative. It felt like solving one problem after another with whatever tools I had.

Looking back, the lesson is straightforward:

• constraints are real, but they are not final
• practical problem-solving compounds fast
• consistency beats perfect conditions

If you’re building with limited resources, don’t confuse constraints with lack of potential. You can still build strong skills, ship meaningful work, and create opportunities.

You are probably closer than you think.