Deployment · environments
It works in preview and breaks in production
Or the build has been red for two days and the error means nothing to you. Both are the same category of problem: something is different between the place the code was written and the place it runs, and nobody wrote down what. Usually it is one variable, one dependency, or one function that has no secret where it is now.
Paste the full error when you write to us. Nine times out of ten it names the cause, and you will hear that before anything is agreed.
- First step
- A short call, or a written description if you would rather not talk yet
- Who you speak to
- The engineer who would do the work. No account manager, no sales call.
- Turnaround
- Most single problems are resolved within 48 hours of getting access
- Cost
- Quoted after we have seen it — scope varies, and guessing helps neither of us
How to get this fixed
Already a client? Raise it as a ticket in Golux Club and it enters the queue with an SLA attached.
The usual differences
Environment variables lead: the value exists in the preview environment and not in production, or it was named with a client-visible prefix so it is inlined at build time and changing it at runtime does nothing. Edge functions come second — they run somewhere with no access to your project's secrets unless those secrets are explicitly set for them, so the function that worked locally returns 500 in production with a message it never logs. Then build-time type and import errors that the preview tolerated. Then a third-party service whose allow-list has the preview URL on it and not the real one.
How to tell it is this
- `undefined is not a function` or a missing key, only in production
- An edge function returns 500 with no useful body and nothing in the logs
- The build fails on a type error in a file nobody edited
- A feature works for you and not for users, and both are on the same version
What we do
Find the difference, close it, then make it visible next time.
- 01
Read the real error
The build log or the function log, not the message the UI shows. That is often the whole job — the cause is usually in a line nobody scrolled to.
- 02
Diff the environments
Every variable, every secret, every allow-list, preview against production. The missing one is the bug.
- 03
Fix it and deploy it
The change, the deploy, and the feature confirmed working on the live URL rather than assumed.
- 04
Make the next one loud
Error tracking wired up, so the next production-only failure sends you a message instead of waiting for a customer to complain.
What you get
- A green build and the feature working in production
- The environment difference written down, both sides
- Error tracking connected, with the first alert tested
- A short note on what to check first the next time it goes red
When this is not what you need
- Every deploy is a gamble and you have no staging — that is a practice problem; the sprint sets it up properly
- The build fails because the app has outgrown the builder — we will tell you that honestly rather than sell you a fix that lasts a week
- You want CI, tests and review gates — worth having, bigger than one fix
How it works
- 01
Tell us the symptom
One paragraph is enough — the error, the screen, what you expected. Run the free audit first if you have not; it often names the problem for you.
- 02
A call, or a written reply
Thirty minutes to look at it together, or a written answer if you prefer. Either way you find out what it is before anything is agreed.
- 03
A written offer
After the call: the scope, the approach and what we need from you. Discussed on the call, confirmed in writing.
- 04
Fixed, explained, handed back
The fix in your project, a short note on what was wrong and why, and how to check it yourself — typically inside 48 hours of getting access.
What we promise before any money changes hands
We tell you what is actually wrong, whether it is one problem or a symptom of a bigger one, and what it would take — before you commit to anything. If the honest answer is that you can fix it yourself in an afternoon, that is the answer you get, and the instructions are usually on this page already.
Questions
- I have no idea what the error means. Is that a problem?
- No. Send it as it appears — the whole thing, not a summary. Reading errors is most of what this work is.
- Can you fix it without touching production?
- We diagnose against a copy wherever possible and deploy when you approve. For a build that is already broken there is nothing to protect — the deploy is the test.
- The app worked yesterday and nothing changed.
- Something changed: a dependency published a new version, a certificate rotated, a provider changed a default, a key expired. 'Nothing changed' narrows it usefully rather than being a dead end.
- Do you fix Vercel and Netlify deploys too?
- Yes — and Supabase edge functions, Docker, and a plain server. Same price.
Next step
Tell us the symptom. We will tell you if it is one problem.
We answer within a few hours with what it is, what it would take, and what we need from you. If it is bigger than one problem, we say that instead — before anything is agreed.
