A separate environment
Per application, on different hardware from the one your business runs on.
Infrastructure and deployment
Nothing reaches production without having run somewhere else first
Every application I build gets its own environment where the work happens and where you approve it, separate from the server your business runs on. What goes live has already been used, by you, on a real address.
Development
app.dev.yourcompany.comYou approve here
generated test dataNo real records
Production
app.yourcompany.comLive
your server, your accountIn your name
Separate machines. A build that goes wrong in development cannot reach the server your business depends on.
Two environmentsone to build in, one to run on
No real datadevelopment never holds your customers
Your accountsserver and domain in your name, not mine
Part of What keeps it all running
Recognise this
You need this if
- Changes go straight onto the live system, because there is nowhere else to put them.
- You find out something broke because a customer told you.
- Nobody can say what changed last, or when, or how to undo it.
- A copy of the live database sits on somebody's laptop so they can test on it.
- The server, the domain or the certificates are in a previous developer's account.
- Every update is a manual sequence, done slightly differently each time.
- The invoices and confirmations you send land in your customers' spam folders.
What this covers
The part nobody sees until it fails
This is not sold separately from the system it carries. It is how anything I build gets onto a server and stays reachable.
A hardened server
Set up once, deliberately: firewall, key access only, automatic security updates.
One repeatable release
The same steps every time, in one go, instead of a sequence someone remembers.
A way back
The previous version stays on the server, so undoing a release takes seconds.
Certificates and secrets
HTTPS renewed on its own. Passwords and keys kept out of the source code.
Backups that are tested
Off site and encrypted, with a restore actually tried, not assumed to work.
How a change reaches you
You approve it on a real address, not on a screenshot
While a system is being built or extended, you have a working copy at your own address. You open it, use it, and tell me what is wrong, before anything touches the system your business runs on.
- An address only you and I can reach, for the whole project
- Protected and kept out of search engines
- The same version you approve is the one released
- New features later go the same way, not straight to production
From an idea to your users
Builtin development
Approvedby you, on your address
Releasedto production
Initial launchSame route
A new featureSame route
An urgent fixSame route, faster
Releases
A release that can be undone
Each release is kept on the server as its own version, and the live one is a pointer to it. Going back to yesterday is a matter of moving that pointer, not of rebuilding anything under pressure.
- The application is built away from your server, so a failed build never reaches it
- Previous versions stay in place, ready to be switched back to
- Rollback is the same action every time, so it works at two in the morning
- What is running is always identifiable, down to the exact version
Releases on the server
releases/2026-02-14-1042Kept
releases/2026-02-19-0915Kept
releases/2026-02-21-1730Live now
To go back
point live at 2026-02-19-0915One step
Illustration. Version names are examples. What matters is the shape: the old version is still there when the new one is not right.
Your data
Your customers never appear in a development environment
The common shortcut is to copy the live database somewhere convenient so it can be tested on. From that moment your customers' data sits on a machine nobody protects. I do not work that way.
- Development runs on generated data, shaped like yours but not yours
- Problems that appear only in production are diagnosed from the logs first
- If a case genuinely cannot be reproduced otherwise, values are replaced before anything is copied, by a script you can read
- Anything extracted is deleted once the problem is fixed, and the fact is written down
Goes into development
Structure and relationsYes
Field names and typesYes
Generated recordsYes
Customer names and emailsNever
Addresses and phone numbersNever
Prices and agreementsNever
Free text notesNever
The server
Set up deliberately, and written down
A server that was configured by clicking around is a server nobody can rebuild. Yours is set up the same way every time, and the setup is documented well enough that another developer could repeat it.
- Only the ports that have to be open are open
- Password login disabled, keys only
- Security updates applied automatically
- Each application runs under its own account, with its own limits, so one cannot starve the others
- HTTPS from the first day, renewed without anyone remembering to
SetupState
Firewall, closed by defaultApplied
Key access onlyApplied
Automatic security updatesApplied
HTTPS and renewalApplied
Per application isolationApplied
Off site encrypted backupApplied
Restore tested on a schedulePart of the monthly plan
Ownership
Everything is in your name from the first day
The server, the domain, the email service and any external account are opened in your name, with your billing. You pay the providers directly, at their price. I do not resell hosting and I do not put a margin on it.
- You can see what you pay, and to whom
- You can move to another provider without asking me
- If we stop working together, nothing has to be transferred out of my account
- How everything fits together is written down, not kept in my head
Who holds what
Held by me
Access, while we work together
The setup documentation
Nothing you cannot revoke
In your name
Server and hosting
Domain and DNS
Email service
External accounts
Source code
How it runs
From an empty server to something your business depends on
Prepare
Accounts opened in your name, server set up, domain and certificates in place.
Build
Work happens in your development environment, on generated data, at your own address.
Release
Once you have approved it, the same version goes to production in one repeatable step.
Watch
The first period after a launch is watched closely, on real usage and real data.
A change reaches production only after you have used it
What it costs
Two things worth saying plainly
Part of the projectSetting up the infrastructure is included in building the system. It is not a separate invoice, and it is not an option you can decline, because without it there is nothing to deliver.
Providers bill youThe server, the domain and any external service are yours, at the provider's price. I do not resell them and I add nothing on top.
Keeping it running afterwards is a separate, optional monthly service. See managed hosting and security
Questions
Frequently asked questions
Where does my application actually run?
On a server rented in your name, from a provider you can see and pay directly. Which provider and how large depends on what the system does. If you already have hosting, I will tell you honestly whether it is suitable.
Do I need a second server for the development environment?
No. The development environment is provided as part of the work, at no separate cost to you, and it does not run on your production server.
Do you need access to our live data?
To operate the system, I need access to the server. To develop on it, I do not need your data, and I do not take copies of it. If a problem can only be reproduced with real structure, values are replaced first, and the extract is deleted once the fix is done.
Is my data stored inside the European Union?
Yes, unless you ask for something else. Providers and locations are chosen with you and written into the setup documentation.
What happens if a release goes wrong?
The previous version stays on the server, so the system goes back to the state it was in before, and we look at what failed afterwards rather than under pressure.
Can I move to another provider or another developer?
Yes, and nothing has to be unwound first. The accounts are already yours, the source code is yours, and how it is deployed is documented rather than improvised.
Do you use containers?
It depends on the project, and I use both. Containers earn their place when a system has several parts that have to run in known versions, or when the same setup has to be reproduced somewhere else. A single application on a server of its own often does not need that extra layer, and running it under its own restricted account gives the same isolation with less to maintain. I will tell you which one your case is, and why. Either way the setup is written down, so it can be rebuilt rather than remembered.
Our email keeps landing in spam. Is that something you fix?
Yes, and it is work I do on its own rather than only as part of a build. Deliverability, meaning whether your message lands in the inbox or in spam, comes down to the records behind your domain, SPF, DKIM and DMARC, and to the reputation that domain has built up. I set those records and repair a reputation that has already been damaged. I also run my own mail server, and client domains send their mail through it.
Who watches it once it is live?
Monitoring, backups and updates after launch are a separate monthly service. If you would rather run it yourself or hand it to your own team, everything is documented for that.
Want to know how your system would be deployed?
Tell me what you have today, and I will tell you what it would take to run it properly.