I built FreeClothes.in to learn what a day job won't

Open any tech blog and you'll find the same shape of post: "How I built X with Y and Z." Architecture diagram, repo link, "thanks for reading." I've read a hundred of those. I've written a few.

This is the opposite. Not how I built FreeClothes.in, but why. And the honest why has very little to do with clothes. It has to do with everything a day job won't teach you.

The black box behind git push#

I've been writing product code for a few years now, across two companies. Both jobs were good. Neither one taught me what an application actually looks like once it leaves my laptop.

At work, I push to a branch. Someone else's pipeline takes it from there. There's a preview URL, a green check, and a merge.

The server is a black box I read about in incident postmortems written by people I've never met.

I had never:

• Bought a domain and pointed DNS at a server I owned

• SSH'd into a Linux box and configured a user that wasn't root

• Watched logs at 2am wondering why a thing I wrote stopped responding

• Set up a reverse proxy or thought about TLS termination

• Restored a database from a snapshot

None of this is on most engineering job descriptions. For someone who wants to call themselves a full-stack engineer one day, all of it is.

Why I picked this project#

FreeClothes.in is a platform for donating and requesting used clothes.

The cause is real. Fashion's environmental footprint is real, and the platform exists to do something about it.

But I'll be honest. I picked this project because I needed a real, end-to-end system that lived on a server.

Not a side-project landing page. Not a single-page app on a free tier.

Something with users, image uploads, transactional email, real auth, an admin surface, and a database that would hurt to lose.

A landing page can't teach you anything except how to deploy a landing page. The list of things I didn't know was specific, and the only way to learn them was to need them.

The hidden curriculum#

I won't walk you through them. I'll just name the categories, because seeing the list helps explain why one project replaced a year of YouTube.

• Picking a hosting plan, a region, and an operating system

• Setting up a non-root user, and learning why, only after almost shooting myself in the foot

• Running a database on a machine I had to administer myself

• A process manager: starting, persisting across reboots, zero-downtime reloads, reading logs

• A reverse proxy in front of an application port

• Certificate issuance and renewal

• Setting up SSH keys and being deliberate about what each one can reach

• An external store for media so I wouldn't fight my own disk

• Transactional email that actually arrives

• Cron jobs for the small chores nobody talks about

• An incident doc folder, which I thought was overkill until I needed it

Most of those phrases meant nothing to me eighteen months ago. Some I had heard in standups but couldn't have defined.

Now I've done all of them, on a system real people use.

The pipeline I'm proudest of#

The single coolest thing I built on this project was the deploy pipeline.

Nobody is going to put that on a list of impressive engineering. CI/CD is a solved problem. Every company has one. Every senior engineer has touched one.

I had never built one.

At every company I've worked at, the pipeline was someone else's job. A platform team built it, owned it, and kept it alive. Product engineers like me pushed code, watched the green check, and trusted everything in between. That arrangement is fine, until you realize you've spent years shipping software without ever seeing the layer that ships it.

What pulled me toward building one was watching it from the outside. A monorepo's CI dashboard at work, ten or twenty pipelines firing in parallel off a single push, each one shipping a different service. It looked beautiful every time. I wanted, very badly, to build a tiny one-pipeline version of that for myself.

The first time I pushed to main, I watched the CI run go green. I watched it hand the work off to my server, which pulled the change, installed the right versions, ran the migration, and reloaded the app without dropping a request.

I felt something I hadn't felt at any job.

I had built the thing that catches everyone else's work and puts it on the internet.

The pipeline taught me what tooling at companies is actually doing for you:

• The check job that runs before deploy

• The locked dependency install

• The non-interactive flag that exists only because CI has no human to answer prompts

• The concurrency control that prevents two deploys from racing each other

• The reload that swaps the running process without an outage

Every one of those is a paragraph someone wrote in a postmortem before it was a line in a workflow file.

I don't think I'll ever look at a pipeline the same way again.

The morning I broke production#

The most useful thing FreeClothes ever taught me was the morning I broke its production database.

I was cleaning up things I thought were unused. I checked one config file, decided I knew what was safe, and ran a command that wasn't. The site went down inside a minute. The actual configuration was being read from somewhere I hadn't looked.

The next thirty minutes were the most educational thirty minutes I've spent in years. I learned, in order:

• How to actually read logs instead of glancing at them

• How a provider's snapshot restore really behaves

• That restoring infrastructure can quietly reset other parts of your setup

• That the backup strategy I'd been meaning to write didn't exist

• That "I'll do that later" is a sentence with a cost

I wrote up the incident the same evening. I added a rule that no destructive command runs without me reading it twice. I scheduled the backup I had been putting off. I now understand, in a way no tutorial could have given me, what people mean by "blast radius."

At work, an outage gets discussed in a postmortem and fixed by a platform team. Here, I was the platform team.

The engineer I am now#

FreeClothes is going to do good work. People will give clothes, people will get clothes, and the textile waste number will tick down by a small honest amount. That part is real and I'm proud of it.

But the second outcome, the one I started the project for, is that I'm a different engineer now.

I can read a deploy script and know what each line is protecting me from. I can talk to a backend engineer about cron strategies without faking it. When a server problem comes up at work, I no longer treat it as someone else's domain.

If you've never touched a server, build something that lives on one. It doesn't have to be a startup. It doesn't have to scale. It just has to be yours, on a box you pay for, with users who will notice when it breaks.

That's the only curriculum I've found that actually works.