We hear «how long will this take» more often than we hear questions about money. It shows even in the structure of our own site: going through 241 service pages, we found a separate question about timing on 162 of them — and in 73 cases it is worded literally, «how long does it take».
The answer «it depends on the scope» is true and helps nobody. So here is what already sits on those service pages and has been public for a while: ranges in working days, a store project broken into seven stages, and the list of things that move the date. We wrote about the money separately — five multipliers of cost across 24 measured stores. This one is only about time.
One limit, without which the rest makes no sense. A deadline named before anyone has seen your catalogue and your list of integrations is a wish, not a deadline. The ranges below are counted from an approved specification, not from the first email, and they hold under conditions we name at the end.
How long a typical job takes
Working days, from the approved specification:
| Job | Duration |
|---|---|
| Nova Poshta in the checkout | 3–10 |
| Feed for Rozetka | 5–15 |
| Landing page | 7–18 |
| Exchange with 1C or BAS | 10–30 |
| Corporate site | 20–40 |
| Move from Prom.ua to your own site | 20–40 |
| Store on OpenCart | 25–45 |
| Wholesale B2B store | 30–55 |
The first thing people misread: these are working days, not calendar days. Twenty-five working days is roughly five weeks, forty-five is nine. Public holidays and vacations, yours and ours, go on top of that in the calendar.
The second: an integration is not added to a store's timeline, it is part of it. Carrier, payment and marketplace feed are the sixth stage of development. They get their own row in the table because they often arrive as a separate job on a site that already runs.
The third: the difference between a landing page in seven days and a store in twenty-five is not the number of pages. A landing page goes through five stages, and the longest of them is design; a store has seven, and each one leans on the previous. A one-page site can be built in a week even if half that week is spent waiting for copy. A store cannot be built in a week at all — not because we would fall behind, but because catalogue, payment and delivery have to come together in one working order.
Seven stages of a store, and where the clock stops
The breakdown for a store on OpenCart is 25–45 working days. For each stage, what makes it stall.
1. Brief and specification, 3–5 days. We go through the assortment, the manager's routine, and the list of payment and delivery methods. The output is the document the estimate is calculated from and the work is accepted against. It stalls while there is no price-list export and no answer on how exactly you take payments.
2. Prototype and catalogue structure, 3–5 days. Category tree, the set of attributes for the filter, product card fields, checkout steps. Approved before design: reworking structure after the front end is built is expensive. It stalls when there is nobody on your side entitled to say «yes, categories go exactly like this».
3. Design, 5–9 days. Home, category, product card, cart, checkout. A ready theme with configured colours and blocks keeps you at the lower bound; custom layouts for your brand add 5–10 days to design and markup. It stalls on a round of revisions that waits a week for an answer.
4. Building the store, 7–11 days. Theme markup, catalogue, cart and checkout, admin roles, payment, delivery and returns pages. The longest stage, and this is exactly where the core-version question surfaces — more on that below.
5. Catalogue import, 3–7 days. Mapping price-list fields, a test load, verifying the number of cards by two methods, a schedule for updating prices and stock. It stalls when attributes exist only inside a PDF price list as an image: they have to be taken apart by hand, and that is a separate line in the estimate, not «another half day».
6. Integrations and analytics, 2–4 days. Payment, delivery, GTM and GA4 with cart and purchase events, a marketplace feed, structured data, sitemap. It stalls without keys and contracts with third parties.
7. Testing, handover, launch, 2–4 days. An end-to-end order run from cart to waybill, measurements of server response time and page weight, a walk through the admin panel with your manager, handover of credentials. It stalls when the manager to walk it through with has not been hired yet.
Why the lower bound is rarely reached
Add up the minimums: 3 + 3 + 5 + 7 + 3 + 2 + 2. Twenty-five. Now the maximums: 5 + 5 + 9 + 11 + 7 + 4 + 4. Forty-five. That is neither a coincidence nor rounding — the range on the page is the sum of the stages, not a separate eyeball estimate.
The consequence is unpleasant and useful. Twenty-five days means all seven stages closed at their own minimum at once. One stage at its upper bound, and the project is no longer at its lower one. So the realistic expectation is the middle of the range, and the lower bound happens where the catalogue is small, the design sits on a ready theme, there are two integrations, and the content was ready before the brief.
The same thing with integrations, only more visible. Nova Poshta is 3–10 days, and three days here is not «if we get lucky» but a specific case: we enable branch delivery only, the order fields are already correct, and your manager keeps creating waybills in the carrier's own panel. The waybill stage simply drops out of the job. Ten days is when all three delivery scenarios are needed, plus a waybill button in the admin panel and a rebuild of the order form.
What stretches the timeline
Content is not ready at the start. The most common reason, and it is not a technical one. Pages stand empty because there is no copy and no photography; the catalogue will not load because attributes sit in a PDF. That is why in the specification for a corporate site we write down the date the content is needed from you, and what happens to the timeline if it arrives later.
Approvals that take longer than one working day. Every stage has a point where we wait for a «yes». Three approvals at a week each are three weeks that appear in no range, because a range counts work, not waiting.
A module exists only for the old core. By default we install OpenCart 4.x, the branch under active development. But the event system was rewritten in version 4, and some Ukrainian modules — separate builds for Nova Poshta, price aggregators, marketplace exports — are still released for 3.x only. In 13 of the 24 stores we measured, the core is pinned to 3.x for exactly this reason. So we walk your integration list item by item at the brief and pin the version in the specification before work starts: finding this at stage four means stopping stage four.
Keys and contracts with third parties. Acquiring, a carrier's API key, access to the accounting system — none of that is our decision or our pace. An exchange with 1C or BAS takes 10–30 days and contains, in the middle, a stage that does not depend on us: we hand over the list of catalogue discrepancies — items with no SKU, items entered twice — and closing it has to happen on the accounting side.
Scope changing mid-project. Two rounds of revisions at the design stage are included, as long as the revisions stay within the approved specification. A new product category, one more carrier, or a second language that appeared after the prototype was signed off is not a revision but new scope: a new timeline and a new estimate. It costs most with catalogue structure, which is why that is approved before design.
What actually speeds things up
Two things work, and both are on the client's side: content ready in advance, and one person entitled to decide. A priority queue at a 25% surcharge compresses the timeline by roughly a third, but only under those two conditions — you can compress your own work, not someone else's waiting.
What does not speed things up. Moving from Prom.ua looks like «switch the domain», and the switch itself does take one weekday evening. But 20–40 working days come before it: exporting the catalogue, taking attributes apart, building the store on your own domain, mapping old addresses to new ones. And after the switch we watch crawl errors for another 30 days and close whatever surfaces. Several jobs have a tail like that, and it is not part of the development timeline.
A note on wholesale. A B2B store is 30–55 days, and it runs longer not because of design. The heaviest stage there is the build, 7–13 days, because every combination of buyer group, price tier and multiple-quantity rule has to be checked separately. How many of those combinations exist is not visible from outside, which is why nobody should name a timeline for a wholesale project before the pricing scheme has been reviewed.
Honest limits
We do not name a timeline in the first email. First comes a free review of the task — 1–3 working days in which we look at the catalogue, the list of integrations and the state of the content. Then an estimate broken down by stage, and it is that estimate that becomes the timeline in the contract, together with the scope and the acceptance procedure. The warranty is 30 calendar days from the day the acceptance certificate is signed: faults that are our fault we fix free of charge.
The timeline does not include what is not in the specification: product description copywriting, catalogue population beyond the agreed volume, legal texts such as the offer and return terms, advertising after launch. On a large catalogue, product descriptions can outlive the development itself, so they are either ordered separately and in parallel, or started before the brief.
What we do not do: we do not name a date without having seen the scope, and we do not write «turnkey in a week». The ranges in this article are a reference point by type of job, not a commitment regarding your project. Your timeline is those same stages counted on your catalogue, and it takes three days to see it.
