Post-launch support covers technical stabilisation, defect remediation, and handover clarification for deliverables built and deployed by Xylora Studios. It ensures that all signed-off work performs accurately in the live environment, deliberately excluding net-new functional requests or external platform failures.
Scope of post-launch coverage
Post-launch support exists to bridge the gap between initial deployment and ongoing steady-state operations. The scope is strictly anchored to the specifications agreed upon in the initial approved brief.
Support coverage is divided across our three internal departments:
- Technology: Resolves functional defects, script errors, broken interactive components, database connection drops, and deployment regressions arising directly from the studio's codebase.
- Creative: Corrects visual discrepancies, responsive layout clipping, missing static production assets, or unintended font display errors that deviate from approved design proofs.
- Operations & Client Services: Manages issue logging, monitors ticket progression, coordinates schedule impacts, and provides written status updates through the portal.
Post-launch support does not cover new aesthetic revisions, structural redesigns, additional template development, or custom feature expansion. Work that falls outside the original contract scope requires a separate submission, with bespoke quotes issued within 48 hours of receiving a complete brief. Package-based maintenance or additions are referenced directly on the packages page.
Sequence of events
Once a project transitions from staging to production, post-launch monitoring follows an orderly progression:
1. Production Deployment: The Technology department pushes the deliverable live, performs preliminary health checks, and formally issues completion notification to the client. 2. Handover Period: A baseline support window begins immediately upon deployment notification. During this phase, client teams conduct end-user validation against standard user flows. 3. Issue Reporting: Any observed anomalies must be logged directly through the Ask Xylo chat on this portal. Submissions must include device profiles, browser versions, steps to reproduce, and visual evidence. 4. Triage and Allocation: Operations & Client Services reviews the report, verifies that the item falls within the original specification, and assigns it to either Technology or Creative. 5. Remediation and Re-test: Studio engineers or designers deploy fixes directly to production or through a hotfix staging branch, followed by verification testing. 6. Formal Resolution: Operations confirms the remedy in the Ask Xylo thread and logs the issue as resolved.
Responsibilities and requirements
Effective support depends on clear lines of responsibility between both parties.
What the studio provides - Direct access to the internal production teams responsible for the build. - Defect fixes for any reproducible deviation from the agreed brief. - Written clarification regarding system setup, production asset locations, and basic administrative usage.
What the client must supply - A designated single point of contact to prevent conflicting support tickets. - Clear, reproducible steps for any reported bug, including screenshots, video recordings, or system error text. - Continued access to the client’s production environment, server dashboards, DNS panels, or third-party accounts required to diagnose issues. - Timely verification when a fix is ready for review.
Timings and operational hours
The studio operates Monday to Thursday, 09:00 to 17:00 GMT. We do not operate on Fridays, weekends, or UK bank holidays.
All support requests must be lodged via the Ask Xylo chat on this portal. Our first reply target is within 24 hours of submission during active studio hours. Tickets submitted outside operational hours (such as Thursday evening through Sunday) enter the triage queue for review on the following Monday morning.
Exclusions and failure cases
Post-launch support is designed exclusively to safeguard the stability of delivered work. It is not an open-ended maintenance retainer. The following scenarios are explicitly excluded from standard post-launch support:
- Client or Third-Party Modifications: If a client, third-party contractor, or unapproved plugin modifies the codebase, settings, or database after release, the studio’s standard support commitment is immediately voided. Restoring corrupted work must be quoted separately.
- Third-Party Service Outages: Failures originating from hosting providers, domain registrars, payment gateways, or third-party APIs are outside studio control and are not covered.
- Content Population: Manually entering catalogue data, bulk drafting blog posts, or configuring third-party products post-launch is the client’s operational responsibility unless specifically contracted.
- Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site.
Post-launch checklist
Before raising an issue with Operations, verify the following:
- [ ] The issue deviates directly from the approved brief rather than being a new feature request.
- [ ] No third-party plugins, theme updates, or client-side code edits have taken place since launch.
- [ ] The bug has been reproduced in more than one browser or in an incognito window with cache cleared.
- [ ] Screenshots, error logs, and precise step-by-step reproduction instructions are prepared.
- [ ] The report is submitted directly through the Ask Xylo chat on this portal.