DDRW’s starting estimate for developing a small online store is from RUB 450,000. It applies to a store based on ready-made components: a catalog with one product structure, a product page, cart, checkout and integration with one payment service. Products are imported from a prepared file in an agreed format. The current scope is listed on our online store and product showcase development page.
This estimate excludes licenses and payment service fees, complex 1C exchange, loyalty programs, marketplaces, product content preparation, hosting and maintenance. For a specific project, the agreed scope determines the final cost: which products are sold, how the buyer places an order and what the team receives at launch.
To estimate your store, break the budget into these parts. This clarifies which work is needed now, what can wait and why two stores that look similar receive different estimates.
Clarify the outcome being estimated
An online store can mean different sales models. A showcase that sends a request to a manager and a store with self-service purchasing need different work. This is about more than a payment button: the whole journey from selecting a product to accepting an order changes.
| Format | What buyers do on the website | What affects the estimate |
|---|---|---|
Showcase with a request | Explore products and send a selection or enquiry to a manager | Catalog structure, product selection, request contents and processing |
Retail store | Choose a variant, build a cart and place a purchase | Calculation rules, payment, delivery, notifications and order management |
Store with complex rules | Buy under an individual price list, order packs or configure a product | Additional sales rules, external data and testing their combinations |
The table shows scope differences, rather than separate pricing packages. A showcase with complex equipment selection, for example, may require more work than a store with a standard range and ordinary purchasing.
The implementation approach also affects the estimate. If the chosen foundation already supports the required process, some work becomes configuration and testing. Required customizations are estimated separately. We compare approaches in our article on choosing an online store platform.
Which work makes up the store development cost
A store estimate should identify a concrete deliverable for each block. “Catalog” is too broad: it can mean an ordinary product list or several distinct structures with variants and separate purchase terms.
| Block | What should be ready at launch | What changes the work volume |
|---|---|---|
Catalog and product page | An agreed presentation of products, specifications, variants and availability | Different product types, sales units and complex property combinations |
Catalog data | Initial import of the agreed range | File readiness, variant relationships and the quality of images and descriptions |
Purchase interface | Pages and states from product selection to order confirmation | Special discounts, bundles, customer groups and unusual errors |
Payment and delivery | Connected payment and order-receiving methods | Number of services, availability rules, delivery calculation and product restrictions |
External business systems | An agreed exchange scope with other systems | Data contents, connection availability and custom rules |
Launch preparation | Tested journeys, settings and handover to the team | Number of condition combinations, old-store migration and staff readiness |
Design, development and testing may be separate stages. The estimate should still make clear which store parts they cover. A product-page mockup and a working size selector with correct stock are different outcomes, even though they visually belong to one screen.
Why the number of products does not determine a store’s price
Item counts matter for content population, data processing and load testing. They do not describe the complexity of sales rules. A thousand consistent products from a clean file and a few dozen complex configurations produce different work.
Imagine two hypothetical clothing catalogs with the same number of models. In the first, each model has one price and straightforward sizes. In the second, price, stock and photography depend on color–size combinations, and some combinations cannot be ordered. The second requires correctly linking more data and testing more purchase states.
Product data preparation is a separate budget item. Importing a ready file and reconstructing a catalog from scattered spreadsheets, photo folders and supplier descriptions are not the same task. Distinguish import configuration from work to bring data into an agreed format.
Ask the estimate to separate source-file transformation, import and result checking. If data comes from several suppliers, specify the number of formats. If specification names must be standardized, agree on the processing volume and verification method. Additional work then has a clear outcome: prepared fields, matched variants and correctly imported product pages.
How cart, payment and delivery expand the scope
An ordinary retail purchase needs one agreed calculation rule set. Additional conditions expand the work: discounts based on cart contents, exceptions for particular brands, minimum order values, pack multiples or customer-group prices.
The estimate must describe which combinations should work together. Supporting promo codes and bundle sales separately does not establish how an order using both should be calculated. Agreeing on that rule affects implementation and verification alike.
Distinguish payment integration from payment-processing expenses. Development work belongs to launch, while payment-service commission arises on sales under the relevant contract. Store development cost and transaction-related costs must therefore be calculated separately.
Delivery has a similar distinction. Connecting a receiving method, building a custom calculation and paying for transport are different expenses. If delivery availability depends on region, weight, cart contents or warehouse, include those rules in the estimate’s scope.
Why integration estimates follow a review of source systems
“Connect 1C” is insufficient for pricing. A one-time catalog import and ongoing exchange of products, stock, orders and updates require different volumes. The specific business-system configuration, available exchange mechanisms and responsibility for changes on the other side matter.
Separate two tasks in the estimate: connecting the store and changing the business management system. If another team handles the latter, its work and involvement must remain in the overall launch plan. Otherwise, the finished storefront will wait for an unagreed connection.
Where restrictions are unknown, start with an integration review that has a concrete deliverable: a confirmed exchange method, available data list and identified customizations. Refine the estimate afterwards. Our article on online store integrations examines exchange principles in detail.
What a “turnkey” online store price means
“Turnkey” becomes useful when it specifies a ready-to-operate outcome. For example: the agreed catalog is imported, supported purchase methods work, notifications are configured and an employee can process an order. The list depends on the project.
Content population boundaries are particularly important to the budget. Establish who prepares text, edits images, checks specifications and corrects invalid data. “The product page is ready” can mean a developed template or a fully populated page; those tasks cost different amounts.
The same applies to migrating an old store. Exporting data, matching new fields and migrating page URLs are independent tasks. Include them in the appropriate estimate lines when replacing a live website.
If the scope is not yet defined, use “An online store brief: what to agree before development” to prepare it. A cost calculation needs an agreed deliverable list with specified content and integration volumes.
Separate launch from first-year costs
Online store development cost does not cover every expense after publication. Three groups are useful for planning: one-off work, recurring payments and expenses dependent on the number of operations.
| Group | Examples | What to clarify |
|---|---|---|
One-off work | Development, catalog preparation, data migration and agreed service connections | Whether all required work is included in the launch estimate |
Recurring payments | Platform plan, hosting, maintenance and product renewals | Billing period, renewal terms and payment responsibility |
Per-operation expenses | Payment fees, paid messages and individual connected-system services | The event that incurs a charge and what determines its amount |
Not every line applies to every store. Hosting may be included in a hosted service plan, for example, so it should not be added a second time. For an installed solution, some maintenance may be included in the support contract — check before calculating.
Billing periods matter. Tilda’s pricing page presents monthly and annual payment separately. When comparing services, consider the actual payment and its period, rather than only the prominent monthly figure. Tilda pricing.
The first-year expense plan combines one-off launch costs, payments for the chosen period and projected per-operation expenses. Account for advertising and new content production separately: they relate to running the store and attracting buyers, rather than automatically being included in development.
What can wait to reduce the first-launch scope
Start with the minimum that gives buyers a clear offer and lets the team receive and process an order. A complex loyalty program, personalized recommendations or extra sales channels can be estimated as later stages if the main process does not depend on them.
Every such decision affects the team’s work. If automated catalog updates are postponed, establish who will update data manually, how often and whether this is viable for the sales volume. A manual operation reduces development work only when the business can actually perform it.
Keep final-total validation, supported ordering methods and error handling in the launch scope. Otherwise, reducing the estimate leaves problems in the main sales process. It is better to reduce the first version through optional features with a clear cost for adding them later.
If requirements change during work, record the difference from the agreed scope. Moving from one retail price to individual price lists, for example, affects data, buyer access, order calculations and testing. Several store parts change even if only one new line appears in the interface.
How to get an estimate for your online store
For an initial estimate, send a catalog sample with ordinary and complex products, your chosen ordering method, external-system list and a description of content readiness. State separately whether this is a new store or a replacement and what the team can do manually at the first stage.
The reply should show the agreed launch cost, separately estimated work and recurring payments. For unconfirmed integrations, it should explain what must be checked before a final estimate. This lets you discuss specific budget changes and choose the first version’s scope.
The DDRW online stores and showcases page lists the current starting estimate and its scope. Send sample data and a sales scenario through contacts — reviewing them will clarify what your store’s estimate includes and which parts need separate assessment.
