A product that works, made to look it, usually without touching the backend

It depends on whether the difficulty lives on the surface or in the model underneath. If people are struggling with layout, labelling, density and inconsistent patterns, a refresh fixes it well. If the underlying concepts are wrong (the workflow does not match how the job is actually done, the permissions model fights the org chart), then a refresh makes a confusing product prettier and no easier. We will tell you which one you have during the audit, and if it is the second we will say so before you commit to the larger piece of work.

Not always, and we would rather not. Products built with a component-based front end can often be re-skinned through tokens and component replacement. Older server-rendered templating stacks can frequently be restyled, though hand-rolled CSS accumulated over years sometimes costs more to untangle than to replace. We assess this specifically in the audit and give you both routes with honest costs, rather than defaulting to the one that suits us.

Some of them, always. Familiarity is a genuine feature, and moving something costs a daily user real time even when the new arrangement is objectively better. We reduce the damage by keeping structures where they work rather than rearranging for novelty, phasing the rollout, giving your heaviest users advance notice and a way to feed back, and keeping the old view available for a period where that is technically feasible. Expect a burst of complaints regardless. Anyone who tells you otherwise has not shipped a redesign.

Often, and it is usually where we start, but "without changing a line" is a goal rather than a guarantee. Some improvements are purely presentational. Others need the API to return something it currently does not, a total count for pagination, a field the old screen never showed, a status the new flow depends on. Those come to you as a separate, costed list so you can decide what is worth the backend time and what to defer.

An audit tells you where you stand against WCAG at a point in time, and remediation closes the issues it found. That is a strong, defensible position, and it is what a conformance statement is built from. It is not a certificate, and nobody can honestly sell you one. Automated tools catch only a portion of real problems, manual testing catches most of the rest, and accessibility is a state you maintain: every new feature can introduce new issues. We will hand you the audit, the fixes and the process to keep it, and we will not tell you it is finished forever.

Usually and often by a lot, because you keep the business logic, the integrations and the years of edge cases already handled. Not always, though. If the front end is so entangled with the backend that the surface cannot be separated, or the framework is so old that nothing current will run alongside it, a refresh becomes a rewrite wearing a smaller name. We would much rather establish that during the audit and tell you than discover it halfway through and send you a change request.