what about ongoing changes after launch?

launch is where the work changes shape. text needs updating, a form needs a new field, a dependency goes end-of-life, someone leaves and their access has to go with them. we set every build up so you can choose who handles that, and change your mind later.

take it over yourself

content is editable on purpose. text, images, and the pages that change often are built so a person on your team can update them without opening a code editor, and the handover doc explains how, who to call, and what runs where. we write it for whoever runs the business, so it doesn't assume an engineer is reading. for a marketing site, that covers most of what changes in a year.

keep us on a retainer

for anything beyond content, a retainer gives you a team that already knows your setup. the shape of it:

• an agreed block of hours each month, and unused hours roll over once
• a shared channel instead of a ticket portal, with priorities you set
• anything from a copy tweak to a new internal tool
• a flat monthly number with no per-ticket charges, month to month, cancel with 30 days' notice

pricing is covered in what does a retainer cost.

the changes nobody schedules

whoever does the work, three things need an owner after launch: keeping dependencies current, revoking access when someone leaves, and retesting after any significant change to authentication, payments, or hosting. two of them are on our pre-launch checklist, and none of them stay done by themselves.