Answer in brief
The CMS question is not settled by comparing systems but by two answers: who will edit the site, and how often. This is a look at three shapes of editing, what core CMS or data wiring means inside the Launch Site package, and what stays your job.
The answer: a CMS is for the person who will edit the site
Whether you need a CMS is settled by one fact rather than by a feature comparison: is there someone in the company who will sit down and change the text on a page? If that person exists and the edits are regular, you need an admin. If nobody will, the panel becomes another system to maintain.
The failure has a recognisable shape. The panel gets built, logins are handed out, and six months later nobody remembers the password, so the text still gets changed by emailing the developer. The money went into a capability nobody uses, and it still has to be kept up to date.
So the conversation starts with two questions: who exactly will edit the site, and how often. Those two answers shape the form of the admin, its size, and how much time goes into training the employee after launch, far more than any list of features in a product description.
The rest of this article covers what «core CMS or data wiring» means in practice, which shapes of editing exist, what stays your responsibility, and how to write the decision down before the build starts so that nothing has to be rebuilt afterwards.
Name a person, not a department
«Marketing will handle the updates» is not an answer. Departments do not log into admin panels; a specific employee does, with a login, a personal level of patience for interfaces, and a task list for the week. Until there is a name, the requirements cannot be written down.
Ask that person what they have done with a website before. Experience with any admin panel changes expectations: they already know what a draft, a preview and a publish button are, and nobody has to explain the difference between a page and a block inside it.
The second question is what they will actually change. One person edits only prices and phone numbers, another writes articles, a third uploads catalogue photographs. Those are three different sets of fields, and building all of them together just in case means paying for what nobody will touch.
If there is no editor and none is planned, the honest answer is that you do not need an admin at all. Edits in that situation are better ordered as a task, and the content stays in the project sources you receive at handover along with the access.
How often the content changes: three patterns, three conclusions
The first pattern is editing almost every day: news, offers, new arrivals, job openings. An admin pays for itself immediately here, because every request to a contractor costs time, and a queue for a two-minute change slows down a whole department that had other work planned.
The second pattern is a few changes a month: update a price list, rewrite a service description, add a testimonial. A narrow set of editable fields covers that. The edits are predictable, and a full publishing system would sit almost unused between them.
The third pattern is a site that changes two or three times a year. A panel then idles while its updates still have to be installed. Ongoing Dev Support fits better: $290 per month for priority updates, a weekly release rhythm and technical maintenance, on a monthly cycle, with volume agreed at the start of each cycle and 30 days notice to stop.
Patterns mix. Prices and contact details can change every week while the page structure stays untouched for years. In that case only the moving part is exposed for editing, and everything else stays in code, where an accidental mouse movement cannot reach it.
What «core CMS or data wiring» means inside the Launch Site package
The Launch Site package is $380 and covers a responsive build, core CMS or data wiring, and deployment setup. The timeline is 3-5 working days, there are 2 rounds of revisions before launch, and content and translations are supplied by the client rather than by us.
«Core CMS» means this in practice: the parts of the site you called moving parts are exposed as editable fields, and everything else stays assembled. It is not a universal page builder but a panel shaped around the specific list of things you said you intend to change.
«Data wiring» is the other route: the content lives in an external source, a spreadsheet or a catalogue for instance, and the site reads it from there. That suits a business where somebody already maintains the data and duplicating it into a separate panel would create a second version of the truth.
The choice between the two rests on the same question: where is the employee comfortable working? Somebody who already lives inside a supply spreadsheet will not open a new panel, and wiring the data removes the training and the extra interface together.
Three shapes of editing you are choosing between
The first shape is editable fields: a heading, a body text, a price, a photograph. Each field is defined in advance with one clear purpose, and the layout cannot be broken from inside it. What changes is what was exposed, and nothing beyond that.
The second shape is a full publishing system: drafts, dates, authors, categories, a media library. It earns its place when new material appears regularly and the archive itself needs order, not only when an already published paragraph needs correcting.
The third shape is content in the project sources. The text sits next to the code, and a change goes through a build and a deployment. For a team with a developer that works; for an owner with no technical person on staff, it does not.
Shapes combine. Service cards can live in fields, articles in a publishing system, and legal texts in the sources, because lawyers rewrite them once a year and always through a task, never casually on a Friday evening between other things.
Editing content is not the same as moving the layout
One expectation worth settling before the build: an admin usually lets you change content, not drag blocks around the screen with a mouse. That limit is deliberate, and it protects the design and the layout from changes made in a hurry and shipped without a check.
A free block editor gives more freedom and, with it, more ways to spoil a page: broken spacing, five different heading sizes, an image stretched across the full width. After six months a site edited that way looks assembled from unrelated kits of parts.
So the brief should not say «we want to change everything». It should list elements: the service heading, the price, the timeline, three benefit bullets, the photograph. A list like that converts into fields directly, with no interpretation step in between.
If a new page type or a new block is needed later, that is separate work. The Product Build package at $880 covers it: 2-3 weeks, with 2 rounds of revisions per delivered feature; native mobile apps and payment licensing are not included in it.
Catalogues, prices and data: when the admin stops being about text
A catalogue changes how the question is posed. It is no longer about a paragraph on a page but about structure: a product has a name, a price, a stock status, photographs and a category, and all of it has to stay consistent between the listing and the product page.
What has to be decided is where the source of truth sits. If products are maintained in an accounting system, the site should read them from there. Otherwise two versions of a price appear, and somebody will send a customer the outdated one attached to a quote.
Typing a catalogue into a panel by hand is reasonable when there are few items and they move rarely. Once there are hundreds of them, manual entry turns into a standing job that nobody put in the budget and nobody wants to inherit.
Filtering, states and routing are development work, not content entry. The Product Build package names it directly: feature delivery, state and route logic, testing and hardening, which is a different order of work from filling in a field in a panel.
Content and translations stay on your side
A boundary worth stating plainly: VITON13 does not write the client's content and does not do translations. The Launch Site terms say it outright, that content and translations are supplied by the client. An admin does not change that; it only provides the place where the text goes.
The practical consequence is that the text has to exist by the time the build happens. An empty panel on launch day means an empty site rather than flexibility: visitors see placeholders, and search engines index pages with nothing on them to read.
Languages work the same way. Three language versions are three sets of copy that somebody has to write and keep current. Without that resource it is more honest to launch in one language and add the others once there is something worth adding.
It also helps to agree who owns each language: one person writes and publishes, another only reviews. Otherwise edits stall between several approvers after launch, and no admin panel has ever cleared a queue that is made of people.
Images, page weight and loading speed
An admin hands image uploading to somebody with no technical training. A photograph taken on a phone and uploaded untouched can weigh several megabytes, and the browser has to download it before the page settles into its final state on the screen.
That is why image handling belongs on the site side: size limits, compression, modern formats, and deferred loading for everything below the first screen. The MDN performance documentation works through these techniques one by one and explains what each of them changes.
It is worth constraining the input as well: a hint about the expected proportions next to the field, a warning when a file is too large, a crop to a fixed aspect ratio. That is simpler than clearing up the consequences of somebody's upload every month.
Speed deserves checking after launch too, not only at acceptance. Content accumulates, and a page that was light on the first day can be dragging dozens of uploaded photographs behind it a year later, with nobody noticing the drift while it happens.
Accessibility: what an editor can break without noticing
Things that decide whether a page can be used at all pass through the admin. WCAG 2.2 requires text alternatives for non-text content, which is success criterion 1.1.1, and the person filling those in is usually whoever uploaded the image.
Headings are the second example. Criterion 1.3.1 asks that the structure of a page be available programmatically and not only visually. When an editor makes a subheading by putting a line in bold, the structure disappears even though the screen looks almost the same.
That produces a practical requirement for the panel: an alt field beside every upload, heading levels chosen from a list rather than set by font size, and meaningful link labels instead of «read more» repeated five times down a single page.
The W3C quick reference for WCAG 2.2 works here as a checklist: it gathers the criteria in one place that you can walk through. Some of the items belong to development, and some belong to whatever the editor types into the panel.
Access, roles and what you receive at handover
Roles are not a question of trust but of consequences. One person publishes, another prepares drafts, a third only reads the statistics. That split reduces the chance that an accidental edit goes live on a Friday evening and stays there until Monday morning.
Accounts should belong to the company rather than to an employee's personal mailbox. Changing contractors or losing a manager must not mean losing access to the panel, the domain and the hosting along with that person and their inbox.
At handover, ask for more than logins: a short written note on how to add a page, how to replace a photograph, and how to undo a mistake. One page of text saves dozens of emails during the first month after the site goes live.
If edits arrive faster than the team can work through them, Ongoing Dev Support at $290 per month covers priority updates, a weekly release rhythm and technical maintenance. A new build or a redesign is not part of it and gets scoped separately.
Writing the decision down and choosing a package to start with
Put the decision in one paragraph: who edits, what they edit, how often, and what stays in code. That paragraph answers whether you need a CMS and which kind in your own terms, rather than in the terms of somebody else's feature table.
For a new site, Launch Site at $380 fits: a responsive build, core CMS or data wiring, deployment setup, 3-5 working days and 2 rounds of revisions before launch. Content and translations are yours to prepare before the build begins.
When a date is already fixed, Launch Site Express is $520, the same scope in a priority queue: 2 working days, daily builds, a launch checklist and a handover call, with 1 round of revisions after the first full build. Content, photography and ongoing support are not included.
If the site already runs and needs specific corrections, start with Site Fix Pack at $70: up to 5 agreed fixes, a mobile and desktop check, and a before/after list at handover, in 1-2 working days with 1 round of revisions. New pages, redesign and migrations are not included; the details sit at /services/development.
Practical checklist
- Name the employee who will open the admin, and write that name into the brief.
- List the specific elements to be edited: heading, price, timeline, photograph, bullet points.
- Estimate how often content changes: daily, a few times a month, or twice a year.
- Decide where the source of truth for prices and the catalogue sits, so data is not maintained twice.
- Prepare content and translations before the build starts, because no panel supplies them.
- Check alt fields, heading levels and uploaded image weight at acceptance.
Questions and answers
How do I tell whether I need a CMS at all?
Name the person who will change the content and how often they will do it. If that editor exists and the edits are regular, you need a panel. If the site changes two or three times a year it will idle, and a support arrangement with edits ordered as tasks fits better.
What does core CMS mean inside the Launch Site package?
The package is $380 and covers a responsive build, core CMS or data wiring, and deployment setup. The timeline is 3-5 working days with 2 rounds of revisions before launch, and content and translations are supplied by the client.
Will I be able to move blocks and change the page design from the admin?
Usually not: the panel changes content inside fields defined in advance, not the arrangement of blocks. New page types and new blocks are separate work, closer in shape to the Product Build package.
What does support cost if we cannot keep up with the admin ourselves?
Ongoing Dev Support is $290 per month and covers priority updates, a weekly release rhythm and technical maintenance. It runs on a monthly cycle, volume is agreed at the start of each cycle, and 30 days notice stops it.
Will you write the content and translations for the site?
No. Content and translations are supplied by the client, which is stated in the Launch Site terms. Our side is where that text sits, how it behaves across screen sizes, and how it can be changed afterwards.