Web design and development services are rarely hard in a technical sense. What decides whether a site is a good investment is a handful of choices made before anyone writes code, and they are expensive to change afterwards. These are the ones we see go wrong most often.
What matters most
- Decide first whether you are building a website or a web application. The two share almost nothing beyond the browser.
- Choose the CMS around whoever edits the content weekly, not around what developers prefer.
- Speed is not a final optimisation. It is a consequence of what you pick at the start.
- Integrations are the line item that most often doubles an estimate.
- Budget for operations from day one: updates, backups, monitoring and somebody who responds.
- Accessibility is both a legal requirement and free SEO. It is cheapest built in from the start.
Website or web application?
A website communicates. Content changes more often than functionality, the editors are not developers, and success is measured in visitors who do something. Here the CMS and the editing experience are the important choices.
A web application does work. Users are usually signed in, data matters more than layout, and success is measured in tasks completed. Here the data model, permissions and integrations matter more than the design system.
Most projects that run off the rails are applications that were estimated as websites.
Choosing the platform
The question is not which CMS is best, but who uses it every week. If marketing needs to build landing pages unaided, a flexible editor outweighs technical elegance. If the content will barely change, a simpler setup is cheaper to run.
Whatever you choose, make sure the content can leave. If you cannot export your pages and images in an open format, you are more tied to the platform than you think.
Speed is a decision, not a setting
Most slow sites are not slow for want of caching. They are slow because of a heavy theme, ten plugins each loading their own CSS and JavaScript, and full-resolution images.
Four things move the needle: fewer plugins, images in modern formats at the right size, server-side caching, and loading only the JavaScript a page actually uses. Choosing well at the start costs far less than optimising your way out later.
Integrations and the parts nobody sees
Forms that must land in a CRM. Prices that come from an ERP. Login against an existing user system. Each is a small project with its own failure modes, and each is usually described in one line of a proposal.
Ask specifically what happens when the other system is down. The answer decides whether you get an integration or a source of errors. That work belongs under API development and should be estimated separately.
Operations, security and accessibility
A web build is never finished. It needs updating, backing up, monitoring, and someone to respond when it breaks. Agree who does that and how quickly before launch, not after the first outage. That is what software maintenance covers.
Accessibility is both a requirement for many companies and an advantage in search. Contrast, keyboard navigation, alt text and a correct heading structure cost almost nothing when built in, and are expensive to retrofit.
How we work
We build both websites and web applications as part of our web development services. If it is an application with logins and data it usually sits under application development, and if it also needs to work as an app we look at mobile development alongside it. If you only need help with the interface, you can hire frontend developers.
Frequently asked questions
The range is wide because content and integrations weigh more than design. A ten-page presentation site with a form is a different project from one with customer logins and an ERP integration. Get the two separated in the proposal so you can compare like with like.
Six to ten weeks for an ordinary company site once the content is ready. Content is almost always what delays it, not development.
If you have more than one site, or plan several campaign pages, it pays for itself quickly. For a single site it is usually overkill.
You should be able to edit text, images and pages unaided. Structural changes still need a developer. Ask to try the editing experience before you approve the design, not after.
In practice
Establish whether you are building a site or an application, choose the platform around your editors, estimate integrations separately, and agree operations before launch. Those four decisions settle most of the budget.
Want us to look at your project? Get in touch.
