Product engineering
Custom software, owned from the first sketch to the production deploy.
Websites, web platforms, online stores and the internal tools a business runs on. We design them, build them, launch them and keep looking after them.
What this means
The work ranges from bespoke web platforms and web applications to content management systems a marketing team runs on its own, online stores, booking and enquiry flows, and the internal tools behind them.
One team holds the schema, the interface and the deploys. That single fact decides most of what follows: the data model gets an owner in the first week, the design is drawn against what the system can actually do, and the people choosing how it is hosted are the people who wrote it. Everything a business runs on eventually leans on that data model, so it is the first thing we settle.
In practice that means the boring decisions get made early and on purpose. What the content model actually is. What happens when a campaign multiplies traffic by twenty. Who edits this next year on their own. Those answers are cheap to change in week one and expensive in month six, which is why they come first.
We stay answerable afterwards. That is the part that changes how a thing gets built: nobody writes a deploy process they would not want to be woken up by.
Questions
What people ask first.
How does a project usually start?
With scope, not code. A short piece of work that turns what you want into what it will actually take, covering the data model, the surfaces, what has to integrate with what, and where the risk sits. You get an estimate you can hold us to, and if the shape turns out to be wrong for us, we say so then rather than three months in.
Do you work with our existing team?
Yes, and often that is the better arrangement. We have built platforms that a client's own marketing team runs day to day without us, which was the point of the work from the start. Where an internal team is going to inherit the code we build it to be inherited, and we say so in the estimate.
What stack do you build on?
There is no house stack. It gets chosen per project, from what the problem actually needs: the load it has to take, the shape of the data, what it has to integrate with, who maintains it afterwards, and how long it has to last. Working across several of them is what makes that a decision rather than a preference, and we tell you what we picked and why before anything gets built on it.
What happens after launch?
We stay on it. Most of what we have shipped is still running, and several of those platforms have taken on work nobody scoped at the start, which is the actual test of whether the first architecture was right.
Who owns the code?
It is set in the contract, project by project. Work built only for you transfers to you with the final payment. Where it builds on something we reuse across clients, you get a perpetual licence to use and change it, and the reusable part stays ours.
Can you take over software another team built?
We do. First we spend a short time with what exists, to see how it is built, where it is fragile and what it would take to change it safely. You get that picture before we commit to anything.
Do you build mobile apps?
We do, for iPhone and Android, when a website is not enough for what people need to do on their phones.