Get in Touch
Web Development Scope Method Coverage Accessibility FAQ
Scope Method Coverage Accessibility FAQ
About Us
AI Solutions overview AI Consulting Services AI Strategy and Readiness Enterprise AI Implementation Generative AI Consulting Agentic AI Consulting AI Automation AI Integration
Oracle Services overview Oracle Fusion Cloud Oracle Fusion Financials Oracle Fusion HCM Oracle Fusion SCM Oracle Fusion Project Oracle Sales Cloud Oracle EPM Planning and Budgeting Oracle Hyperion Financial Accounting Hub Oracle BI Integration Oracle Technology Oracle SOA Suite Oracle DBA Oracle APEX Oracle OIC Oracle VBCS Oracle E-Business Suite EBS Upgrade and Support EBS Migration to Cloud Oracle NetSuite NetSuite SuiteScript NetSuite CRM NetSuite Supply Chain, Inventory & Manufacturing NetSuite HCM NetSuite Analytics & AI
Salesforce overview Salesforce Implementation Salesforce Integration Salesforce Managed Services Agentforce and Salesforce AI Salesforce Migration
Microsoft Enterprise Services overview Microsoft Dynamics 365 F&O Microsoft Business Central Microsoft Power BI The .NET Framework
Application Management overview Java Development Mobility Solutions Android App Development React Native Xamarin Universal Windows Platform Automation Testing Services Katalon Selenium DevOps Web Development LAMP Stack MEAN Stack E-commerce Solutions Enterprise E-commerce
Managed IT Services overview Infrastructure Monitoring Network Support End User Support System Support Managed Cloud Services Managed Security Services
Managed Business Services overview Logistics BPO Services Finance and Accounting Services Healthcare BPO Services Mortgage Loan Processing Order Processing
AtomicRoute Enterprise AI Atomic HR
Manufacturing Government and Non-profit IT Services and Networks Education Real Estate Media Logistics Pharmaceutical
Insights Newsroom Gallery Why AtomicNorth Get in Touch

Sites your own team
can still edit

Customer-facing and internal web applications, built for accessibility and performance, with a content editing workflow the people who own the words can actually use.

Content editing is designed with the people who will do it, because a site only its developers can change becomes a site nobody changes.

Get in touch See the delivery method
ScopePublic and internal

Marketing sites, customer portals and the line-of-business tools staff use all day.

StandardWCAG 2.1 AA

Designed against it and reviewed by keyboard and screen reader, not only by an automated scan.

PerformanceMeasured on real devices

Tested on mid-range hardware and constrained connections rather than on a developer's laptop.

EditingOwned by your team

Structured content models so a page change is an editor's task, not a deployment.

What we build

Web applications and the sites around them

Web work splits into two jobs that get confused. One is an application with logic, state and integrations. The other is content that has to be changed by people who do not write code. Building the second like the first is why so many sites go stale.

Customer portals and applications

Accounts, self-service, ordering, document access and payments, integrated into the systems that already hold the data.

The authentication and account recovery paths get designed properly, because those are where a portal actually loses people and they are usually treated as plumbing.

A portal that reduces calls rather than generating them.

Internal line-of-business tools

The web applications staff use all day, replacing the spreadsheets and shared mailboxes that a process has quietly grown into.

Speed for a repetitive task matters more than visual polish. Keyboard use, sensible defaults and bulk actions come before anything decorative.

Tools the people using them stop complaining about.

Content-managed sites

Structured content models in a headless or traditional CMS, with editing roles, preview and publishing workflow set up around your actual approval chain.

Content types are modelled rather than left as free-form pages, so a redesign later does not mean rewriting every page by hand.

A site the marketing team updates without raising a ticket.

Accessibility

WCAG 2.1 AA as a design constraint from the first wireframe: semantic markup, focus order, contrast, labelling and error handling.

Automated checks run in the pipeline and manual keyboard and screen reader review happens per release, because the automated pass catches only part of it.

A site that works without a mouse and with a screen reader.

Performance

Payload budgets, image handling, caching strategy, server rendering where it helps, and measurement on mid-range devices and slow connections.

Performance is a budget agreed at the start and checked in the pipeline. Treated as a phase near launch, it becomes a rebuild instead.

Pages that load acceptably on an ordinary phone.

Replacing a site nobody can update

Content audited and migrated, the abandoned platform assessed, and the new build shaped around who will maintain it rather than around what looks impressive.

The audit usually shortens the site considerably. Migrating pages nobody has read in years is paid-for work with no reader at the end.

A smaller site that is current, rather than a large stale one.

How a web engagement runs

StepOneAudit

What is there and who it is for: the content inventory, the analytics, the tasks people arrive to complete, and what currently blocks them.

Rebuilds commissioned on how a site looks tend to reproduce its structural problems in a new skin.

You receive:

An audit and content inventory

Every page with an owner, a purpose and a keep, rewrite or delete decision, plus the accessibility and performance position as it stands.

Yours to keep, and enough on its own to justify deleting a good deal of the site.

StepTwoModel

Content types, fields and relationships, plus the editing roles, approval chain and preview behaviour your team will actually work through.

Modelled with the editors in the room. A content model designed without them produces a system that is technically correct and unusable.

You receive:

A content model and editing plan

Content types with fields and relationships defined, editor roles and permissions, publishing workflow, and the migration mapping from the old site.

Signed off by the people who will maintain the content, not only by the project sponsor.

StepThreeBuild

Iterative delivery on a real URL your team can see, with accessibility checks and performance budgets enforced in the pipeline from the first build.

Editors get access early and load real content. That is how content model problems surface while they are still cheap to change.

You receive:

A working site in stages

Deployed increments on a real environment, automated accessibility and performance checks as pipeline gates, and manual keyboard and screen reader review per release.

No launch date is fixed until content is loaded, redirects are mapped and a manual accessibility review has been completed.

StepFourHand over

Editor training against the real workflow, documentation written for the people doing the work, then support for the platform underneath.

The measure of a handover is whether content changes happen after the project team leaves. Most sites go stale because nobody was trained properly.

You receive:

An editing team and a support line

Editors trained and publishing on their own, documented workflow, and platform maintenance covering dependency and security updates.

Accessibility and performance rechecked after significant content changes, because both regress through content as much as through code.

01
Coverage

What sits in the web practice

Delivered as a project, or as a project followed by a retainer covering platform maintenance, security updates and ongoing changes.

Web Development coverage
AreaTechnologyScopeModel
Front end React, Next.js, TypeScript, plain HTML and CSSInterface build, component library, responsive and accessible markupProject or retainer
Back end Java, .NET, Node, PythonAPIs, business logic, authentication, integration into existing systemsProject or retainer
Content management Headless and traditional CMS platformsContent modelling, editor roles, publishing workflow, migrationProject or retainer
Accessibility WCAG 2.1 AADesign review, pipeline checks, manual keyboard and screen reader reviewProject or retainer
Performance Payload budgets, caching, image handlingBudgets set and enforced, measurement on representative devicesProject or retainer
Search and analytics Site search, tagging, consent managementSearch configuration, event tracking, consent handlingProject
Maintenance Existing sites and applicationsDependency and security updates, content support, small changesRetainer
Accessibility

An automated scan is not an accessibility review

Automated tooling catches a genuine share of accessibility problems and reports cleanly on a site that is still unusable. It cannot tell you whether focus order makes sense, whether an error message explains what to do, whether a custom component announces its state, or whether a form can be completed without sight.

So the automated checks run as a pipeline gate and a person reviews the site by keyboard and with a screen reader before each release. It is slower and it is the only version of this claim that holds up when a real user arrives, or when someone asks for evidence.

Ask for an accessibility review
  • Designed inSemantic structure, focus order, contrast and labelling handled in the designs and the markup rather than patched afterwards.
  • Checked automaticallyAccessibility rules run as a pipeline gate, so a regression fails the build instead of reaching a release.
  • Reviewed by a personKeyboard-only and screen reader review per release, covering the flows that matter rather than a sample of pages.

Applies to sites we build, and it is the standard we assess an existing site against.

Questions we get asked

Before rebuilding the site

Our site is out of date and nobody here can change it. Where do we start?

With a content audit rather than a design. Listing every page with an owner, a purpose and a keep, rewrite or delete decision tells you how much of a site you actually have, and it is normally a fraction of what exists. That answer changes the scope of everything that follows, so doing it first saves paying to migrate pages nobody reads.

Which CMS should we use?

The one your editors can work in, which is a different question from the one developers usually answer. Headless suits estates feeding several channels and teams comfortable with structured content. A traditional CMS with good preview suits a small team that wants to see the page. We will pick against your editing reality and say why, and we will not recommend a platform because we happen to have built on it recently.

Can you work with our design agency?

Routinely. The arrangement that works is agreeing accessibility and performance constraints with the designers before they finish, rather than receiving finished designs that cannot meet either. Contrast, focus states, text sizing and payload are cheap to accommodate in a design and expensive to retrofit into a build.

Is a single-page application the right choice?

Sometimes. For an application with real state and interaction, yes. For a content site it usually costs you performance on ordinary devices, complicates search visibility and adds a build step between an editor and a published page. Plenty of sites are better served by server-rendered pages with a little client-side behaviour, and that recommendation is unfashionable rather than wrong.

What happens after launch?

Dependency and security updates, content support and small changes, either as a retainer or handed to your team with the documentation to do it. What we will not do is treat launch as the end. A web application left without maintenance accumulates vulnerable dependencies whether or not anybody is changing it.

A site thatstays current.

Start with a content and accessibility audit. It needs access to the site rather than a contract, and it produces a page-by-page decision list you keep.

Get in touch Book a scoping call