Answer in brief
A package window describes the supplier's work, not your launch date. Here is what decisions, copy, access and acceptance add to it, and why Product Build is quoted in weeks while the other packages are quoted in working days.
What a timeline is made of: the short answer
A timeline is four stretches placed end to end: the supplier's build window, your decisions, your material, and acceptance. Writing code fills a smaller share of the calendar than waiting on a question nobody has yet agreed to own.
The VITON13 development page quotes specific windows: 1-2 working days, 2 working days, 3-5 working days, 2-3 weeks, and a monthly cycle. Every one of them describes the supplier's work. A launch date appears once your own intervals are added.
This is why a single package produces two different dates for two clients. The build is identical, but the approval queue, the readiness of the copy and the speed of handing over access are not, and that gap moves the calendar.
What follows sets out what sits behind each window, which of your own actions hold it in place, and why Product Build is quoted in weeks while the other packages are quoted in working days. The difference is not cosmetic.
What each package actually quotes
Site Fix Pack is $70 and takes 1-2 working days: up to five agreed fixes, a mobile and desktop check, and a before/after list at handover. One round of revisions. New pages, redesign and migrations sit outside the package.
Launch Site is $380 and takes 3-5 working days: a responsive build, core CMS or data wiring, and deployment setup. Two rounds before launch. Content and translations are supplied by the client, because the supplier does not write them.
Launch Site Express is $520 and takes 2 working days: the same scope in a priority queue, with daily builds, a launch checklist and a handover call. One round after the first full build. Content, photography and ongoing support are excluded.
Product Build is $880 and takes 2-3 weeks: feature delivery, state and route logic, testing and hardening. Two rounds per delivered feature. Native mobile apps and payment licensing are excluded. Ongoing Dev Support is $290/mo on a monthly cycle with 30 days notice to stop.
Why Product Build is quoted in weeks
Working days are an honest unit where the scope is known in advance. Five fixes, or one responsive build, can be written down as a list, so the window can be named before work starts and then held without renegotiation.
Feature delivery does not describe itself that way. State and route logic unfolds as it is built: one screen implies a second, and checking edge cases sends the work a step backwards. A week absorbs those returns, a day does not.
Testing and hardening live inside the same 2-3 weeks. They are a named part of the package rather than the time left over once features begin to compile, and they produce a share of the rework a daily grid cannot hold.
The practical consequence is simple: do not quietly convert 2-3 weeks into ten or fifteen working days and plan against that grid. The wording in weeks was chosen deliberately, and it is worth keeping verbatim in your own correspondence.
Decisions: the queue of unmade choices
Calendars are consumed by questions without an owner rather than by lines of code. Which of two homepage directions to take, how many levels the menu has, what happens after a form is submitted: each one waits for someone to close it.
While a question stays open the work does not stop; it routes around the disputed area instead. That detour costs time twice, once for the placeholder decision and again when the placeholder is replaced by the real answer.
What helps is a named person rather than a fast reply. One approver with the final word shortens the cycle more reliably than a wide group where everybody comments, nobody closes the question, and the discussion circles back.
Agree in advance which channel questions arrive through and how quickly they are answered. That interval belongs to your side of the launch date, and it deserves the same planning attention as the build itself.
Content and translations arrive from the client
Launch Site states it plainly: content and translations are supplied by the client. Express repeats the same line and adds photography. VITON13 does not write your copy or translate it, and that is a boundary of the service rather than small print.
A start line follows from this. The three to five working days do not begin at signature; they begin once the material exists. Empty blocks cannot be filled in later without a second pass over the layout and a second review.
Copy can be written in parallel with the build if the page structure is fixed first. Give the writer the list of blocks and a length limit, and the material arrives exactly at the point where the build needs it.
A multilingual launch needs a plan of its own: translation starts once the source text has stopped changing. Editing one sentence in the source language sends every language version back into the queue, not just one of them.
Review rounds occupy the calendar
Revision rounds differ by package, and the difference lands on the calendar. Fix Pack has one round. Launch Site has two rounds before launch. Express has one round after the first full build. Product Build has two rounds per delivered feature.
A round is a collected list, not a stream of separate messages. Twenty comments sent as one document cost a single pass; the same twenty sent one at a time across a week cost a full week of work.
For Ongoing Dev Support no revision count is stated at all. What is stated instead is that volume is agreed at the start of each cycle. Do not carry a number over from another package, because package terms do not transfer.
Book the acceptance window like a meeting: who reviews, on which devices, and by what hour the list is sent. Without that, a round stretches to exactly as long as gathering opinions inside your team happens to take.
Access, accounts and outside parties
Deployment setup is part of Launch Site, but it depends on what you hand over: the domain, DNS, hosting and account credentials. Until access exists the work can be finished while the launch, in practice, has not happened.
Some of that access is issued by outside organisations at their own pace. A registrar, a bank, a payment provider or a corporate IT desk answers on its own schedule, and no supplier can compress that schedule for you.
Collect credentials on day one rather than on launch day. The list is short and known in advance, so it runs comfortably alongside the build and blocks nothing while you work through it item by item.
Payment licensing is excluded from Product Build. Where a product needs to take payments, the legal side and the work with the provider stay on your side and are planned separately from the 2-3 weeks of development.
Scope boundaries: what holds a window and what moves it
A window is held in place by a list. “Up to five agreed fixes” is that list, and it is the reason 1-2 working days stays a realistic promise. A sixth fix does not stretch the package; it becomes separate work.
Fix Pack excludes new pages, redesign and migrations. That is not a formality: moving data and reworking a layout live in a different unit of time, and forcing them into a two-day window breaks the window itself.
Product Build excludes native mobile apps. A web build and a native application are different bodies of work, and swapping one for the other changes the composition of the service rather than the date it finishes.
Check the scope wording before the start rather than halfway through. The question of whether something is included costs a minute at the beginning and several days once the build is running and the schedule is agreed.
Testing, performance and accessibility
Testing and hardening are named inside Product Build, which means they are named inside the same 2-3 weeks. They hold their own place in the calendar rather than the time left over once features are written and handed across.
Performance is checked by measurement rather than impression. The MDN Web Docs performance material describes what the browser exposes and which loading stages are worth watching; running those checks takes hours, and those hours belong in the plan.
Accessibility works the same way. The W3C quick reference for WCAG 2.2 lists the success criteria an interface is checked against, and working through that list is a scheduled task rather than a final glance before publication.
Both checks cost less before launch than after it. Something found during the build is corrected inside a round; the same thing found after launch arrives as separate work and is scoped separately from the package.
Working days against calendar days
1-2 working days, 2 working days and 3-5 working days are stated in working days precisely. A Thursday start on a 3-5 working day window pushes the finish past the weekend, and that is arithmetic inside the wording rather than a delay on the supplier's side.
Product Build's 2-3 weeks is stated differently, in weeks. There is no need to convert it: the unit was chosen to match the character of the work, not for the convenience of a shared project spreadsheet.
Public holidays in your country and in the supplier's may not coincide. Name them before the start, because that costs less than explaining the gap at the moment a date has already been promised to the market.
To reach a launch date, add three intervals: the package window, your own intervals for decisions and material, and the acceptance window. That sum is the date you can safely repeat outside the project team.
Express: buying a place in the queue
Launch Site Express is $520 against $380 for the ordinary Launch Site, and it takes 2 working days against 3-5. The price difference buys a priority queue rather than a different body of work.
Express adds daily builds, a launch checklist and a handover call. A daily build means your comments land on a running version every day, and that tightens the feedback loop between the two sides of the project.
There is one round of revisions here, and it comes after the first full build. That changes your preparation: comments go in a single document by an agreed hour, or a two-working-day window loses its purpose.
Content, photography and ongoing support are excluded from Express. A priority queue accelerates the supplier, not the writing of your own copy, so the material has to exist before the window opens at all.
After launch: a monthly cycle instead of a date
Ongoing Dev Support is $290/mo and runs as a monthly cycle with 30 days notice to stop. The unit here is neither a task nor a day but a cycle, and planning follows cycles rather than one-off dates.
The package covers priority updates, a weekly release rhythm and technical maintenance. The weekly rhythm buys predictability: a change goes into the next release instead of waiting for a fresh conversation about when it might ship.
For support no revision count is stated. What is stated instead is that volume is agreed at the start of each cycle. That is the planning mechanism: you agree the content of a month, not a quota of reworks.
A new build or a redesign is excluded from support and scoped separately. The split is useful: the monthly cycle holds the running site, while larger work gets a window of its own and its own rounds.
Practical checklist
- Appoint one approver with the final word and fix how quickly questions get answered.
- Collect the domain, DNS, hosting and account credentials on day one rather than on launch day.
- Fix the page structure before the writer starts producing copy for it.
- Gather comments into one document and send them as a single round by an agreed hour.
- Check the package exclusions: new pages, migrations, native mobile apps, payment licensing.
- Convert the package window into a calendar date using both sides' weekends and public holidays.
Questions and answers
How long does a launch website build take?
Launch Site is $380 and takes 3-5 working days. The window covers a responsive build, core CMS or data wiring, deployment setup, and two rounds of revisions before launch. Content and translations are supplied by the client.
Why is Product Build quoted in weeks rather than working days?
The package is $880 and quoted as 2-3 weeks because it covers feature delivery, state and route logic, and testing and hardening. That work unfolds as it is built, so the weekly unit is deliberate and does not need converting into days.
Can a launch be accelerated by paying more?
Partly. Launch Site Express is $520 and takes 2 working days: the same scope in a priority queue, with daily builds, a launch checklist and a handover call. One round of revisions comes after the first full build, and content, photography and ongoing support are excluded.
What does Site Fix Pack include, and over what window?
$70 and 1-2 working days: up to five agreed fixes, a mobile and desktop check, a before/after list at handover, and one round of revisions. New pages, redesign and migrations are not part of the package.
How is the timeline for technical support counted?
Ongoing Dev Support is $290/mo and runs as a monthly cycle with 30 days notice to stop. No revision count is stated for it; what is stated is that volume is agreed at the start of each cycle. A new build or redesign is scoped separately.