Websites your team can change after we hand them over
A site is easy to build and hard to live with. We work out which parts you will edit every week and which you will never touch, and build accordingly.
- A site your team can edit without raising a ticket
- A stack another developer could pick up
- Page structures built around your real content
- Speed built in rather than patched on afterwards
Platforms we work in
How we approach it
A site you could take elsewhere
Some agencies build on tooling only they can maintain, which turns a client into a hostage. We would rather you stayed because the work is good than because leaving is expensive.
The expensive decisions are the early ones
Changing how content is modelled after launch means migrating everything built on top of it. Getting the page types right in the first week is worth more than any visual decision made in the sixth.
Fewer moving parts
Every plugin, integration and clever animation is something that can break while you are asleep. Most sites are carrying far more of them than they need.
How we work
Work out what changes, and how often
That answer picks the platform, so it comes before the platform does.
Structure the content
Page types, fields and relationships. This is the part that is cheap now and expensive later.
Design against real content
Layouts built around your actual copy and images, not placeholder text that always fits.
Build and check it properly
On real devices, on a slow connection, and with the content actually in it.
Hand it over
Access, a written record of how it is put together, and a walkthrough with whoever will be editing it.
What is inside this service
- Structure before design
- Built on what you can hire for
- Editing that does not need us
- Fast because of how it is built
- Checked on the screens people use
- Ecommerce where it applies
What each part does
- Structure before design
- What the pages are and how they relate to each other, settled before anyone opens a design tool.
- Built on what you can hire for
- A stack the next developer will recognise, rather than one that makes leaving us expensive.
- Editing that does not need us
- Content models your team can use without understanding how the site is built underneath.
- Fast because of how it is built
- Speed comes from structure and images. A caching plugin added at the end is a patch over the problem.
- Checked on the screens people use
- Real devices and real connections, not a desktop browser made narrow.
- Ecommerce where it applies
- Shopify or WordPress, chosen on what you sell and how you fulfil it.
What it changes for you
Editable by your team
Content models built for the people who will actually use them.
Fast without a plugin
Speed from structure and images, which does not decay the way a bolt-on does.
Nothing exotic to maintain
A stack another developer can read without being introduced to it.
Works on what people use
Checked on real devices rather than resized in a browser.
Businesses we work with
Questions we get asked
It follows from who edits the site and how often. WordPress suits a marketing team publishing regularly. Shopify suits selling physical products without wanting to think about the plumbing. Custom is worth it when the site does something specific to your business, and it is the wrong answer when it is chosen for the sake of it.
That depends on how the content is modelled, which is why it comes early. If an editor can only change a page by editing layout, they will eventually break the layout. If the fields are shaped around what they actually need to change, they cannot.
It stays up and untouched. The new site is built separately and only replaces it at cutover, which is also when redirects from the old URLs go in. Skipping those is how a rebuild loses traffic it took years to earn.
Usually not. Slowness is more often images, third-party scripts and a stack of plugins than it is the underlying build. We would rather find out which it is and tell you the site is fixable than sell you a rebuild you did not need.
Fewer plugins is the real answer, and it is one of the reasons we argue for fewer. Beyond that: updates get applied somewhere that is not your live site first, so a breakage happens on a copy rather than in front of a customer.