Variables and secrets in the wrong place
The app expects keys that only exist locally, or they have been pasted into the frontend by mistake. Deployment fails or the keys are exposed.
Service · Deployment and production
Your AI-built app runs in preview. Let's put it in production.
I set up the real environment your application needs to be online: hosting, domain, database, environment variables, repeatable deployment and basic monitoring.
The blocker
Preview is not a production environment
A demo can work with your machine's configuration and still fail the moment it goes online. These are usually the first things to break.
The database isn't ready
Migrations are missing, the user lacks permissions, or the connection still points at a test environment.
Domain, DNS or SSL
The domain doesn't resolve, the certificate doesn't cover the right URL, or the app sits behind a configuration nobody understands.
No repeatable release process
Publishing depends on manual steps and remembering what happened last time. Every change feels risky.
No logs or monitoring
When something fails, you can't see what happened. No visible errors, alerts or way to reproduce the problem.
No backups or rollback
A broken migration or deploy can leave the application with no clear recovery path.
The approach
A deployment you can repeat, not a one-off favour
Getting an app online once is relatively easy. The hard part is keeping it running when you change something, when users arrive, or when someone else has to publish.
I review how the application is built and what it actually needs. Then I set up the minimum reliable environment: production separate from testing, managed variables, a database with migrations and a documented deployment process.
If your current hosting is reasonable, I keep it. If it doesn't fit the application, I explain why before moving anything.
I don't promise zero incidents. I promise an understandable environment with fewer blind spots and a clear way to recover.
- Diagnosis of the current configuration and deployment failures.
- Production separated from development and test.
- Variables and secrets out of the code and the frontend.
- A clear command or pipeline for publishing changes.
- Logs, errors and minimum backups so operations aren't guesswork.
What's included
The pieces that turn a preview into an online service
Not every application needs the same setup. This is what I can review and configure depending on the stack and the state of the project.
01
Hosting and infrastructure
- The problem
- It isn't clear where the application should live or which plan or server it needs.
- What I do
- I choose and configure hosting that fits the stack: Vercel, Netlify, Railway, Render, DigitalOcean or a Docker/Nginx server.
- What changes
- The application runs in an environment built for production.
02
Domain, DNS and certificates
- The problem
- The domain points to the wrong place or SSL fails on some routes.
- What I do
- I configure DNS, domains and certificates, including redirects and the www versus root-domain decision.
- What changes
- A reachable, consistent URL over HTTPS.
03
Variables, secrets and configuration
- The problem
- Keys live locally, in the repository or exposed in the frontend.
- What I do
- I separate configuration by environment, move secrets where they belong and check what is being sent to the browser.
- What changes
- Less risk of leaked keys and fewer configuration failures.
04
Production database
- The problem
- The app uses a local database or an instance shared with testing.
- What I do
- I configure the database, permissions, migrations, backups and a verified restore path.
- What changes
- Separated data and a way to recover if something goes wrong.
05
CI/CD and releases
- The problem
- Every deploy is manual and depends on remembering the right order.
- What I do
- I set up a repeatable flow with GitHub Actions or another pipeline, with checks before publishing.
- What changes
- Publishing stops being a risky operation.
06
Logs, errors and monitoring
- The problem
- There is no visibility when the application fails in production.
- What I do
- I configure error logging, uptime checks and basic alerts.
- What changes
- You hear about problems before users report them.
Who it's for
Projects that usually need deployment done properly
If the application already has shape but isn't online, or is online in a fragile way, this service fits.
Apps that only live locally
The project is on your computer and you need a real URL to show or use it.
Projects built in an app builder
Lovable, Bolt, Replit or v0 gave you a preview, but you need your own environment and domain.
Apps already online but unstable
It works, but every change is a risk and there is no clear recovery process.
Teams without a DevOps profile
The product team knows what to build, but nobody wants to touch infrastructure.
How it works
From diagnosis to an environment you can maintain
The goal isn't just to make the app start. It's for you or your team to publish changes without depending on me.
- 01
I review the app and setup
Stack, build, variables, database and current domain state.
- 02
I identify production blockers
I separate what prevents launch from what can wait.
- 03
I configure the environment
Hosting, data, secrets, domain, HTTPS and deployment.
- 04
I test the full flow
Deploy, check critical routes and verify rollback works.
- 05
I document and hand over
How to deploy, where logs live and what to check if something fails.
Frequently asked questions
Common questions before deploying
Can you deploy an app built with Lovable, Bolt or Replit?
Yes, if I can access or export the code. I review which stack the tool generated and whether the project can run outside the builder with the right credentials and services.
My application works locally. What is usually missing for production?
Usually environment variables, a reachable database, a correct build, domain and HTTPS, permissions, logs and a deployment process. The specific diagnosis depends on the app.
Can you configure my domain and SSL certificate?
Yes. I configure DNS, redirects, www versus root domain and HTTPS, provided you have access to the registrar or the relevant account.
Do I have to change hosting?
Not necessarily. If the current hosting fits the application and can be operated reliably, I keep it. If not, I explain the limitation and the alternatives.
Do you set up CI/CD?
Yes, when it adds value to the project. It can be a GitHub Actions pipeline or another automated flow, with checks before publishing.
Do you handle the production database?
I can configure it, review permissions, prepare migrations and leave a backup and restore procedure. I'm not a dedicated DBA for very large systems, but I cover the usual ground for a business application.
What happens if the deployment breaks later?
I leave documentation and a recovery path. If we keep working together, I can handle maintenance; if not, your team will have the context needed to operate it.
Do you work with companies outside Spain?
Yes. I work remotely with companies in Spain, the EU and the United States, in Spanish or English.
Contact
Tell me where your app lives and what happens when you deploy
With the URL, repository or a description of the error I can get a useful picture of the starting point.
What helps to include
- Which stack or builder you used.
- Where it runs now and where it fails.
- The error message, if you have it.
- Whether you have a domain, hosting or repository.
- What you need: launch, move hosting or stabilise what exists.
Don't send passwords or keys in the form. Access is shared through a secure channel once the work is agreed.
Related help
Other blockers I can help with
Related service
AI-built apps to production
The full picture: rescue, deployment, data, audit and maintenance from one starting point.
Related service
ERP and CRM data migration
Mapping, cleaning and validation to move your company history into a custom application.
Related service
Code audit and maintenance
Code, permissions, performance and tests reviewed; ongoing maintenance after launch.