Time to rethink local development

For about as long as I’ve worked in tech, ‘local development’ has mostly meant one of two things:

1. The Developer Laptop: install a bunch of stuff until everything works. Lots of freedom, very little ‘developer friction’. Also, bespoke setups to manage the myriad of different tools/versions/configs, and days wasted because “local dev was broken”.
2. Corporate VDI Hell: you can’t do anything locally but you have to use ‘development VDI’ solutions that are usually too locked down, running the wrong OS (Windows…), lacking the right tools (Notepad++ and PuTTY aren’t going to cut it), and are slow to the point of being unusable. Oh, and you can’t copy/paste either. Or access the internet. For security reasons.

Both models have significant issues. Security issues, financial challenges (dev laptops aren’t getting cheaper), user experience (and staff retention), friction, onboarding experience, etcetera. It’s a complex set of tradeoffs that will make it very hard to create a single approach that will be ‘the best’ for everyone.

But instead of trying anyway, it seems that as an industry we’ve settled on the 2 extremes, and left it at that.

Better solutions?

It seems that the ‘complex set of tradeoffs’ has been scaring the tech industry away from this particular issue. Surely, tools and solutions do exist, and some of them are quite good. Solutions like:

• DevContainers: create codified, repeatable, containerized development setups. You only need a container runtime and a compatible IDE. No installing anything on laptops, no hours wasted on figuring out how to set up and configure the dev setup for a project you just wanted to fix one thing on. Easy onboarding, better security.
• Coder Workspaces: Run codified development workspaces anywhere. Leverage cloud or datacenter compute for hosted development environments that developers can use with their favourite IDEs. The upsides of VDI without the downsides.
• DevPod: a client-only solution for running codified development workspaces anywhere. Use it as a convenience wrapper around DevContainers, or to leverage compute resources outside of your laptop.
• Github Codespaces: cloud development environments ‘as a Service’ through Github.

And that’s just some tools for ‘codified development setups’. A part of the problem space. But maybe it’s the part we should start with.

A market problem

Building solutions costs time and money. And in 2026, when money is involved investors want their investment back a.s.a.p. So you don’t just need a good product; you need a business model to monetize that product. A growth strategy. Marketing. Or your funding eventually runs out, and your product becomes abandonware.

One of my favourite ‘dev setup tools’ used to be Gitpod (see also this blogpost), before it fell subject to what I presume is investor-driven AI-enshittification.

Gitpod offered a great product for ‘codified development workspaces’ that struck a really nice balance for individuals and small teams. You could run on their cloud infrastructure, your own, or even locally on your computer. But the business model wasn’t quite there. After a few pivots that scared users away, they found some new investors and pivoted once more: a full rebrand to Ona, an AI-first platform. Existing users updating their Gitpod app were faced with, without any prior warning, a new mandatory onboarding process that required granting Ona (which nobody had ever heard of before that point) access to all of their Github repositories, while also killing the local Gitpod workspace runner in the process. I just wanted to work on the workspace I had running, not onboard on some new AI thing I didn’t ask for, or grant it access to all my code for no reason. Not an option¹. I jumped ship here, and moved to DevPod. Time will tell if Ona becomes successful.

DevPod, an open-source project built by Loft Labs, turned out to be a great, but basic solution for my needs. No AI-sauce here, no weird rebrands. But unfortunately, also no clear business strategy to monetize DevPod. As a result, when Loft rebranded to vCluster Labs last year, development on DevPod pretty much halted, which alerted users. Fortunately, with DevPod being client-only and open-source, you could simply continue using your environments, and a community fork was created in response.

Why should we care about this now?

We’ve just established that the market doesn’t care about solving these issues. Hard problems, not a lot of profit. But I don’t think that’s the root cause; it’s just how capitalism works. Instead, the tech industry doesn’t care enough about addressing the challenges, so the demand for solutions doesn’t exist. But the tech industry should very much care about this for a few simple reasons:

• The inevitable rise of Agentic Coding: if we are to believe the hype AI can build better software than humans and increase developer productivity by 10x. But it’ll need resources and usable environments to do that. It’ll need consistent environments to function consistently. It’ll need containment and guardrails to not destroy your business.
• Security and Geopolitical instability: we seem to be closer to WW3 than we’ve ever been. Alliances are proving to be fragile, with allies turning to blackmail when they feel like it. Wars that aren’t wars but ‘military operations’, and the rise of ‘hybrid warfare’ means that increasingly infrastructure, technology, and information infrastructure become legitimate targets. Having hundreds of devs carry your company secrets with them on their laptops is an attack vector that is very hard to manage.
• Chip shortage and pricing: software development is getting increasingly resource intensive, and if we add local AI tooling (or worse, local models) to the equation, we need more compute, more RAM, and more storage than ever before. And that a point where RAM prices are skyrocketing. What if a ‘good dev laptop’ doesn’t have to be a MacBook Pro with an M5 Max chip and 64GB of memory (currently EUR 5124 including taxes)?

If there was ever a time for companies to start caring about better ways to manage development setups, it’s now. For the sake of security, usability, productivity, as well as hardware cost.

Putting my money where my mouth is

I never liked travelling with ‘a laptop full of company secrets’, which is part of why I’ve been interested in this space for years. So for travel, I would often take my iPad and then do whatever development I had to do remotely — using SSH or using web-based VSCode solutions like Codespaces, Gitpod, or DevPod. But recently I was in the market for a new laptop. A laptop I would mostly use for basic things, some occasional Logic Pro or guitar plugins, and a bit of dev work here and there. I decided I wasn’t going to drop at least EUR 1800 just to get 32GB of RAM, that I’d only need for a handful of development situations or AI experimentation. Things I could already do on my Mac Studio.

I ended up with a MacBook Air with an M4 CPU, 16GB of RAM, and 512GB of SSD, costing less than 20% of the ‘good dev laptop’ I mentioned above. It will handle pretty much everything I’ll throw at it without breaking a sweat, but it will run out of memory if I start running Kubernetes clusters, large dev setups, or AI models. For those particular use cases I will rely on ‘external compute’ in the form of either my Mac Studio, or on-demand compute on Scaleway.

If you want to know how my setup works, and how you can build it yourself, watch this place. A deep-dive is coming soon.