Many software projects start with an infrastructure question: "where will this run?" As if that were a foundation that has to be poured first, and as if the answer should steer the build. The misconception is that the hosting choice is an early, expensive decision. With software that is delivered declaratively it is a late and cheap one: the application describes how it should run, and where that happens is an instantiation of that description.
The description is the product
Declarative delivery means the application's environment — dependencies, configuration, build-up — lives as a description inside the project. Deploying is executing that description, by a human or by a machine. It is the same property that keeps day one on a project short, seen from the other side: what a new developer builds locally with one command, a server builds the same way. Containers and orchestration are the obvious form and are never far away with us, but they are one way of executing the description, not the reason for it.
Three outcomes, one project
With that description in place, these are not three projects but three executions:
- SaaS with us — we run the application on our own infrastructure, with error tracking, monitoring and updates included.
- On-premises with you — you say "we have this and this", and the application lands in your environment. No special thrown-over-the-fence edition; the same artefacts, the same description.
- A bare machine — a web server, a runtime and the described steps. Not every application deserves an orchestration platform, and a small internal system is perfectly served by a single machine.
The bare-metal route is not a fallback for when it has to be, but an equivalent outcome. The point is never the tool; the point is that the route is described and repeatable.
Why this is cheaper
The effort goes into the project once, instead of into every deployment. Standing up a new environment is not days of copying and trying, but executing something that already exists and is already proven daily. That is efficient for us and therefore cheaper for you — and it carries through to everything around it: a test or acceptance environment is the same description once more, and whoever wants to move house one day moves a description instead of a pile of handiwork.
There is an honesty argument in it too. An application that only runs where its builder put it ties you to that builder. An application that describes its own environment is one you can take with you. We build the second kind, knowing that a supplier who is easy to leave is one you can stay with.
From our own kitchen
This is also how our own software lives, this website included: every change is a commit, and the deployment follows the description in the project — automatically, without anyone "quickly going into the server". How that pipeline works, and why a release therefore stops being an event, is a story of its own.
The question at the right moment
With us, "where will this run?" comes at the end of the conversation, once it is clear what runs and for whom. Want to have software built without committing to an environment on day one, or do you have an application that currently only runs where it happens to sit: get in touch or request a proposal.