Refresh Continuation — 57 Tickets
A 73-day refresh continuation spanning 57 tickets and 34 URLs. Header/footer propagation plus 4 Figma service pages, delivered in ~23 hours.
Screenshots captured by automated tooling — some elements may not have loaded fully or may layer on top of each other. For the most accurate view, visit the live site →
Carry the balance of a live-site refresh — small tickets, agency cadence, no regressions on parts of the site the agency did not ask to touch.
Client (end user): Evergreen Grace Dental Care — a US dental practice
Engagement: White-label development for a US marketing agency
Delivered: October – December 2025 · 73 days · ~23h across 57 tickets
What a Refresh Continuation Is
57 tickets across 73 days for a dental practice refresh already mid-stream — the agency’s homepage was live, but header and footer had not propagated to the other 33 pages, four new service pages were waiting on approved Figma designs, and a change-request queue had already started to form. Three work streams ran concurrently from day one: propagation, new-page builds, and the change queue, each gated individually through Site Checker before close.
Snapshot
| Field | Value |
|---|---|
| End-client industry | Healthcare — General Dentistry |
| End-client | Evergreen Grace Dental Care (US dental practice) |
| Engagement | White-label refresh continuation for a US marketing agency specialising in local-business websites |
| Project Type | Refresh continuation — header/footer propagation, 4 net-new service pages from Figma, change-request queue |
| Scope | 57 tickets across design propagation (header/footer to 34 URLs), 4 new service pages (Clear Aligners · Veneers · Teeth Whitening · Endodontics), and a change-request queue (gallery fixes, booking links, padding, menus, footer) |
| Timeline | 73 days (9 Oct – 20 Dec 2025), on the agency’s cadence |
| Effort | ~23h across 57 tickets — sub-1-hour average per ticket |
| Team | 5 specialists — rotating through development + QA + PM; no dedicated lead (characteristic of continuation work) |
| Templates | Pages built into the agency’s existing dental template system (34 URLs audited; 4 new pages added on top) |
| Tech Stack | WordPress · Elementor · WP Engine · Site Checker (xaverPRO QA plugin) · agency AutoQA (Phone · Links · Contact-Email · Content-AI · OpenAI visual check across 1920 / 1280 / mobile) |
| Cadence | 57 tickets — header / footer propagated across 34 URLs, 4 new service pages shipped from Figma, change-request queue worked through; 85-item QA checklist gated each ticket close |
| Engagement cadence | 11 agency-raised issues · 10 of 11 closed by handoff |
| Review rounds | ≈5 review rounds across the 73-day calendar window |
| Per-ticket effort | 57 internal Redmine tickets · median 14m / P75 32m per ticket |
| Launch checklist | 84 items, signed off before cutover |
The Brief
The agency had already published a refreshed homepage for Evergreen Grace Dental Care before our engagement started. The brief opened with that fact: “We already published a refreshed homepage… But we need to double-check whether the header and footer were transferred to the other pages.” The homepage design was done — our job was everything that came after it.
Three things needed to happen in parallel. First, the new header and footer had to propagate across the remaining 33 pages; the agency’s sitemap listed 34 URLs and the homepage was the only one where the refresh had fully landed. Second, four new service pages needed to be built from approved Figma designs and a Google Drive folder of copy docs — Clear Aligners, Veneers, Teeth Whitening, Endodontics — against the agency’s existing Service Page template. Third, a queue of change requests was already forming: gallery link bugs, duplicate images, a booking-link update, padding adjustments, footer Instagram logo placement, final menu additions.
The ask was not a single handoff with a cutover date. It was cadence: work through three simultaneous streams without tripping over each other, gate every change through QA before close, and respect the agency’s template system throughout.
Risk Context — three work streams, one live revenue surface
Refresh continuation work is more operationally complex than a clean refresh because the design propagation, the new-page builds, and the change-request queue all run simultaneously rather than in sequence. The live site is already indexed, already converting, already serving patients from day one — and it keeps doing so through all 57 tickets that follow. On a clean refresh there is a single design-swap gate; on a continuation, every ticket is its own gate. A header override that propagates cleanly to 30 pages but corrupts the layout on the 31st is a regression the agency cannot afford. The value being sold is not the volume of tickets — it is the discipline of running three concurrent work streams against a live site without introducing regressions along the way.
Operational Integrity at handoff
The Redmine record carries 41 QA-pass sub-tickets with a -qa suffix — one per work item, generated before each ticket returned to the agency — batched across six sequential invoices (#24–#29) so the hours-to-tickets reconciliation happened invoice by invoice rather than once at engagement end. Pre-ticket-close QA ran through Site Checker — see our QA discipline for the categories and the fail-zero gate. The agency’s own QA layer — their tools, their process — ran post-handoff and surfaced issues into the shared backlog for our fix loop until they signed off on each ticket.
How We Did It
1. Header / footer propagation across the 34-URL sitemap. The agency’s Website Sitemap tab listed 34 URLs alongside their assigned templates (Homepage · Services Lander × 9 · Service Page × 23 · About Us). The refresh had landed on the homepage; we audited header and footer placement on each of the remaining URLs, applied the refreshed design sitewide, and logged any page that required a manual deviation back to the agency. The constraint was typical of continuation work: parts of the site had been touched by a prior developer and the line between “changed” and “not changed” was not always crisp — the team’s rule was not to touch anything the agency had not asked us to touch.
2. Four new service pages built against Figma + copy docs. The agency supplied approved Figma frames for each new service page and a Google Drive folder with copy docs. We mapped those into the agency’s existing dental template (Service Page template) — Clear Aligners, Veneers, Teeth Whitening, Endodontics — keeping each page in draft until the agency released it to the menu. We chose the template path over custom page layouts because the site already ran 34 URLs on the agency’s template system, and divergent page structures would have broken the visual consistency the agency needed across the full sitemap. A constraint surfaced during build: the copy docs and Figma frames covered layout and copy but did not supply images for the new service pages, and meta descriptions were absent from every draft page — both had to be sourced from the legacy site and inserted manually before each page could leave draft status.
3. Change-request queue — worked in parallel with the design and build streams. Change requests came through Redmine while the propagation and new-page work was still active: “Gallery link is not working (change request)”, “Duplicate images (change request)”, “Footer Instagram Logo”, “Booking Link update”, “Too much padding”. Each ticket was scoped, developed, QA’d internally through Site Checker, returned to the agency, and closed on their sign-off. The interleaving of streams is what distinguishes a continuation from a clean refresh — the queue did not wait for the design propagation or the new pages to finish.
4. Two-stage QA — Site Checker pre-ticket-close + agency post-handoff. Every ticket, regardless of which stream it belonged to, was gated through Site Checker before close: fail-zero on core settings, content and SEO surface, URL structure, content-language sanitization across pages, posts, Elementor data, menus and widgets, and multi-resolution screenshots. The agency’s AutoQA layer then ran post-handoff — Phone audit · Links audit · Contact-Email audit · Content-AI check · OpenAI visual check across three viewports — and surfaced any remaining issues into the shared SEO + CX backlog for our fix loop. The 85-item launch / QA checklist was worked against each batch of changes before agency acceptance.
Four streams — header/footer propagation, new service pages from spec, change-request queue, and per-ticket QA — run concurrently because that is the shape of a refresh continuation. The discipline of keeping them from interfering with each other is the work.
Results
| Metric | Outcome |
|---|---|
| Change requests delivered | 57 tickets closed across the 73-day engagement |
| New service pages | 4 — Clear Aligners, Veneers, Teeth Whitening, Endodontics (built from Figma + agency copy docs) |
| Pages health-audited against header/footer propagation | 34 URLs in the agency’s Website Sitemap tab |
| Site Checker QA gate | Pre-ticket-close, fail-zero — ran before every individual ticket close |
| AutoQA coverage | Phone audit · Links audit · Contact-Email audit · Content-AI check · OpenAI visual check across 3 viewports (agency-managed) |
| Launch / QA checklist | 85 items tracked across Development / Main and post-change verification |
| Backlog tabs reconciled | 2 — Issues Backlog (SEO) + Issues Backlog (CX), with most items closing as Completed before agency handoff |
| Timeline | 73 days, delivered on the agency’s cadence |
| Effort | ~23h total across 57 tickets — average under 25 minutes per ticket |
| Handoff | Site live at evergreengracedental.com, HTTP 200, header and footer consistent across audited URLs |
The outcome, restated plainly: design propagated across 34 URLs, four new service pages shipped from approved Figma, and 57 change requests carried from raised to closed — all across three concurrent work streams over 73 calendar days, each ticket gated individually through Site Checker before close.
Process
| Phase | Duration | Outcome |
|---|---|---|
| Initial brief + scoping | ~1 week | Continuation scope catalogued: header/footer gap across 34 URLs, 4 new pages from Figma, open change-request queue |
| Design propagation | ~2 weeks | Header and footer applied to all 34 URLs; per-page deviations logged to agency |
| New service pages batch | ~3 weeks | Clear Aligners · Veneers · Teeth Whitening · Endodontics built in drafts from Figma; Go-Live sequence agreed |
| Change-request cadence | ~6 weeks (concurrent) | Small tickets triaged and closed one at a time; each through Site Checker pre-close QA + agency post-handoff sign-off |
| Final Go-Live sweep | ~1 week | Menu additions verified live; footer & gallery parity confirmed sitewide |
Phases overlap heavily — the change-request queue was active from week one, and design-propagation tickets continued to arrive through the new-page batch. This concurrent shape is characteristic of continuation work, where three streams run at once rather than sequentially.
Team
Delivery team
- Nikita Tumasevic — developer on core refresh work
- Pavel Sazhin — development + QA on change requests
- Timur Arbaev — development + QA on new pages and change requests
- Lyudmila Travkina — agency-side account / client liaison
- Anton Hersun, xaverPRO — project lead (estimation, agency-side communication, sign-off)
Agency-side project management, design approval, and client-facing communication remained with the partner agency throughout. Our team was invisible to the end client.
For agencies running a mid-stream refresh
If your agency has started a site refresh — homepage is live, interior pages are behind — and you need a development partner to carry the design through the rest of the site, build the remaining pages from spec, and work through the open change queue without touching anything you did not ask them to touch: that is a refresh continuation, and it is a distinct scope from a clean rebuild or a retainer cadence.
The complexity is not in any individual ticket. It is in running three work streams concurrently against a live site and keeping them clean. That requires a partner who understands the difference between what was already changed and what was not, and who will not improvise scope in either direction.
Send us the sitemap, the Figma link, and a list of open tickets. We will scope the propagation pass, size the new-page batch, and return a per-ticket rate on the change queue. No cost for the review, no obligation to proceed.
Don't have a spec yet? Send a one-paragraph description — we'll come back with the questions worth asking. Send a description →
Not a phase plan. A ticket flow across 73 days.
Refresh work does not proceed in sequential phases — it arrives as a rolling cadence of change requests, new-page batches, and QA passes overlapping in time. The visualization below traces that rhythm across the partnership window.
- Content updates (44%) are the characteristic majority on any refresh — small copy corrections, image swaps, SEO text refinements, none requiring structural changes.
- Bug / UI fixes (28%) trace to the live-site risk: each small change can surface edge-case breakage on adjacent pages; the fix cadence is its own QA signal.
- New service pages (14%) represent the only scope that resembled traditional "build" work. Each was held in draft until the agency explicitly promoted it to live.
- Navigation changes (9%) are disproportionately high-risk relative to effort: a menu change propagates across every URL in the template system.