blog

Someone on your team asks for a small thing. A page that reads two APIs and shows which orders are stuck. You point an agent at it and an hour later it works on your machine. Then you spend four days getting it in front of the one person who asked, and about half way through you start wondering whether it was worth it.

What the four days are actually made of

None of it is the software. The software was finished on day one. The rest is the bill for making a thing that runs on your machine into a thing that runs somewhere else, and it itemises about the same way every time.

• A container, or a buildpack, or a runtime version pinned somewhere. Something has to describe the machine your laptop already was.
• Somewhere to put it, which means an account, a project, a region and a bill.
• The secrets again. They were environment variables in a file you never committed, and now they have to exist in a second place that is not your laptop.
• The data. It read from a local database with a few rows you had seeded by hand. That database is not coming with it.
• A URL, which means DNS, which means a certificate.
• Some way to stop the whole internet opening it, which is the step that quietly turns a two-day job into a four-day one.

Every item is reasonable. Together they are a deployment, and a deployment is a fixed cost. It does not get smaller because the thing you are deploying is small.

The bill did not move when writing got cheap

This is the part that changed recently, and it changed in one direction only. Writing the code got dramatically cheaper. Putting it in front of a person did not move at all.

So the ratio inverted. The order dashboard used to be two weeks of work and two days of deployment, and nobody argued about the two days. Now it is an hour of work and two days of deployment, and the deployment is the project. That is a bad trade for anything only a handful of people will ever open, which is most of what gets built inside a company.

What people do instead

Faced with that bill for a tool three people need, most of us pick one of four things, and all four are worse than they look.

• Send a screenshot. The person cannot use it, so they keep asking you to run it.
• Run it for them on request, which makes you the tool.
• Deploy it properly, which is the four days, for something that may be abandoned in a fortnight.
• Do nothing, which is the most common answer and the reason a lot of useful internal software is never built at all.

The other way round

Almost all of that bill exists because the software was built somewhere private and has to be moved somewhere public. If the agent that wrote it can put it somewhere public itself, most of the list stops applying. There is nothing to describe, because nobody else has to run it. Nothing to move, because the files go straight from the conversation to the place they are served from.

On reachpad that is one call. The agent hands over the files and gets a link back.

• create_app takes a name and the files and answers with the app’s link.
• Anyone signed in at your company can open that link. Named people only, or anyone who has the URL, are the other two settings.
• No clone, no install, and no account on your machine.

Then they ask for a change

They always do, and this is the half of the story that gets left out. The first version is rarely the one people keep, so the interesting question is not how you shared it, it is what the second version costs.

The app’s link points at whichever version is live, not at a copy of what was running when you sent it. Publish again and the same link serves the change, so the person you sent it to keeps the address you gave them. The version they were looking at keeps a link of its own, which is how you show somebody what it used to do without putting it back.

When to pay the four days anyway

Some software should be deployed properly, and pretending otherwise would be a disservice. If it takes payments, if it holds data you would have to disclose losing, if people outside your company touch it, or if it needs to stay up while you change it, then the bill at the top of this page is not overhead. It is the job.

The argument here is narrower: that bill should not be the price of finding out whether an idea was any good, and for a tool three people use it very often is.

Publishing an app is the call your agent makes and what it answers with, and versions and their links covers what each link keeps serving after the next publish.