I have been a developer for fifteen years. I have used hundreds of tools. Some of them cost more than my first car. Some of them cost nothing and do the job better. The twelve below are the ones I open every single day, in order of how often I reach for them. None of them cost money. Several of them replaced paid tools I used to spend hundreds of dollars a year on.
This is not a “ten tools you absolutely need” roundup. The trade-offs are real, and I will name them.
The 12 tools, in the order I reach for them
I will not bury the list. Here it is, with the job each tool does and the paid tool it replaced (if any):
- VS Code. My editor. Free, runs on Mac, Linux, and Windows. I used to pay for the JetBrains Java IDE ($149 per year for individuals, $499 for businesses). VS Code with the right extensions does what I need. The trade-off is the Java stack: if you live in Spring or Kotlin and want first-class refactoring, IntelliJ is still the right call.
- Git. Free, comes with every Mac and Linux machine. The paid alternative would be a hosted Git service that I pay for on top, but the version control system itself is free. I use the command line 90% of the time and the rest inside VS Code.
- Docker Desktop. Free for personal use and small businesses (under 250 employees and under $10M in annual revenue, as of 2026). I run Postgres, Redis, and a couple of Node services in containers locally. The paid alternative would be a hosted dev environment, which costs hundreds per developer per year.
- Postgres. Free, open source, runs everywhere. My default database. The paid alternative would be something like AWS RDS, which is Postgres with a wrapper. I run Postgres directly on my dev box, and I run Postgres in production on a Linux server.
- Redis. Free, open source. I use it for caching and for queues. The paid alternative is a managed Redis like AWS ElastiCache or Redis Cloud. For small workloads, self-hosting is fine.
- Node.js. Free. My default for any quick server. The paid alternative is something like a cloud function service, which costs per request.
- curl. Free, comes with every Unix machine. I use it to test APIs, to download files, and to debug HTTP problems. There is no paid alternative.
- jq. Free, open source. A command-line tool for slicing and dicing JSON (a common data format used by web APIs and config files). I use it every day to inspect API responses. There is no paid alternative.
- htop. Free, comes with most Linux systems. A better version of
top(a built-in command that lists running processes). I use it to see what is eating CPU or memory on a misbehaving box. There is no paid alternative. - tmux. Free. A terminal multiplexer (a tool that lets you run multiple terminal sessions inside one window, switch between them, and keep them alive when you disconnect). I use it to keep long-running processes alive when I close my terminal. There is no paid alternative.
- Firefox Developer Edition. Free. My default browser for testing web apps. The paid alternative is a debugging proxy like Charles Proxy ($50 per license).
- Obsidian. Free for personal use. My note-taking and knowledge base. The paid alternative is something like Notion ($8 per user per month on the Plus plan), which I used for two years before switching. I do not miss it.
That is the list. The order is roughly how often I reach for each one, with VS Code and Git being the only ones I touch every hour.
What I gave up by going free
The honest part. Free is not free. Here is what I traded:
- No vendor support contract. When Postgres gets weird at 2 AM, I read the source, read the docs, or ask the mailing list. With a paid database, I could open a ticket. For a solo developer or a small team, the docs and the community are usually faster than a support contract, but for a regulated workload (healthcare, finance), support matters.
- More setup time. Self-hosting Redis means installing Redis, configuring systemd (the init system that manages services on most modern Linux distributions, handling startup, restarts, and logging), setting up backups, and monitoring it. A managed service does most of that for you. The time trade-off is real: expect to spend 4-8 hours setting up a self-hosted service the first time, and 1-2 hours per year maintaining it.
- No “single throat to choke.” When something breaks in a stack of free tools, you are the throat. With a paid SaaS, you can email support and cc your boss. With free tools, you fix it yourself or hire someone. For a small team, this is fine. For a 50-person engineering org with on-call rotations, the math changes.
- A few niche features. IntelliJ’s Java refactoring is better than VS Code’s. Figma’s auto-layout is better than Penpot’s. Adobe Lightroom’s noise reduction is better than RawTherapee’s. For the things I do every day, the free tools are good enough. For the things I do once a quarter, the paid tool is sometimes worth the money.
How I picked these twelve
I did not pick them by reading “top 10 free dev tools” listicles. I picked them by tracking what I actually used for thirty days. I kept a list. At the end of the month, I sorted the list by how many times I had opened each tool. The top twelve are the list.
The surprise was how many paid tools I was paying for out of habit, not need. I was paying $99 per year for a code formatter that VS Code does for free. I was paying $50 per year for a JSON viewer that jq does better. I was paying $8 per month for a note app that did the same thing as Obsidian. The paid tools were not bad. They were just not earning their subscription.
If you want to do the audit yourself, here is the process:
- Track every paid tool you use for 30 days. A spreadsheet is fine. Note the price and the last time you actually used a paid feature that the free alternative could not do.
- For each paid tool, find the free alternative. Search the web, ask a friend, or try the suggestions in this article.
- Switch one at a time. Do not rip out five tools in a week. Switch one per month. Give yourself time to learn the new tool and find the gaps.
- Keep a “paid tools I would buy back” list. After thirty days, you will know which paid tools were actually earning their keep. Pay for those. Cancel the rest.
Trade-offs
Going free is not free in time. Self-hosting a service takes 4-8 hours the first time and 1-2 hours per year to maintain. A managed service does that for you, for a monthly fee. For a solo developer, the math favors free. For a 50-person team, the math can favor paid.
The free tools I picked are the ones I happen to use. Your stack is different. If you are a data scientist, your “12 daily tools” will include Jupyter, pandas, and R or Julia. If you are a frontend developer, it will include Figma or Penpot and a CSS framework. The principle is the same: track what you use, audit the cost, switch if the math works.
The biggest risk is the “free for now, paid later” trap. Some tools are free today because the company is in growth mode. They will start charging when growth slows. Obsidian, VS Code, and Postgres are not in this category: they are open source or funded by other means. But smaller free SaaS tools can pivot to paid overnight. Read the terms. If the tool is the load-bearing wall of your workflow and the company is venture-backed, plan for a future where you might need to switch.
If you are a solo developer or part of a small team, going free on the dev stack is a clear win. If you are part of a large org with on-call rotations and compliance requirements, the trade-off is closer. Audit first, then decide.
What I would tell past me
If I could send a message back to the version of me that paid for ten SaaS subscriptions in 2020, I would say three things.
- Track what you actually use, not what you signed up for. Subscription inertia is real. I was paying for tools I had not opened in six months.
- The free alternative is rarely as polished. It is often good enough. I do not need a beautiful UI to edit JSON. I need a tool that does the job.
- Self-hosting is a skill, not a punishment. Once you have set up Postgres, Redis, and a process manager (a tool that keeps your services running and restarts them if they crash) on a Linux box, the second one is faster. The fifth one is an afternoon.
The twelve tools above are not the only twelve. They are the ones I happen to use. Build your own list by tracking for thirty days. The result will probably surprise you.