Web Development

• Not for you if you need it live next week. A build we would put our name on does not compress below the time it takes, and the version that does is the one you will pay to replace.
• Not for you if the content is not written and nobody has been given the job of writing it. Sites wait on words far more often than on code.
• Not for you if a template on an existing platform would do. If you need five pages and a contact form with nothing unusual behind it, say so. We will point you somewhere cheaper and tell you what it cannot do.
• Not for you if the site must run inside an old content system you cannot leave and which cannot hand its content over to anything else. That constraint decides the technology, and the answer is not this one.
• Not for you if there will be nobody to look after it. A site with moving parts falls apart faster than a simple one, and we would rather sell you something simpler than something abandoned.

Hypothetical scenario

Illustrative: a catalogue site with search

Say you sell several thousand products, and the current site takes eight seconds to show a category page on a phone. A build of this shape splits along an obvious line. Product and category pages only change when the catalogue changes, so they are produced in advance and refreshed when the source data updates. That takes the database out of the way for most visits. Search and filtering cannot be prepared in advance, so those are worked out on request, with results appearing as they are found. The chosen filters are kept in the web address, so a filtered view can be shared and can turn up in search results. Images are resized once, when the site is built, instead of being sent at full size and shrunk in the browser — usually the single biggest gain available on a catalogue. A site of this shape is six to ten weeks, and it is how much of your product data needs cleaning, not the design, that decides the schedule.

An illustration of our approach, not a delivered client project.

As a planning assumption: a marketing site of this shape is four to six weeks from approved design to launch. A content-heavy site with a system for editing it behind it runs six to nine. A web application with accounts, permissions and real data is three months and upward. The number moves with the outside services involved, and with whether existing content has to be brought across, which is frequently the largest single item.

You do, from the first day. The code sits in your company’s account, the hosting and analytics accounts are in your name, and we work as collaborators inside them. There is no handover event at the end, because nothing is being held back. If you leave, you remove our access, and everything you need is already where it should be.

You tell us, we price the change, you decide. Small adjustments inside the agreed scope are absorbed without ceremony. Anything that changes the shape of the work — a new outside service, an extra type of user, a section nobody costed — gets a written estimate before it starts. What we will not do is absorb it quietly and hand you a slipped date with no explanation.

Yes. There are two common arrangements. In the first, we build what the visitor sees while your team owns the system behind it. In the second, we take a defined set of features while your team works elsewhere in the same code. Both work, provided one person settles technical disagreements. We will ask who that is in the first conversation.

We can build the technical half. That means fast pages, clean page code, and correct titles and descriptions. It also means an address structure search engines can read, and no accidental instruction left on the live site telling Google to ignore it. Beyond that, ranking comes from content and from other sites linking to you, which is not an engineering deliverable. If someone promises you positions in exchange for a build, they are selling something they do not control.