For agencies and freelancers

You built it. We’ll put it where the client wants it.

Your client wants the app off the vendor and onto infrastructure they own. You would rather not spend a week on Docker, Postgres and TLS to find out how it goes. We do that part, as your subcontractor, and disappear afterwards.

Why this arrangement

Built for the person who has to answer for it.

01

The client stays yours

We do not contact them, we do not brand anything, and we do not follow up afterwards. If you want us on a call we join as your team. If you would rather we never appear, we never appear.

02

A fixed number you can quote on

You get a price before you commit to your client, so you can mark it up and quote with confidence instead of guessing at infrastructure work you would rather not own.

03

A scope document in your name

We write the plan — what moves, what does not, acceptance criteria — and you send it on as your own. It closes the deal and it prevents the argument at handover.

04

Reviewed before it reaches you

One engineer does the work, a second checks it before handover. Your reputation is on the line and ours is not visible, which is exactly the wrong way round unless we take the review seriously.

The situation this solves

An AI platform got the app built in days instead of months. That part worked, and it is why you used it. Then the client asks a reasonable question — can we host this ourselves, can we have the database, can we point our own domain at it — and the answer involves containers, a database, a reverse proxy, certificates and a deploy pipeline.

That is a different discipline from building the app, and it is a poor use of a week if you only do it twice a year. Meanwhile saying no to the client is not really an option, because the question is legitimate.

Subcontracting infrastructure is normal. Losing the client to your subcontractor is not, and it is the reason most people do not.

What we will not do

Worth stating plainly, because it is the actual objection and everything else depends on it.

If you want to introduce us as your infrastructure team, that is fine too. Your call, not ours.

How it runs

Five steps, and you are on the client side of all of them.

01

You brief us

What the app is, where it runs, what the client is asking for. A repository link if you have one. Fifteen minutes.

02

We scope it

A written plan with a fixed price, usually within one business day — or an honest "this is a rebuild, not a migration" if that is the truth.

03

You quote your client

At whatever number works for you. What you charge is not our business and we never see it.

04

We do the work

About a day, once credentials exist. We report to you, not to them.

05

You hand it over

Running app, written handover, deploy pipeline. Delivered by you, to your client.

Terms
$600per migration · what you charge is yours

A standard single-app migration: front end, backend logic, one database, auth, file storage, domain. Larger jobs get scoped and quoted before you commit to anything.

Bring us repeat work and we will talk terms. We would rather build one steady relationship than chase twenty one-off jobs — and so, we assume, would you.

Ongoing maintenance is available at $40–60 a month, billed to you, resold by you — or declined entirely. Also your call.
Get a quote

Send us one to scope

Tell us what your client built and what they are asking for. You get a written plan and a fixed price, usually within one business day — including an honest no if it is a rebuild rather than a migration.

No newsletter, no automated sequence. Your details are used to answer you and nothing else.