Web development, from a marketing site to a working application

To scope the work we need to know what visitors must be able to do on the site and what your team needs to manage. Tell us the job the site has to do, in your own words, rather than a specification. Include any existing designs, the content you already have, and the systems the site must connect to, such as a CRM, a payment provider or an accounting system. We use those details to agree the page types, the functionality and the handover requirements, and we put that agreement in writing. The written scope also records what we have assumed and what is explicitly not included. If something in the brief will not work, you hear it at this stage rather than in week six. You do not need to write the specification yourself. Bring the problem and we will help write that part with you.

Usually a website with two good forms will do. Many projects that arrive described as an application turn out to be a content site with a well-built enquiry form and a way for your team to edit it. We will say so if that is the answer. It is a smaller project, and telling you that at the start is worth more to us than the difference in fee. A custom application is the right call when the site needs real accounts, permissions, an audit trail and somewhere for the data to go. Portals, dashboards, booking and quoting systems and member areas fall into that category. So does the spreadsheet that has stopped working at about thirty users. We recommend the tools that fit your requirements before you commit to a budget, and the recommendation is written down in the scope so you can check it.

Yes, in most cases we work with your existing hosting. Moving a site is a decision you make, not one we make for you, and the build does not depend on it. If the hosting is the reason the site is slow or keeps falling over, we will tell you, with the evidence, so you can decide whether to move it. The build is handed over with documented deployment instructions and the environment variables it needs, so it can run on the hosting you already have or on new hosting later. Hosting remains a separate and optional agreement after launch, in the same way as support and maintenance. If you would rather we ran it, see hosting. If you would rather keep it where it is, nothing in the code only works while we are involved.

Anything outside the written scope comes back to you as a short note with the cost and schedule impact before we build it. That way it is your decision rather than a surprise on the invoice. The scope we agree at the start records what the site does, what it does not do, and what we have assumed, so it is clear when a request falls outside it. Small changes inside the scope are simply part of the build. Work goes into your repository in reviewable pieces on a fixed check-in rhythm, with one named contact, and you can see it running on a staging URL from early on. That means changes tend to surface early, while they are still cheap to make. For applications, we would rather agree before launch how changes get requested and paid for than have that conversation for the first time when something is urgent.