Atlas Components
A manufacturer rebuilds around product-category search intent, with a structured content model instead of a page builder.
Structure built for how buyers search
03 · Build
Web development
A business website has to do four things at once: explain what you do, be found in search, be usable by everyone, and be editable by your team without calling a developer. Most sites are built well against one of those and poorly against the rest.
We build websites as engineering projects. Semantic markup, deliberate performance budgets, accessibility built in rather than audited afterwards, and a content model that matches how your team actually works.
What we are usually called in to fix
Existing sites tend to fail in recognisable ways, and the cause is almost always a decision made early rather than sloppy work later.
- Page speed is poor and nobody can say which part is responsible.
- Publishing a straightforward page requires a developer.
- The theme and plugin stack has grown to the point that updates are risky.
- Search visibility dropped after a redesign and never recovered.
- The site works on the marketing team's laptops and badly everywhere else.
- Accessibility has become a procurement requirement and the current site cannot meet it.
What we build
The right build type is a business decision, and it is made in strategy before development starts – not defaulted to whatever we like working in.
Custom websites
Built from scratch when the site is a core commercial asset, when the design or interaction is genuinely bespoke, or when performance and accessibility requirements are strict. Maximum control, no platform ceiling, no licence dependency.
Corporate websites
Large, multi-section sites with real information architecture: service hierarchies, locations, documentation, careers, investor content, governed editorial workflows and multiple internal stakeholders.
CMS-based builds
Where a proven platform is the better commercial answer, we build on one properly. WordPress with a custom theme and structured content models – not a purchased theme with twenty plugins layered over it. Webflow where the editorial team needs visual control and the requirements fit inside it.
Headless and API-driven builds
A decoupled front end against a headless CMS or your existing services, when content is shared across several channels or when the front end has performance requirements a traditional CMS cannot meet.
Redesigns and modernisation
Rebuilding an existing site without losing what already works. Search equity, URL structure and content are treated as assets to be carried across, not collateral damage – see migration.
Landing pages and campaign sites
Focused pages for specific campaigns, built on the same component system as the main site so they stay consistent and do not become an orphaned codebase.
Diagram
How we build
The standards below are defaults on every project, not upgrades.
-
Semantic HTML first Real headings, landmarks, buttons, links and forms. This is the foundation of accessibility, of how search engines understand the page, and of a document that still works when JavaScript fails.
-
Progressive enhancement Content and navigation work before any script runs. JavaScript adds behaviour to something already functional rather than being the reason anything renders at all.
-
A performance budget, agreed in advance Targets for Core Web Vitals are set before design is finished, and design decisions are checked against them. Performance is much cheaper to hold than to recover.
-
Accessibility as an acceptance criterion Keyboard operation, focus management, contrast and labelling are tested as part of the definition of done. We build to WCAG 2.2 AA criteria.
-
A content model that matches the team Editors get structured fields with clear rules, not a blank rich-text box. It is the difference between a site that stays coherent for years and one that decays in months.
-
Handover that assumes we leave Documented build and deploy process, documented content model, documented components, and a clean repository. You should be able to hire someone else and have them productive quickly.
What you receive
- Production website, responsive across the full device range
- Source code in your repository, with a documented branch and deploy process
- CMS configured with structured content models and editorial roles
- Component library implemented and documented
- Technical SEO foundation: metadata, canonicals, structured data, sitemap, robots
- Analytics and conversion tracking configured, if in scope
- Performance and accessibility test results against the agreed targets
- Editor documentation and a training session for your team
- Post-launch monitoring window before support handover
Technology, and how we choose it
We are not loyal to a stack. The choice follows the requirements, and we will tell you what each option costs you later.
Choose custom when
The site is a core commercial asset; performance or accessibility requirements are strict; the interaction design is genuinely bespoke; or platform licensing and lock-in are a long-term concern.
Choose WordPress when
Editorial volume is high, the team already knows it, hiring for it needs to be easy, and the requirements sit inside what it does well. Built as a custom theme with structured content – not a marketplace theme.
Choose Webflow when
The marketing team needs visual control without developer involvement, the site is presentational rather than transactional, and the requirements fit within the platform's ceiling.
Choose headless when
Content is consumed by more than one front end, the front end has strict performance requirements, or the editorial and presentation teams need to move independently.
More on how we weigh these decisions on the technology page.
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Build work sits inside that process rather than alongside it.
Work involving web development
Common questions
Will we be locked into working with you?
No. The code is in your repository, the stack is mainstream, the build process is documented, and nothing depends on a proprietary tool of ours. Retaining clients by making it hard to leave produces bad work.
Can you work with our existing site rather than replacing it?
Often, yes. Where the underlying structure is sound, targeted work on performance, accessibility, templates or content modelling delivers most of the value for a fraction of a rebuild. We will say which of the two your site needs.
How do you protect our search rankings during a rebuild?
URL mapping and redirects, content parity checks, structured data parity, and pre- and post-launch crawls. It is a defined workstream, not an afterthought – see SEO-safe migration.
How long does a website project take?
A focused site, six to ten weeks. A large corporate site with multiple stakeholders and integrations, three to six months. Discovery gives you a range with the assumptions behind it before you commit.
Related services
Related reading
Planning a new site or a rebuild?
Tell us what the current site cannot do. We will tell you whether that is a build problem, a platform problem or a content problem.
Or email hello@applystudio.com – we reply within one business day.