What 'Fully Managed' Actually Means

"Fully managed" gets used a lot in software services marketing. It sounds good. It means different things to different shops — and in many cases, it means very little at all.

Here's what we actually mean when we use the phrase, and how to hold any dev shop accountable to it.

The Baseline: Working Software in Production

The minimum bar for any engagement is working software that runs in production and is accessible to real users. This sounds like a given. It isn't. We've heard from founders who finished a months-long agency engagement with code that had never been deployed to a real environment — only demoed locally.

Production deployment is not a final step. It's the starting point. Everything we build is live, at a real URL, from week one. That's the baseline.

Hosting

We provision and manage the hosting infrastructure for every project we deliver. That means we pick the right hosting provider for the workload, configure it, and ensure the application has the right compute, memory, and scaling settings to handle real traffic.

Hosting isn't set-and-forget. Providers release updates, pricing changes, and resource limits evolve. We stay on top of this so our clients don't have to.

CI/CD

Every project we deliver has a continuous integration and continuous deployment pipeline from day one. When a developer pushes code, automated tests run, and if they pass, the code deploys to production automatically.

This means no manual deployments, no "I'll push it this afternoon," and no "it works on my machine." It also means new developers can contribute without needing a 45-minute onboarding session just to deploy.

Monitoring and Observability

A deployed application that nobody is watching is a liability. We configure error tracking, uptime monitoring, and performance observability on every project. If something breaks at 2am, we know about it before our clients do.

This includes application-level error tracking, so when a user encounters an unhandled exception, we see the full stack trace and context — not just a vague "something went wrong."

Security

Basic security posture is non-negotiable. This includes HTTPS everywhere, environment variables handled correctly (never in the codebase), dependency auditing, and authentication systems that don't have obvious vulnerabilities.

We don't treat security as a checkbox to revisit at the end. It's part of the foundation we build from the start.

What Falls Off When a Shop Isn't Fully Managed

Here's what typically gets dropped when a dev shop doesn't operate this way:

→ Infrastructure is handed off to the client — often with a comment like "you'll want to set up hosting yourself." The client, who hired a dev shop because they're not technical, is now responsible for managing servers.

→ No CI/CD — deployments happen manually, inconsistently, and with a high risk of human error. New developers need significant onboarding time just to ship code.

→ No monitoring — the client finds out about bugs when users complain. By then, the issue has often been affecting users for hours.

→ Security is an afterthought — environment variables end up in the wrong places, dependencies have known vulnerabilities that were never audited, and the auth system has edge cases nobody thought about.

How to Evaluate Whether a Shop Is Actually Managed

Ask these questions before signing:

→ What hosting provider will you use, and who owns the account and billing?

→ Describe your CI/CD setup. What happens between a git push and code being live?

→ What monitoring and error tracking do you configure by default?

→ How do you handle environment variables and secrets?

If the answers are vague, that's your signal. Fully managed isn't just a marketing phrase — it's a set of specific responsibilities. Make sure you know exactly which ones your shop is taking on.