How I Got Here
Building a startup is hard these days. Building a tech startup is even harder.
My niche is Cloud and DevOps, so from the very beginning I wanted Platform as a Service to be part of my offering. Naturally, I also needed a place where I could test the services I wanted to sell.
So we decided to build our own datacenter.
Looking back, I had absolutely no idea what I was getting myself into.
The funny thing is that I’m about 7 months in, and sometimes it feels like nothing really moved forward. We still don’t have anything publicly available yet. But that’s a story for another post.
For now, I’d like to share some of the less obvious mistakes I made while building a self-hosted IT infrastructure. Hopefully they’ll save someone else a few headaches.
Infrastructure as Code… and Coding Everything
Yes, you heard that right.
These days everyone talks about Infrastructure as Code, Terraform, automation, pipelines, and writing code for every piece of infrastructure.
It’s cool. It sounds sexy. It’s also incredibly satisfying.
But sometimes… it’s just not worth the hassle.
I started with the idea that everything must be written as code. Every configuration. Every service. Every system.
Terraform.
Ansible.
Bash scripts.
You name it.
And while writing automation is fun, I eventually realized something important:
Sometimes you're just fiddling with code instead of finishing the job.
There are moments when you need to ship something quickly. Sometimes a quick click in a UI is perfectly fine.
In my case, I even wrote a full Bash script to auto-configure Proxmox. Later I discovered that something very similar already existed:
Proxmox VE Helper Scripts
https://community-scripts.github.io/ProxmoxVE/scripts?id=post-pve-install
So I basically did the work twice.
Lesson learned: automation is great, but don’t automate things that already have a perfectly good solution.
Sometimes it's okay to just click the button.
Why Backup Anything If I Can Recreate Everything From Code?
This mistake came directly from the previous mindset.
Since everything was defined as code, I convinced myself that traditional backups were unnecessary.
And to be fair, in many cases that actually works.
If a VM breaks?
Just recreate it with Terraform.
Easy.
But here’s the catch.
Real life rarely follows the clean IaC model.
Sometimes you:
- tweak something manually
- test a quick change
- forget to update your Terraform
- don’t want to rewrite a module for the 100th time
And suddenly your perfectly reproducible infrastructure isn’t perfectly reproducible anymore.
So yes, infrastructure as code helps a lot.
But periodic backups still matter.
One important clarification though:
This is about infrastructure backups, not user data.
User data should always be backed up properly.
For infrastructure itself, backups are just a safety net when reality drifts away from the code.
Sometimes restoring a backup is simply faster than rebuilding everything.
Old-school admin practices exist for a reason.
Documentation Doesn’t Need to Be Perfect
Everyone keeps repeating the same advice:
“Always document everything.”
And yes, documentation is important.
But it doesn’t need to be perfect.
At some point I started writing extremely detailed documentation for even the smallest tasks. Sometimes a simple setup ended up with multiple pages of documentation.
Eventually I realized something funny.
Many of those beautifully structured documents were never opened again.
Meanwhile the documents I actually used were:
- quick notes
- work-in-progress docs
- messy personal guides
- short command snippets
Not the polished ones.
Turns out the most useful documentation is often the one that is fast to write and easy to search, not the one that looks perfect.
Write documentation for future you, not for a technical writing award.
The Classic Hypocrisy: No Monitoring for My Own Infrastructure
This one is honestly embarrassing.
One of the products I’m planning to launch is a SaaS observability platform for software houses.
Meanwhile my own infrastructure monitoring barely exists.
It’s somewhere near the top of my backlog, but not properly implemented yet.
Which is ironic.
If you're building infrastructure, monitoring should exist from day one:
- system metrics
- service health
- logs
- alerts
Otherwise you're basically flying blind.
This is something I’m planning to fix soon and probably stream the entire setup process, if anyone is interested.
Doing Everything “By the Book” and Thinking Too Big
Another trap I fell into was trying to do everything the “proper” way.
Perfect architecture.
Perfect processes.
Perfect automation.
But the reality of startups is different.
Sometimes speed matters more than perfection.
What matters most is delivering value, especially to clients.
Ambition is great. Big plans are important.
But when you're:
- bootstrapping
- low on budget
- early in the journey
it’s often better to start small and evolve.
You can always improve things later.
You can’t improve something that was never shipped.
What mistakes did you make?
Building infrastructure is one of those things where you only learn by doing… and by breaking things along the way.
These are just a few mistakes I made in the first months.
I’m sure there are many more waiting for me in the future.
So now I’m curious:
- What’s the biggest mistake you made while building infrastructure?
- What’s something you wish someone told you earlier?
- Did you also fall into the “automate absolutely everything” trap?
I’d love to hear your stories. I suspect I’m not the only one who learned some of these lessons the hard way.
Top comments (0)