Answer in brief
Ongoing Dev Support is $290/mo, runs as a monthly cycle and stops with 30 days notice. Here is what it covers, why volume is agreed at the start of each cycle, and how security updates and dependency drift differ from new feature work.
What website support is, and why it is billed by the month
Website support is work on a product that is already live: updates, checks, repairs when something breaks, and small adjustments along the way. At VITON13 it is a separate service called Ongoing Dev Support, priced at $290/mo. It runs as a monthly cycle, and you stop it with 30 days notice.
The monthly shape follows from where the work comes from. Browsers ship new versions, libraries close vulnerabilities, payment and mail providers change their interfaces. None of that arrives on your project plan; it arrives on somebody else's schedule and needs a response when it lands.
Paying per incident fits this badly. Every time something broke you would negotiate a quote again, wait for a free slot and re-explain the project to whoever picked it up. A monthly cycle removes that loop of negotiation and leaves only the work itself.
Draw one line early. Ongoing Dev Support does not cover a new build or a redesign, and those are scoped separately. The term protects both the budget and the schedule, because large work needs planning of its own rather than whatever hours a maintenance cycle happens to have left.
What Ongoing Dev Support actually includes
The stated scope is short, and it is worth holding in full: priority updates, a weekly release rhythm and technical maintenance. Three concrete items, not a vague promise to handle everything connected to the site. Knowing the edges is more useful here than the length of the list.
Priority updates mean your work enters the queue without a fresh round of approvals. When a dependency turns out to be vulnerable or an integration stops responding, the work starts inside the running cycle rather than waiting for another agreement to be signed.
A weekly release rhythm makes delivery predictable. Changes are gathered, checked and shipped on a regular beat instead of piling up for months into one large and risky update. For an owner, that means a change reaches the live site within a window you can name in advance.
Technical maintenance is the part nobody sees on screen: package updates, build checks, the state of the environment, forms and mail still working, errors watched. It reads modestly in a report, and it is what keeps the site in working order between visible releases.
Volume is agreed at the start of each cycle
There is no revision count in this service, and the omission is deliberate. No number of rounds is stated. What is stated is a different term: volume is agreed at the start of each cycle. Do not carry a figure over from another package, or you will argue about a promise nobody made.
In practice a cycle opens with a short list: what needs doing this month, what carries more weight and what can wait. The list is written down, and from there it works as a shared reference point for both sides of the arrangement.
That is a fairer instrument than a revision counter, because maintenance work is not uniform. Updating a dependency, restoring a broken form and adding a field in the CMS are tasks of different sizes, and calling each of them one revision distorts the picture.
To keep the cycle from blurring, hold the list short and ordered by priority. When something urgent appears mid-month, it is more honest to take another item out than to pretend that everything still fits inside the same weeks.
Security updates are not new features
A site does not sit still while you leave it alone. Dependencies, the server environment and third-party services keep shipping, and part of what they ship closes vulnerabilities. Installing those releases belongs to maintenance, not to product development.
The distinction has a practical consequence. A security update adds nothing a customer can see: afterwards the site looks and behaves exactly as it did. Skipping such updates, though, gradually turns your project into a collection of other people's known problems.
That is why the work belongs inside a subscription, where it does not compete for budget with new functionality. An update that has to go out this week should not be waiting behind the next investment decision your board takes.
Check separately who owns what happens next. Updating a CMS, a platform or a library can change behaviour, so after installation the key paths deserve a pass: forms, checkout, sign-in and content rendering across the templates you actually use.
Dependency drift and how it accumulates
A modern site is assembled from dozens of external packages. Each keeps its own schedule: it publishes fixes, changes interfaces and eventually marks older versions unsupported. The distance between your build and the current versions is what drift describes.
Drift matters because it compounds. One skipped update is applied today without effort. A year of skipped updates becomes a chain of incompatibilities, where each change forces another one further down the dependency tree before anything builds again.
Regular maintenance turns that into small reversible steps. Update, build, test, deploy, and the distance between your code and the outside world stays short enough to cross inside a single working day rather than a project.
This is why support costs money in months when nothing appears to happen. No visible change on the site does not mean no work; part of the job is making sure you never need an emergency intervention in the first place.
Why new features are scoped separately
The term is explicit: a new build or a redesign is not part of support and is scoped separately. This is not an attempt to sell more, it follows from the fact that you are looking at work of a different nature.
Maintenance preserves existing behaviour. A new feature changes it: new states appear, new routes, new ways to fail and new tests to write. Work like that cannot be fitted safely into a cycle whose whole purpose is stability.
For feature work VITON13 offers Product Build at $880 with a timeline of 2-3 weeks and two rounds of revisions per delivered feature. Native mobile apps and payment licensing are not included in that package.
The separation serves you as well. When development is priced on its own, you see what it truly costs instead of dissolving it into a maintenance invoice, where it quietly consumes the hours set aside for stability.
What a weekly release rhythm changes
Shipping regularly is less about speed than about the size of each change. The more often releases go out, the smaller each one is, and the easier it becomes to work out what caused a problem when one shows up.
Rare, large updates stack dozens of edits into a single moment in time. When something breaks after a release like that, finding the cause takes longer than the repair, and the site behaves incorrectly for the whole search.
A weekly beat also gives you a planning horizon. A request made today lands in the next deployment, so nobody has to chase status daily or guess when a change will finally become visible to customers.
Rhythm does not cancel urgency. A critical failure does not wait for the calendar, but everything else benefits from entering a predictable flow rather than an open-ended queue with no dates attached to it.
Performance changes over time
Site speed is not among the results you achieve once. Analytics scripts get added, images grow, third-party widgets are embedded, data volumes rise. Each of those changes looks harmless on the day it ships, which is precisely the difficulty.
Maintenance means watching that accumulation. It pays to measure key pages on a regular schedule and compare the result against the previous cycle, rather than waiting until a visitor says the site has started to feel slow.
The MDN Web Docs performance documentation explains what perceived speed is made of and what each metric describes. It is a reasonable reference when you need to explain why a particular change deserves attention this month.
The practical takeaway for an owner: put performance on the cycle list as a recurring item, rather than treating it as part of a launch that was signed off once and then closed for good.
Accessibility needs the same regular attention
Accessibility degrades through change as well. A new banner traps keyboard focus, an added form ships without field labels, an updated palette drops contrast below a usable level. All of this arrives after launch, not at it.
The W3C quick reference for WCAG 2.2 lists success criteria together with ways to check them. It works well as a checklist during regular reviews, because it lets you test what moved instead of auditing the entire site again.
Look at what changed: new interactive elements, focus order, text alternatives for images, and whether error messages in forms can be read and understood without relying on colour alone to carry the meaning.
This is maintenance, not a separate project. It fits a monthly cycle in small portions and survives postponement badly, because deferred work returns as one long list that nobody on either side wants to open.
When a one-off fix is enough
A monthly arrangement is not right for every site. When the task is finite and well understood, the sensible instrument is Site Fix Pack at $70: up to five agreed fixes, a timeline of 1-2 working days and one round of revisions.
The package includes a mobile and desktop check and a before/after list at handover. It suits the situation where you can already name precisely what bothers you and expect nothing further to follow behind it.
Its boundaries are equally clear: new pages, redesign and migrations are not included. Do not try to route large work through it, because you will spend the time arguing about scope instead of collecting a result.
The one-off format stops working once requests repeat. Three or four separate orders in a quarter say that you are already buying support, only without predictability and without a shared plan standing behind it.
How support relates to launching the site
Support usually begins after the site has been handed over. Launch Site costs $380 with a timeline of 3-5 working days and covers a responsive build, core CMS or data wiring and deployment setup, with two rounds of revisions before launch.
Content and translations are not part of that package, they are supplied by the client. The same limit continues afterwards: maintenance does not write your copy, so plan content updates on your own side of the line.
When the launch is urgent, Launch Site Express is $520 with a timeline of 2 working days: the same scope in a priority queue with daily builds, a launch checklist and a handover call, with one round of revisions after the first full build.
Note what Express leaves out: content, photography and ongoing support. Support is a separate decision, taken once the site is live and set up as its own cycle rather than folded into the launch itself.
How to decide whether monthly support fits you
Start with the cost of downtime. If a broken form or a failing checkout costs you orders the same day, a predictable queue for fixes carries a value you can express as a number rather than a feeling.
Then ask how often the site changes. A property that moves every week needs different care from a brochure page nobody has touched in two years, and paying the same for both makes very little sense.
Then ask about people. Is there someone on the team who will update dependencies, verify a build and read an error log? If nobody holds that role, support fills a function rather than merely completing a task list.
Finally, the arrangement is reversible. The 30 days notice term means the decision can be revisited without a long contract: run a cycle or two, then judge what changed in ways you can measure.
Practical checklist
- Write the cycle list before the cycle starts and order it by priority.
- Separate maintenance from new features on that list and price them apart.
- Re-check forms, checkout and sign-in after every dependency update.
- Measure key pages each cycle and compare against the previous result.
- Review the parts of the interface that changed against WCAG 2.2 criteria.
- Record in writing who gives the 30 days notice to stop, and in what form.
Questions and answers
How much does Ongoing Dev Support cost?
$290/mo. The service runs as a monthly cycle, and stopping it takes 30 days notice. Volume is agreed at the start of each cycle.
How many revisions are included per month?
No revision count is stated for this service, and you should not borrow a figure from another package. The stated term is different: volume is agreed at the start of each cycle, so the task list is written down when the cycle opens.
What exactly does support include?
Priority updates, a weekly release rhythm and technical maintenance. In practice that means package updates, build checks, the state of the environment, forms and mail still working, and errors being watched.
Does support cover a redesign or a new site?
No. A new build or a redesign is not part of support and is scoped separately, because work of that size needs planning of its own rather than the hours left over from a maintenance cycle.
How is support different from a one-off fix?
The one-off route is Site Fix Pack at $70: up to five agreed fixes, a timeline of 1-2 working days, one round of revisions, a mobile and desktop check and a before/after list at handover. New pages, redesign and migrations are not included.