Custom web development that converts, ranks, and scales

The question comes up early. It is usually answered by whoever speaks first. A content management system wins when the site is mostly pages: services, articles, a catalogue that changes a few times a week, editors who need to publish without opening a ticket. A custom build earns its cost when the site is really an application wearing a website's clothes — pricing that depends on the customer, a configurator, a booking flow tied to stock, accounts with different permissions.

Most projects sit in the middle. The honest answer for them is a CMS carrying the pages, with custom code behind the parts that carry money. The failure mode in both directions is the same. A CMS stretched into an application collects plugins until nobody dares upgrade anything. A custom build used to publish blog posts means a developer is involved every time a comma changes.

Ask one question before deciding. In two years, who will be changing this, and how often?

A website rarely lives alone. It talks to a CRM, a payment provider, a warehouse, an email platform, sometimes an accounting system configured by someone who has left. Each of those connections is a small project with its own credentials, its own rate limits, and its own idea of what a customer record looks like.

Estimates go wrong here more often than anywhere else. The page design is visible, so it gets discussed. The integration is invisible until it fails. We ask for the list of systems at the start, then for one real export from each, because the documentation and the actual data disagree more often than anyone expects.

• which system holds the master copy of a customer record
• what happens to an order while the other side is down
• who holds the account that issues the API keys

None of those are technical questions. They are decisions about how the business runs.

A performance score is a number from a test on a machine in a data centre. Your customers are on a phone, on mobile data, in a hotel lobby. The two rarely agree.

Speed holds when it is a budget agreed before the first template: a ceiling on page weight, a limit on third-party scripts, a rule that a new marketing tag cannot arrive without an old one leaving. Without that, a site launches quick and slows over the following year. One analytics tag, one chat widget, one heat map at a time. Nobody makes a bad decision and the site still ends up slow.

We measure with field data where it exists, because it reflects the devices your audience actually holds. When a page misses the budget, the fix is usually removal rather than optimisation. The fastest script is the one that is not on the page.

A contact form is the cheapest part of a web project to build and the most expensive one to get wrong. It is usually specified last, in a single line: name, email, message, send to info@. Six months later that form is the only evidence anyone has that the site is working, and nobody can say where last Tuesday's enquiries went.

Three questions are worth settling before anyone argues about field labels. Where does a submission land besides the inbox? Who finds out when the mail server refuses it? And how long does the data sit there afterwards? A form that only sends email has no memory, so when a spam filter swallows a week of it there is nothing to recover from. The loss is invisible. No error, no bounce. Just quieter Mondays.

We store submissions on the site as well as delivering them, hand them to whatever the sales team actually opens, and add a check that notices when delivery stops instead of waiting for someone to mention it. Spam is handled without asking a customer to identify traffic lights — most of it is stopped by fields a human never sees and by timing a human never manages. Uploads get a size limit and a type limit. They land outside the web root.

The last part is not technical. Whatever is collected has to be kept for a stated reason and deleted when that reason expires, and the page has to say so in a sentence a person can read. That is a short conversation at the start of a project, and a letter from somebody's lawyer at the end of one.

One thing the single-line specification never mentions is which page the enquiry came from. A submission that arrives without it turns every marketing question into guesswork, and at build time the fix costs nothing: a hidden field carrying the URL, the campaign and the referrer, delivered alongside the message. Adding it two years later means changing the form, the delivery and the reports at once.