Everyone and their dog is rebuilding apps right now. „I rebuilt Jira in 48 hours with Claude.“ „I cloned Notion in a weekend.“ Cool. I’m genuinely impressed. But let me ask you a follow-up question that nobody seems interested in answering: what happens on Monday?
Because building the thing was never the hard part. Running the thing is.
I’ve watched this play out a dozen times. Some team gets excited, vibe codes their way to an MVP, deploys it, high-fives all around. Then six months later they’re drowning. Not because the code is bad. Because they forgot that shipping software is maybe 20% of the actual work. The other 80%? That’s the part nobody puts in their Twitter thread.
So let me walk you through the actual cost of running an app. The stuff that doesn’t make for good content but absolutely makes or breaks your product.
the invisible tax: observability
The moment your app goes to production, you need to see what it’s doing. Monitoring. Alerting. Logging. Distributed tracing. These aren’t nice-to-haves. They’re the difference between „we caught the issue in 5 minutes“ and „users have been seeing errors for three days and nobody noticed.“
And this stuff isn’t free. Datadog will happily charge you the price of a junior engineer’s salary just to watch your logs. Grafana, Prometheus, OpenTelemetry, pick your stack. It all takes time to set up, time to tune, and time to maintain. You think setting up alerts is easy? Wait until you’re getting paged at 3 AM because someone set a threshold too low and now your on-call engineer is sleep-deprived and angry.
Here’s the thing nobody tells you about alerts: someone has to respond to them. That means you need an on-call rotation. That means you need runbooks. That means you need a process for escalation. You just went from „I built an app“ to „I need to build an operations team.“ Congrats.
managed services won’t save you (but they help)
„Just use serverless! Just use a managed database! Just throw it on Vercel!“
I hear this constantly. And look, I’m a huge fan of managed services. Lambda, Cloud Run, PlanetScale, Neon, whatever. They absolutely reduce the operational burden. You don’t have to patch your own Postgres. You don’t have to manage your own Kubernetes cluster. That’s real value.
But „managed“ doesn’t mean „zero maintenance.“ Your serverless function still has cold starts that frustrate users. Your managed database still has connection limits you’ll hit at scale. Your queue service still needs dead letter handling when messages fail. You traded one set of problems for a different, smaller set of problems. That’s a good trade. But it’s not a zero.
the scale wall
So your app is running. Users are happy. Then one day your database query that used to take 20ms is now taking 2 seconds. Your API that handled 100 requests per second is falling over at 500. You just hit the scale wall.
Finding bottlenecks is a skill. Fixing them is a project. Sometimes it’s a simple index. Sometimes it’s a complete rearchitecture of how you handle data. And every fix needs to be implemented, tested, deployed, and then monitored to make sure it actually worked and didn’t break something else. That cycle of „identify, fix, verify“ can eat weeks of engineering time. Per bottleneck.
dependency hell is forever
Here’s one that slowly kills teams: your dependencies rot. Node 18 hits end-of-life. That npm package you depend on has a critical CVE. Python 3.9 is no longer getting security patches. Your Docker base image is three years old and full of vulnerabilities.
You can automate some of this. Dependabot, Renovate, coding agents that handle upgrades. Great tools. They’ll handle the easy stuff. But then you get that one upgrade where a major version bump changes the entire API surface. Or your ORM drops support for a query pattern you use in 47 places. Or the new runtime version subtly changes how async works and now you have a race condition that only shows up under load.
Someone has to review every single one of these updates. Even the automated ones. Even the ones that „look fine.“ Because „all tests pass“ and „actually works in production“ are two very different statements. You do have comprehensive tests, right? Unit tests, integration tests, end-to-end tests? Because if you don’t, every dependency update is Russian roulette.
infrastructure never sits still
Your cloud provider deprecates the service you built on. Kubernetes releases a new version and drops support for the API version you’re using. AWS announces that the Lambda runtime you picked is going end-of-life. Terraform has a provider update that changes how your networking works.
I’ve personally spent entire sprints just keeping infrastructure current. Not adding features. Not fixing bugs. Just making sure the foundation doesn’t crumble. It’s the engineering equivalent of mowing the lawn. Nobody notices when you do it, but everyone notices when you don’t.
users will find the bugs you didn’t
You built the happy path. Users will find every unhappy path you didn’t think of. The form that breaks when someone pastes in emoji. The API that times out when a user has 10,000 records instead of 10. The payment flow that fails on Safari because of course it does.
And then come the feature requests. „Can we add SSO?“ „We need RBAC.“ „Our enterprise customers want audit logs.“ Each of these sounds like one sentence but represents weeks or months of work. Someone needs to triage these, prioritize them, scope them, build them, and communicate back to the customer. That’s not engineering. That’s product management. That’s customer support. That’s a process.
the compliance monster
Depending on your industry and your users, you might need SOC 2. Or GDPR compliance. Or HIPAA. Or all three simultaneously. That means policies, documentation, access controls, audit trails, data retention rules, incident response plans, and regular reviews.
This is the kind of work that makes engineers‘ eyes glaze over. It’s also the kind of work that can shut down your entire business if you skip it. Compliance doesn’t write itself, and it doesn’t maintain itself. It’s a living, breathing tax on your engineering capacity.
the support tax
Users need help. They email you. They open tickets. They tweet at you. They find your personal GitHub and open issues there (true story). Someone needs to respond. Someone needs to investigate. Someone needs to follow up.
You need a process for this. A ticketing system. Response time SLAs. Escalation paths. And real humans spending real time helping real users. This is not optional if you want anyone to actually pay for your product.
so should you build it?
Look, I’m not saying don’t build things. Building is great. The tools we have now are genuinely incredible and I use them every single day. What I am saying is that „I can rebuild Slack in a weekend“ and „I can run a Slack competitor“ are separated by an ocean of operational work that nobody wants to talk about.
Before you rebuild that established app, ask yourself: am I ready to monitor it, alert on it, scale it, update its dependencies, maintain its infrastructure, handle its edge cases, manage its compliance, and support its users? Because the SaaS you’re trying to replace? They already have teams doing all of that.
Sometimes the best engineering decision isn’t building something new. It’s knowing when someone else has already solved the hard problems and paying them $20 a month to deal with it.
The vibe-coded MVP is the easiest part of the whole journey. Everything after that is where the real work begins.
Peace, nerds.