After a relaunch, terms blur quickly: support, maintenance, new features, ongoing upkeep. To the client, it all sounds like “you'll take care of it”. That's why we define before launch what the 30 days afterward cover and what they don't. That isn't unfriendly, it makes sure there's no dispute later.
The case
After a launch, the usual reports came in during the first few weeks: a bug on mobile, a link that's wrong. And in between, things that weren't bugs: a new page, another app, a change the client had made themselves that shifted something else. Everything landed in the same inbox, with the same expectation.
What launch support covers and what it doesn't
| Covered, 30 days from launch | Not covered, separate service |
|---|---|
| Bugs in what we built | New features and pages |
| Features that don't work as agreed | Additional apps |
| Display bugs on devices we tested | Issues caused by your own changes to the theme |
| Questions about using what we built | Changes by third parties, such as app updates |
| Theme updates | |
| Ongoing maintenance and optimization |
The line is simple: if something doesn't work the way we promised, it's a bug, and we fix it. If it's something new or something has changed, it's a new job. For that, there's a short offer or an ongoing support plan.
What you can take away
- Ask before the project what happens after launch. How long is support, what does it cover, what does ongoing support cost afterward?
- A new wish isn't a bug. Both are legitimate, but they're two different things.
- Your own changes shift responsibility. If you work on the theme yourself after launch, tell the agency. That makes it faster to pin down a bug.
- Maintenance is an ongoing service. A store is alive, apps and Shopify change. If you want that covered, you need a support plan, not extended project support.
Want to know what happens after launch? We clarify it before the project, in writing.