SwiftandScale

12 years building custom software

Releases that stop being an event

Your product is written. Getting a change live still takes an evening, a person and some luck. Two weeks and it takes a push — the way this site, and everything else we run, already works.

See our work

Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//Deployment & Support//

Sound familiar

Nobody plans for this, and every team arrives at it

“Only one person can deploy, and he is on holiday.”
The release process exists in a head rather than in a file. It works until the day it is needed and that head is unavailable.
“We do not deploy on Fridays.”
A sensible rule for an unsafe process, and a strange one to keep forever. What it really says is that nobody trusts what happens after the button.
“Something broke last night and we found out from a customer.”
Nothing was watching. Monitoring is the cheapest part of this whole list and the one most often postponed until after the first incident.
“The server was set up two years ago by someone who has left.”
It runs, nobody dares touch it, and it cannot be rebuilt if it dies. That is not infrastructure, it is an heirloom.

The setup

Push to deploy, in two weeks, on your own accounts

from $2,400

Fixed for the scope below, for one application and one environment. Entry pricing — this is a door into working together, not the biggest thing we sell.

Two weeks

From access granted to a release that happens because someone pushed.

What you get

A pipeline that builds, checks and deploys on every push, in your own repository
Staging and production as separate environments that are actually separate
Containerised build, so the thing tested is the thing that runs
A rollback that takes one command and has been tested at least once with you watching
Monitoring and alerts that reach a person, not a log nobody opens
Backups with a restore performed once, in front of you — an untested backup is a rumour
A runbook written against your system, and a walkthrough with whoever will own it

What is not included

A Kubernetes cluster, unless you genuinely need one — most products do not, and we will say so
Migrating between cloud providers; related work, separate quote
Round-the-clock on-call. Alerts reach you, and we answer within business hours unless you buy a retainer
Rewriting the application to make it deployable. If it needs that, we will scope it honestly first
Security auditing and compliance certification — not our trade, and you deserve someone whose it is

Every push

builds, checks and deploys this very site

products of our own run on this exact setup

1 command

to roll back, tested before handover

What gets set up

What lands in the two weeks, and what waits for a reason

Nearly every small product needs the same seven things and has three of them. This is the usual split; the real one comes out of an hour looking at how you deploy today.

Which journeys go into which stage of the work
Journey	First two weeks	Later	Not us
Build and deploy on every pushThe whole point. Everything else on this list is easier once this exists.	Covered · First two weeks	Not covered · Later	Not covered · Not us
Separate staging and productionTesting against production because there is nowhere else is the root of most Friday incidents.	Covered · First two weeks	Not covered · Later	Not covered · Not us
Rollback, tested once with youAn untested rollback is a plan, not a capability.	Covered · First two weeks	Not covered · Later	Not covered · Not us
Monitoring and alerts to a humanUptime, errors, and the two or three numbers that mean your product is actually working.	Covered · First two weeks	Not covered · Later	Not covered · Not us
Backups, with one restore performedThe restore is the deliverable. The backup on its own is a hope with a schedule.	Covered · First two weeks	Not covered · Later	Not covered · Not us
Zero-downtime releasesWorth it once traffic makes a thirty-second gap expensive. Before that it is complexity you pay for daily.	Not covered · First two weeks	Covered · Later	Not covered · Not us
Autoscaling, clusters, multi-regionReal needs at real scale, and an expensive costume before then.	Not covered · First two weeks	Covered · Later	Not covered · Not us
Penetration testing and compliance auditsA different profession. We will happily fix what such an audit finds.	Not covered · First two weeks	Not covered · Later	Covered · Not us

includednot in this stage

The right-hand column is the honest part. Most quotes in this space include everything and deliver the first four.

The cheapest infrastructure that actually works

There is a strong pull towards building for a scale you do not have. Kubernetes, service meshes, multi-region failover — all real answers to real problems, all of them a permanent tax when the product serves a few thousand people a day. Our own products, this site among them, run on containers on ordinary servers with a pipeline in front, and the whole arrangement can be understood by one person in an afternoon. That is a feature: infrastructure nobody understands is infrastructure nobody can fix at two in the morning.

What is running should be provable, not remembered

The first question in any incident is which version is live, and on most small products the answer takes an afternoon of asking around. It should take ten seconds: the image running in production carries the commit that built it, so a single command answers it. Everything downstream gets easier — you can tell whether a fix shipped, whether a rollback landed, and whether the thing you tested is the thing serving customers. It costs nothing to set up and it changes how incidents feel.

How we build the systems this runs

Alerts that mean something, and none that do not

A monitoring setup that pages you about disk usage at 71 percent trains everyone to ignore it, and the one alert that mattered arrives into that silence. We wire up a small number of things that genuinely indicate your product is broken for a customer — the site not answering, errors climbing, the queue stopping, the payment provider refusing — and deliberately leave the rest as dashboards you look at when curious. Fewer alerts, each of which means get up.

The backup is not the deliverable, the restore is

Almost every team has backups. Far fewer have ever restored one, and the gap between those two states is where companies die. We perform a restore during the setup, with you watching, into a scratch environment — and we time it, because "we have backups" and "we can be back in forty minutes" are entirely different sentences to say to a customer. If the restore turns out not to work, that is the single most valuable thing this engagement will find.

And then, if it is worth it, we stay

The setup is a fixed piece of work with an end. What follows is optional: a monthly arrangement where we watch the alerts, keep dependencies current, apply security updates and handle the release when something needs shipping. It is worth buying if your product changes regularly and there is nobody in-house whose job this is. It is not worth buying for a stable product with a competent team — we would rather say that and keep the relationship than sell a retainer that quietly does nothing.

And what we do not do

We do not recommend Kubernetes by default. Most products we see would pay for it monthly and use none of it.
We do not take root access to a machine we cannot rebuild. If it cannot be recreated from a file, that is the first thing to fix.
We do not offer 24/7 on-call as a standard package. Selling it without the people to staff it is a promise that breaks on the first bad night.
We do not do security certification. We will fix what an audit finds, but the audit is somebody else’s trade.

How it runs

Two weeks, and the first deploy happens in week one

Nothing here is a discovery phase. The first pipeline runs in the first week, because everything after it is easier once a change can reach a server by itself.

Days 1–2
We look at how you deploy today
An hour with whoever currently deploys, a look at the servers, and an honest inventory: what exists, what is undocumented, what nobody dares touch. Most of the value of this engagement is decided here.
You seeA written picture of the current setup, including the parts nobody had written down.
Days 3–5
The pipeline runs
Build, checks and a deploy to staging, triggered by a push. Containerised, so what is tested is what runs. This is where undocumented server configuration usually surfaces, which is exactly why it comes first.
You seeA push that reaches staging on its own, and the list of surprises found on the way.
Week 2, first half
Production, rollback and monitoring
Production wired the same way, a rollback performed deliberately so everyone has seen it work, and alerts pointed at a human. Backups configured and a restore actually carried out into a scratch environment.
You seeA tested rollback, a completed restore with a time attached, and alerts arriving where you want them.
Week 2, second half
Handover
Your developer deploys and rolls back while we watch and say nothing. A runbook written against your system: how to release, how to roll back, where the secrets live, what each alert means.
You seeSomeone on your side who has released and rolled back, unaided.
After
Support, only if it earns its keep
A monthly arrangement for watching alerts, keeping dependencies current and shipping releases — or nothing at all, if your team has this covered now. We will say which we think it is.
You seeA decision made on how your product actually behaves for a month.

What we work with

GitHub Actions
GitLab CI
Docker
Coolify
Traefik
PostgreSQL
Umami

What you keep

The two files that end the Friday problem

Both screenshots come from this website, which is set up exactly the way described above. Real output — the same pipeline, the same proof, the same handover.

The workflow file of this site: what runs on every push to main — The pipeline, in your repository
Readable by anyone on your team, changed like any other code, reviewed like any other change. Not a configuration hidden in someone’s dashboard, and not a script on a laptop — a file that travels with the project and can be understood by whoever inherits it.
The workflow that deploys this site.

Terminal output showing the local commit matching the container image serving the site — And the answer to “what is actually live?”
The image running in production carries the commit that built it, so the first question of any incident is answered in one command instead of an afternoon. It sounds small until the night you need it, at which point it is the difference between fixing and guessing.
Run against swiftandscale.com while this page was written.

Be honest with yourself

Cheap insurance for some teams, an unnecessary purchase for others

Buy this if

Deploying is a manual routine only one or two people know
You have no staging, or staging is "production but we are careful"
Nothing is watching the product outside working hours
You have backups but nobody has ever restored one
The person who set up the servers has left the company

Do not buy this if

You already deploy from a pipeline and have rolled back at least once on purpose
The product is a prototype with no users — set this up when it has some
You want someone to take responsibility for uptime without a retainer; that is a different arrangement
You are looking for a security audit or a compliance certificate
Your infrastructure is large and specialised enough to need a full-time platform engineer, which is a hire, not a project

If your setup is already fine, we will say so on the call and charge nothing for the hour. It happens, and telling you is cheaper for us than a project that delivers nothing you did not have.

Questions we get about deployment and support

Short answers. The long ones happen on the call.

From $2,400 for one application and one environment, fixed against the scope on this page and delivered in two weeks. More environments, several services or an application that cannot currently be containerised push it up — and we would tell you that before quoting, not during.

Almost certainly not. It solves problems that appear at a scale most products never reach, and it charges rent every month until then in complexity nobody on a small team enjoys. Containers on ordinary servers with a pipeline in front will carry a product a very long way — it is what we run ourselves.

By running the new version alongside the old one and switching over once it answers correctly. Worth setting up when a thirty-second gap costs you money or embarrassment; before then it is complexity you maintain for no benefit. We will tell you which side of that line you are on.

Watching the alerts, keeping dependencies and security updates current, handling releases, and being the people who answer when something breaks. What it does not include, unless separately agreed, is night and weekend cover — selling that without the staff to provide it is a promise that fails on the first bad night.

By default, nobody — the alert reaches you and we respond in business hours. That is the honest arrangement for a team our size, and it is what most small products actually need. If genuine round-the-clock cover matters for your product, you need a rota of several people, and we will help you scope it rather than pretend we are it.

One command, and we will perform it with you during the setup so it has been done at least once by someone who is not us. Rollback that has never been tested is a paragraph in a document; the first time you try it should not be during an incident.

Fewer things than you think. Whether the site answers, whether errors are climbing, whether the background work is still running, and whether the two or three business numbers that indicate a working product are moving. Everything else becomes a dashboard for when you are curious, not an alert that wakes someone.

Usually yes, and the first job is making it reproducible from a file rather than from memory. If the current servers cannot be rebuilt without the person who made them, that is the risk to fix first — before anything is automated on top of it.

Selected work

Both of these deploy this way, every day

Not client references — our own products, running on the setup described above, with demos you can open right now.

Two-sided marketplace app · Creator economy

Marketplaces where the money sits in the middle

A marketplace with two sides, a payment held between them, and an AI studio that bills by the generation. The hard part is never the catalogue — it is deciding, in code, the exact moment money and files change hands.

Same pipeline, with 173 end-to-end tests standing between a push and production — and money moving between two sides of the product, which is exactly the case where a tested rollback stops being a nice idea.

4 months

from kickoff to a working product

173

end-to-end tests, 24 suites

data models behind it

Live demo insideRead the case

Creator feed in the marketplace app, with an order button

Made-to-order production platform · Medical manufacturing

Operations platforms where every order is one of one

Made-to-order production has no catalogue and no reorder button. Every item is built for one person from measurements a computer takes off a scan, and the system has to hold that thread from the first appointment through manufacturing, delivery, and the remake eighteen months later.

Three repositories, each running its own suite on every push before anything deploys — 2,053 checks between them, on a runner we host ourselves. The system they protect runs a production floor, so a bad release is not a cosmetic problem: it is a shift that cannot record what it made.

8 months

and still building — the largest system we run

flow families, from intake to remake

2,053

automated checks across its three repositories

Live demo insideRead the case

Order board in the operations platform, with production stages

Every solution we build

Worth reading before you change anything

All articles →

Web development

Why two studios quote the same project three times apart

You send one brief and get back three very different numbers. The spread is not greed — it is four different readings of the same sentences, and closing it is your job as much as theirs.

7 September 20262 min read

Marketplace development

Commission, subscription or listing fee: picking how your marketplace charges

This is a business decision that quietly rewrites your software. Pick it before the build, because each answer needs a different thing to exist on day one.

6 September 20263 min read

Client portal

The portal question nobody asks until it is too late: who can see whose documents?

Access rules are the part of a client portal that breaks silently and looks normal from the inside. Here is what to specify before anyone writes code.

3 September 20263 min read

Tell us what you are building

A person reads it and answers within one business day — with a range and the assumptions under it.