Should you build or buy Platform as a Service (PaaS)?
A platform as a service runs application code without the customer managing servers directly: it builds from source or a container, routes traffic, scales instances, collects logs and patches the underlying operating system. Teams use it to deploy web applications and background workers without hiring dedicated infrastructure staff.
Yes, and plenty of teams have. Kubernetes with Knative and Argo CD, or Dokku, Coolify and Kamal on plain hosts, cover what a PaaS does, and the named Heroku departures ran in production for years. The honest cost is operational: patching, backups, multi-region failover, compliance evidence and on-call become yours, and the published case studies say that took longer and cost more people than expected. Use the credible alternative to negotiate and to keep an exit rehearsed, and self-host when steady workloads and an existing platform team make the operations cheap for you.
Build it, buy it, or bridge?
When building makes sense
Self-hosting the equivalent of a PaaS is a documented, mainstream choice, not a fringe move. Salsify built its own Kubernetes platform, with in-house tooling it named salsifyk8s and ksonnify, after outgrowing Heroku, and the project ran roughly six months past its original schedule with the tooling still needing upkeep. Algolia moved its search crawler from Heroku to Google Kubernetes Engine and needed several weeks to get it running sustainably before shutting Heroku down. Neither team says this was fast: each ended up owning infrastructure work that used to be Heroku's job. Building pays off when the workload is steady enough to amortize that cost, when the team already has or is willing to grow SRE capacity, and when the platform bill has grown large enough that the labor trade makes sense. It does not pay off as a reaction to sticker shock alone.
When buying makes sense
Buying remains the right default for most teams, and Heroku's own February 2026 announcement makes the case for staying deliberate rather than reactive: the company is shifting to a sustaining-engineering model focused on stability and security, existing customers see no change to pricing or billing, and Enterprise contracts keep renewing, just with no new ones being sold. That's a signal worth watching for teams on Enterprise plans, but not an emergency for anyone paying by credit card today. Forto's early years show why most teams should still start here: Heroku let a three-person engineering team ship a product without hiring for infrastructure, and Forto only migrated once it had grown past twelve engineers and could staff a dedicated SRE function. Buy when the team is small, when the workload isn't steady enough to justify dedicated operations staff, or when engineering time is worth more spent on the product than on Kubernetes fluency.
The desk read
Build-versus-buy analysis for Platform as a Service (PaaS) is being written. In the meantime, the framework that drives every B4 call is on the B4 Index page.
Frequently asked
What does a platform as a service actually do?
It takes a source repo or container image, builds and deploys it, then handles scaling, load balancing, log collection and OS patching so a team never touches a server directly. The tradeoff most buyers hit later is that the same convenience makes the platform hard to peel off once traffic or team size outgrows its opinionated defaults.
Is Heroku shutting down?
No. Heroku announced in February 2026 that it's shifting to a sustaining-engineering model focused on stability and security rather than new features. Existing customers see no change to pricing or service, and current Enterprise contracts keep renewing; only new Enterprise contracts have stopped.
Can a team realistically replace a PaaS with its own Kubernetes setup?
Yes, and it's a documented path. Forto migrated from Heroku to Kubernetes on GCP as it grew past twelve engineers, though it took real planning and eventually a five-person Site Reliability Engineering team to run well.
What's the real cost of self-hosting instead of buying?
Not the platform fee, but the operations behind it: patching, backups, on-call and the engineering time to build a deployment pipeline. Salsify's own Kubernetes migration ran about six months past its original schedule, and the in-house tooling it built kept needing maintenance well after launch.