Building well is just as important as launching well.

Por qué el despliegue es donde los proyectos fallan

There is a common assumption in web development projects: If the code works, the launch is just a formality. It isn't.

The environment in which an application is developed is never identical to the environment where it will run in production. Missing configuration variables, certificates that aren’t activated, database migrations that weren’t executed in the correct order, external services that behave differently under real load—all these issues exist and manifest themselves at deployment time, not during development.

On top of that, there’s the pressure of the launch: there’s a deadline, expectations have been raised, and users are waiting. It’s exactly the worst time to improvise and that's exactly when you improvise the most—when there isn't a defined process.

A well-managed deployment doesn't eliminate uncertainty — it reduces it to a manageable level. And when something does go wrong, a defined rollback process means minutes of downtime instead of hours.

A defined process, not a to-do list

Every project goes through the same verification cycle before going into production. Not because it’s the fastest way to launch — it’s the most predictable way, and predictability in a pitch is more valuable than speed.

The production infrastructure is set up in parallel with development, not just a week before launch. Configuration variables are defined and verified from the start. Database migrations are tested in advance. The automated deployment pipeline is up and running before launch day. When the time comes, there are no pending decisions because they have already been made.

Why do we separate development, staging, and production?

A serious project doesn't exist in just one environment. It exists in three, and each one serves a different purpose that justifies its existence.

Development is where the team builds. It is the most flexible environment, the most error-tolerant, and the closest to the developer's workstation. Here, you can test ideas, break things, and rebuild them without affecting anyone else.

Staging This is the dress rehearsal. It replicates production as closely as possible—same infrastructure, same configuration variables, same database with representative data— but without real users. Any new functionality goes through staging before reaching production. This is where the complete workflows are verified, integration tests are run, and it is validated that the deployment works correctly before proceeding with real consequences.

Production is the live environment. Only code that has gone through development and staging, and has been verified and approved, reaches this stage. It is the most secure environment, with the most restrictive permissions, and the only one where every decision is made with the utmost care.

The reason why many projects fail in production with code that worked during development is precisely the lack of a staging environment that detects issues before they affect the end user.

The Right Infrastructure for Every Project

There is no single deployment infrastructure that is universally correct. Choosing the right one depends on the type of project, the budget, the expected traffic volume, and the level of control required. These are the three options we work with and the criteria for choosing between them.

Serverless — Vercel

The most efficient option for Next.js projects without a dedicated backend or with a lightweight backend. The code runs on demand and scales automatically based on traffic, without the need for server management.

Dedicated VPS — Hetzner, DigitalOcean

Full control over the runtime environment at a predictable cost. With Docker, the project runs in portable and reproducible containers that can be moved to another infrastructure without reengineering.

Enterprise Cloud — AWS, Azure

For projects with enterprise-level requirements, high-volume traffic, or industry-specific regulatory compliance. They offer the most comprehensive managed services ecosystem on the market.

Database: An in-house infrastructure decision

The database deserves special consideration because in many projects, the best approach is to deploy it separately from the rest of the application—not on the same server.

For projects that prioritize operational simplicity, managed services such as Supabase — for PostgreSQL — or MongoDB Atlas — for document databases — they completely eliminate the need to manage the database server: automatic backups, managed scaling, built-in administration interfaces, and compliance with privacy regulations. The drawback is the subscription cost and reliance on an external provider.

For projects that require full control or have very low latency requirements, deploying the database on your own dedicated VPS offers maximum performance and predictable long-term costs.

When a client’s existing data infrastructure needs to be modernized—whether that involves migrating between engines, switching providers, optimizing schemas, or transitioning from SQL to NoSQL or vice versa—we treat it as a standalone project with its own audit, planning, and execution process. This is a service distinct from standard deployment, with its own methodology.

No changes are deployed to production without going through a verification process

CI/CD—continuous integration and continuous deployment—is the set of automated processes that take place between the moment a developer completes a change and the moment that change goes into production. It is not a specific tool — but a way of working that eliminates manual deployment as a source of error.

In practice, it works like this: every time a change is committed to the repository, the pipeline automatically runs a series of checks—compilation, tests, code analysis— before that change can move on to the next environment. If any of these checks fail, the change is stopped there. No code with errors makes it to staging, and no code that hasn't gone through staging makes it to production.

Every change follows the same proven path, regardless of who wrote it. The result is a predictable update process in which the risk of introducing a regression in production is systematically reduced—not through individual discipline, but by the design of the process.

What we verify before approving a deployment

Pre-launch testing isn't just a formality—it's the difference between discovering a problem before or after the user encounters it. These are the key areas we systematically cover:

Environment variables and settings. Verify that all credentials, API keys, and configuration parameters are correctly defined in production. A deployment that fails due to a missing environment variable is a preventable error that frequently occurs when this step is not performed systematically.

Database migrations. Verifying that the production schema is up to date and that existing data has been migrated without loss or corruption. In projects involving production data, this is the highest-risk step and the one that requires the most advance planning.

Verification of critical flows. The app’s main workflows—authentication, data operations, integrations with external services, payment flows—are tested in the production environment before the release is approved. Not in staging: in production, before access is granted.

Certificates and HTTPS. Verify that the SSL certificate is active and properly configured, and that all redirects from HTTP to HTTPS are working on every page of the site.

Active monitoring from the very first minute. The alert system is operational before launch, not after. If something starts to go wrong after launch, the team detects it before the user does—not the other way around.

The result of this process is a checklist that must be completed before announcing the launch. There are no “half-baked” or “almost ready” releases — It's either ready or it doesn't launch.

A launch without a fallback plan isn't ready to go

The ability to roll back a deployment in minutes is what distinguishes a minor incident from a prolonged outage. This is not an unusual scenario — is a feature that must be ready before launch, regardless of how much confidence one has in the deployment.

In serverless environments, rolling back to a previous version is instantaneous by design—the platform maintains a history of deployments, and rolling back takes just a few seconds. In environments using Docker on VPS or in the cloud, we keep images of previous versions available so they can be restored in minutes using a documented and tested process.

The database is the most sensitive part of the rollback. Reverting the code is trivial; reverting a data migration may not be, especially if writes have been made to the new schema. That is why each migration is designed alongside its reverse operation, both of which are tested in staging before deployment. If the migration proceeds, the reversal is also verified.

This level of planning is included in the DevOps retainer for production projects—not as a one-time intervention, but as an ongoing process that encompasses updates, incident management, and rollbacks throughout the entire product lifecycle.

The rollback plan is not a document that is drafted as a precaution. It's part of the deployment process and is tested before it's needed.