What I Would Build With $100 of Used Hardware

A realistic starter build using second-hand equipment and a narrow service goal. This is the practical question behind the article: what is enough, what fails first, and what should be kept simple?

Start with the job

Choose the service before choosing the hardware. A small server that runs one important workload reliably is more useful than a powerful machine with no clear owner. Write down the expected users, whether the service must run continuously, what data it stores, and what happens if it is unavailable for a day.

The decision points

Priorities, compromises and the first service to deploy. The answer should be based on the workload you can describe today, not a future list of every service you might someday install. Leave room for one sensible change, then stop.

Build it so it can be undone

Keep configuration in a documented location, back up application data separately from the operating system, and record the last-known-good state. Test access from the device you will actually use. If the service is important, write the recovery steps before you need them.

A practical first test

1. Measure the current hardware or service before changing it.
2. Install the smallest useful version of the workload.
3. Run it long enough to see ordinary failure modes.
4. Check logs, storage, temperature and access from another device.
5. Decide whether it earned a permanent place.

The honest trade-off

Every self-hosted service trades money for ownership and maintenance. That can be a good trade, especially for private data, learning or a service that is otherwise expensive. It is a poor trade when the system is critical, undocumented and powered by hardware nobody wants to repair.

Priorities, compromises and the first service to deploy.