Lessons from 50 Devs on Docker Hosting
When you talk to enough developers about how they deploy projects, a few patterns start to emerge. Some are obvious in hindsight, others caught me completely off guard.
Here are my biggest takeaways so far.
1. Keep Talking to Users – Always
Interviews aren’t just a pre-launch thing. They work for any kind of app.
It’s amazing how something that feels crystal clear to you as the builder can be completely unintuitive to someone else. Watching real people click around your UI will surface more “aha” moments than weeks of theorizing.
2. Interfaces Should Feel Alive
Users want to feel in control and know what’s happening.
If something is in progress, show it – a spinner, a loading bar, anything. If you can’t give immediate results, fill the gap with meaningful feedback. Never leave people wondering, “Is this thing stuck?”
3. Pretty vs. Functional: Where Devs Lean
Maybe it’s selection bias, but most developers I talked to care far more about a UI being clear and functional than it being flashy.
When AWS’s interface is slow and clunky, anything even marginally better feels like a big improvement.
4. Your Landing Page Might Matter Less Than You Think
Only a small fraction of devs I spoke to read landing pages in full. Many go straight to Getting Started or Try Now.
A common journey seems to be: Top of page → Pricing → Try Now.
Selection bias? Possibly. But it makes me think the “shiny” part of the landing page matters less than making the first click effortless.
If you do read this whole post, I’d love your thoughts on our landing page – what works, what doesn’t, and what’s missing. You can email me at pv@hostim.dev. Honest, constructive feedback is always welcome.
5. Many Devs Don’t Even Know the “Big” PaaS Players
This one surprised me at first: about half of the devs I spoke to didn’t know the names of popular PaaS competitors.
In hindsight, it makes sense:
- At work, devs often don’t handle deployments at all.
- If they do, it’s usually Kubernetes – and where it’s hosted is someone else’s problem.
- For hobby projects, most people just rent a VPS, install Docker, and run
docker compose up.
The upside? There’s still a lot of awareness to be built. The market isn’t as saturated as it sometimes feels from the inside.
6. Listening Pays Off – Literally in Features
When I first started sketching out my platform idea, it was going to be “bare” PaaS – you’d have to create apps, databases, and volumes yourself, wire them up, copy env vars around, etc.
Two questions kept coming up over and over:
- “Do you support Docker Compose?”
- “Do you have templates?”
At first, both answers were no. But after hearing it enough times, I built them.
- Templates now include five common stacks – Spring Boot, Rails, FastAPI, Django, and Node – plus a bunch of open-source apps like Umami, Ghost, Actual Budget, Memos, and more.
- Docker Compose support takes your YAML and turns it into a template. If your Compose file builds from source, the platform will just ask for the Git repo and build it for you.
Strong signals from user conversations made those features obvious to prioritize.
Wrapping Up
If you take one thing from this: talk to users early and often. Even if you think you know what they need – you don’t, not until you watch them try it.