Frequently Asked Questions

Websites, web apps, mobile apps, internal tools, and the systems that sit behind them. A booking screen your staff use all day. An order flow that has to talk to your accounts package. A dashboard that pulls numbers out of three places nobody wants to open. We also run what we build: hosting, cloud, backups, security and day to day support once it is live. Most clients start with one of those and add the other later. The two are quoted separately, so the price of building something never hides the cost of keeping it working.

Around the build sits the work that keeps it standing. Cloud setup and moving existing systems onto it. Security reviews. Network and access. Data work, reporting and ERP. You can take any of it on its own. A company that needs a security review does not necessarily want anybody writing software for it, and a bundle that assumes otherwise is charging you for the wrong thing. The full list, with what each one covers, is on the solutions pages.

The same handful come round again and again. A website that loads slowly and loses orders before anyone reaches checkout. An app nobody has touched in two years that now fails on new phones. Staff retyping the same data into two systems because neither talks to the other. One person who understands how it all fits together, which is fine until they are on leave. A build that stalled halfway and left you with code you cannot read and nobody to ask. And growth: what worked for ten people falls over at a hundred. None of those start as technology problems. They turn into technology work once somebody has worked out which one is costing you the most.

A call, then a written scope. We go through what you have now, what you want it to do, and what has to be true for it to be worth doing at all. You get the scope and the price before any work starts, and neither changes without you agreeing to it in writing. In the first week you see something working. Not a slide, not a mockup: a screen you can click, or one small piece of the thing running end to end. If the first thing you see is a demo at the end of month three, you have no way of knowing whether the work is going well.

You do. The code sits in your repository. The servers, the domain and the cloud accounts are in your name, and you hold the keys. That is set up on day one rather than promised for handover day, because a handover that has never been tested is a promise rather than a fact. If you decide to work with somebody else next year, you take all of it with you and nothing stops working. We also keep the notes that say why things were built the way they were, which is the part most teams lose. More on how we work is on the why us page.

Within 24 hours on a working day, on anything you send us. That is the whole promise, and we keep it by removing the places where time usually goes. Email and the support form land in one queue, so there is no second inbox to be forgotten. Requests are sorted by what has actually stopped rather than by who asked most recently. The systems we run are documented, so a request does not sit waiting for the one engineer who has seen that server before. Anything unresolved has a named route upwards, which means asking for more attention is a step rather than a favour. What to send us, and what to do if a request stops moving, is on the client support page.

Manufacturing, transport and logistics, healthcare, banks and insurance, consulting firms, non profits and fintech. What they have in common is that an hour of downtime has an obvious cost, and somebody outside the business sets the rules about the data. That changes when you are allowed to release, and how much of the work has to be written down afterwards. Knowing an industry means knowing which system is load bearing and what an auditor will ask to see. The technology underneath is much the same. Each sector has its own page under industries.