June 29, 2026?3 min

Stop Building IDEs, Start Building Workflows

Why I ditched heavy IDEs for lightweight tools that actually match how I work with PHP and Node.js.

PHPArchitectureOpen Source

I get it — IDE minimalism appeals to developers. But I've learned the hard way: the problem isn't the IDE. It's that most developers are trying to force one tool to do everything.

When I'm building Seven CMS or working on ERPNext customizations, I don't need an IDE. I need a workflow. VSCode with extensions gets me there faster than any "minimal" IDE built from scratch.

Here's what I actually use:

  • VSCode with the right extensions (PHP Intelephense, REST Client, SQLTools)
  • Terminal split-screen for running tests and servers
  • A simple script runner for repetitive tasks
  • Database UI tools I can throw away and rebuild in 20 minutes

The real minimalism isn't building a new IDE. It's knowing what you don't need.

I've worked on legacy PHP systems where developers were stuck in PhpStorm, waiting 30 seconds for autocomplete. Meanwhile, I'm in VSCode with a 2MB footprint, same results, faster iteration. For modernizing legacy code, speed matters more than features.

Where IDEs actually help: when you're on a team and need everyone on the same page. That's when you invest in tooling standardization. At that point, Docker + VSCode devcontainers beats any custom IDE.

The Python + ttkbootstrap approach is clever engineering. I respect it. But here's the question: would you want to use it? Or would you use it because someone built it? Those are different things.

Building tools is fun. I do it constantly with Seven Suite. But I ship features first, tools second. If my custom tools distract from shipping, they're wrong tools.

For PHP developers specifically: you don't need a new IDE. You need:

  1. A linter that catches real errors (PHPStan, Psalm)
  2. A formatter (PHP-CS-Fixer) that runs on save
  3. A debug setup that actually works (Xdebug + VSCode debugger)
  4. One good test runner

That's it. Everything else is nice-to-have.

Build tools because the problem is unsolved. Not because you can.