Clarity before we build

Most websites run 3-8 weeks. Web apps and internal systems are usually 8-20 weeks depending on complexity, approvals, and integrations.

A website is primarily a marketing and information layer. A web app is product software people log into to complete tasks and workflows.

Yes. We stay involved for updates, fixes, and ongoing improvements so performance stays strong as your business evolves.

We monitor stability, resolve snags quickly, and run through a clear handover process so priorities, ownership, and next steps are all explicit.

Yes. Ongoing maintenance is part of how we work, including technical support, iteration planning, and delivery of follow-on improvements.

Errors are reported automatically rather than waiting for someone to notice and tell us. Every project we run has error monitoring wired into both the browser and the server, so a fault that affects real people surfaces as an alert rather than as a complaint days later.

The price depends on the written scope. A website, an app and an internal system are different pieces of work, and integrations, user roles and payment flows can change the size of any of them. We talk through the problem first, then agree the deliverables, build price, timeline and any optional ongoing support in writing before work starts.

The build fee buys the software. If you want us to keep running it afterwards, a separate monthly agreement covers hosting, monitoring, maintenance and agreed updates. That ongoing support is scoped plainly rather than being hidden inside the build price, and ownership does not depend on keeping it.

Yes, and it is often the sensible thing to do. A first phase that solves one real problem tells you more about working with us than any amount of discussion, and it means the bigger decision is made with evidence rather than optimism.

No. You need to know the problem, not the solution. Turning up with a rough idea and a real frustration is a better starting point than a specification written to guess what a developer wants to hear.

One conversation, and access to whoever actually understands the problem. Not a document. The most useful first meeting is usually with the person who currently works around the thing that is broken.

Yes, and you do not have to ask. We treat client work as confidential by default, and we are happy to put that in writing before you share anything.

Usually. Most businesses are not starting from nothing, they are starting from a spreadsheet, a subscription tool or two and a process that lives in someone's head. We build one system around how you work to replace that patchwork, and it works with the accounts package and card payments you keep.

You do, once the build has been paid for in full. That is what the build fee buys. In day to day running we keep hold of it and operate it for you, because that is what the retainer pays for and because a folder of source code is not much use to most people. Owning it and having to look after it are two different things. Ask for a copy whenever you want one and you will get it. Third-party frameworks and services keep their own licences, as they would with anyone.

No. The build fee bought the software; the retainer pays for hosting, maintenance, security and updates. Ending one does not undo the other. If a retainer ends you get a complete export of your source files, content and assets within 14 days, what you reasonably need to host it elsewhere, and 30 days still live so there is time to move it or find someone else to run it.

Yes, without qualification. Content and business data you put into software we run for you stays yours, and you can ask us to export it in a common, usable format at any time, including when you leave. We will not hold your data hostage.

We do, for as long as a support, hosting or retainer plan is running. That is deliberately separate from ownership: owning the deliverables does not include hosting, deployment, monitoring, security patching or updates, so you are never paying twice for the same thing or wondering which of us is watching it.

Lancashire, working remotely with clients across the UK. In practice it matters less than how quickly you get an answer when something needs deciding, which is the thing worth judging us on.

Automated checks run against every change, and they block the release rather than warn about it. They cover the build itself, the copy shown to users, whether text is squeezed or overflowing at any screen size, and the weight of media on the page. The services page shows which checks run and what they reported on this site.

It is checked at phone width as a matter of course, not as an afterthought once the desktop version is signed off. Layout and text wrapping are verified at small sizes on every change, because that is where most of your visitors are.

Ours. You should be reviewing whether it does the right thing for your business, not finding broken links and error messages. If you are the one discovering faults, we have not finished.