AI changed how apps are built. Hosting hasn’t caught up.
Building an application has never been easier. Running one still feels like preparing for a disaster.
Before the first real user arrives, a developer can already be thinking about Docker images, container registries, Kubernetes, Redis, queues, load balancers, managed databases, autoscaling rules, observability, and several monthly bills.
These tools solve real problems. But they solve the problems of successful applications: traffic, coordination, reliability, and teams operating at scale. Most new applications do not have those problems yet.
They have a more basic question:
Does anybody want this?
Infrastructure assumes success too early
The default hosting story treats every deployment like it might receive a million users tomorrow.
So we separate the application from the database. We add a cache before we know what is slow. We introduce a queue before we have enough work to queue. We design for horizontal scaling before one machine has done anything difficult.
That preparation can be responsible for a mature product. For an experiment, it is often just distance between an idea and an answer.
Complexity also creates its own work. Every service needs configuration, credentials, networking, monitoring, upgrades, and failure handling. A small application becomes a small distributed system before it has earned the need to be distributed.
The missing middle
A VPS is efficient because you can put many applications on one machine, but you must operate the machine and decide how everything shares it.
Containers improve isolation and portability, but each application and supporting service still carries a baseline cost. Packing many small projects together quickly becomes an orchestration problem.
Traditional shared hosting packs applications efficiently, but usually gives developers little control over resource isolation or modern application runtimes.
There should be a middle ground: one pool of resources, many properly isolated applications, and a platform that manages how they fit together.
AI creates more attempts, not guaranteed winners
AI-assisted development changes the economics of creating software.
One person can now build:
- several product experiments in a week,
- an internal tool for a temporary workflow,
- a client prototype before the next meeting,
- a small application for a narrow community,
- or five versions of the same idea to find the one that works.
The number of applications can grow dramatically without the number of successful applications growing at the same rate.
That distinction matters. If AI creates one hundred times more attempts, infrastructure cannot price and operate every attempt as though it were already a production business.
Most of those applications will have little traffic. Some will be used for a few days. Some will wait weeks between requests. A small number may become important.
The right platform should make all of those outcomes acceptable.
Simplicity is a feature
For early applications, the ideal infrastructure is deliberately boring:
- Connect the code.
- Deploy the application.
- Add a database if it needs one.
- Get a URL.
- See if the idea works.
The platform should carry the operational complexity until the application has evidence that it needs more.
This does not mean scalability is unimportant. It means scalability should arrive in response to usage—not as an entrance fee for experimentation.
Developers should spend their early time on the product: talking to users, changing the workflow, removing features, and trying again. A perfectly scalable application that nobody needs is still a failed experiment.
Build first. Earn complexity later.
Lacho is our attempt to build hosting around this new reality.
The goal is simple: deploy JavaScript applications without assembling a stack of infrastructure first. The runtime and an optional private SQLite database are handled together. Quiet applications should consume very little, and applications that find real usage should have a path forward.
We are still in alpha. Limits, paid plans, and production guarantees are not defined yet. That is intentional. We want those decisions to come from measured usage rather than copying the assumptions of platforms designed for a different way of building.
AI makes it cheap to create an idea. Hosting should make it cheap—in money, time, and attention—to discover whether that idea deserves to grow.
Every successful product starts as an experiment. Infrastructure should let it remain one until it proves otherwise.