Development
We build websites and web applications. Then we keep them running. The second part changes how we do the first.
Built to be lived with
Most web projects are built to be handed over. Ours are built to be maintained, because we are the ones who will be maintaining them.
In practice that means the boring decisions go the other way. Fewer modules rather than more. Standard approaches over clever ones. Nothing custom where something supported will do. Every project ends up in a Git repository with a deployment pipeline, because in three years somebody has to change this safely, and that somebody is us.
It is a slower way to build and a much cheaper way to own.
What we build
- New sites and applications
- From a straightforward site that has to work properly to an application with users, permissions, workflows and more than one language.
- Rebuilds
- When a site has reached the point where every change is a fight, or it is stuck on a version that is no longer supported.
- Upgrades and migrations
- Moving between major versions, or moving off a platform that is no longer the right answer.
- Work on what you already have
- Often the right answer is not a rebuild. If your site can be fixed, improved and brought up to date for a fraction of the cost, we will tell you so.
How we work
We start with what it has to do
Not with a design, and not with a platform. How much content, how many people use it, what it connects to, and who has to keep it running afterwards. The technology follows from that.
You see it while it is being built
Work goes to a staging environment you can look at whenever you want. No reveal at the end.
A small number of projects at a time
We would rather run two projects properly than six badly. It is also why we sometimes ask you to wait.
One person, all the way through
The person who scopes your project is the person who builds it and the person who answers you afterwards.
How we quote
We do not quote from a paragraph of description. Any number produced that way is either padded or wrong, and you find out which one later.
For anything beyond the small and obvious, it works like this:
You tell us what you have in mind
A conversation is enough to start. No forms, no requirements document.
A short paid discovery
We work out what is actually being built, what it has to connect to, and where the risk is.
A written scope and a fixed price
Yours to keep. If you take it to someone else, that is fine.
The discovery cost comes off the project
If you build with us, you have not paid anything extra.
What happens after launch
Every project we deliver includes a managed plan from the day it goes live: hosting, security updates, backups, monitoring, and someone who already knows how your site is built. This is not an upsell we come back to later, it is how we deliver, and it is the reason we can stand behind what we build.
We do not hand a site over and hope. If you want to run it yourself, or you have your own development team, we are probably not the right people for you, and we will say so early.
Before you get in touch
We are selective about what we take on, for a reason we are happy to explain. We commit to being responsible for the things we build, for years. That means we look for three things:
- It matters to your business
- It has a future, not just a launch date
- It is something we can host and maintain ourselves
If that describes what you have in mind, we should talk.