Compare the same order
Start with the specific purchase journey your business needs. The customer selects a product variant, sees availability, enters an address, receives a delivery price, pays and receives confirmation. A staff member finds the order and sends it for picking. If one proposal calculates delivery automatically while another has a manager confirm it by phone, the proposals describe different processes.
Four columns help clarify each line: the result, materials supplied by the client, exclusions and the acceptance method. For example, “catalogue import” means uploading agreed fields from a specified file; the client supplies images and SKUs; correcting original descriptions is excluded; acceptance uses an import report and selected product pages. This describes the scope much more precisely than “content entry”.
Also check which screens are designed separately. A ready-made product page may need changes for bundles, custom sizes or sales by the pack. If these rules emerge after the design is approved, the programming work changes too. They need to appear in the shared table before comparing totals.
The table below is a starting point. Add adjacent columns for each contractor’s answer and price. An empty cell is an open question, rather than work assumed to be included.
| Estimate line | What to compare | How to accept the result |
|---|---|---|
| Catalogue | Fields, variants and images; who corrects the source file | Import report and product pages with agreed variants |
| Exchange with accounting and inventory software | Directions, fields and frequency; who handles errors | Stock changes reach the site and orders appear in the accounting system |
| Payment | Provider, confirmation and cancellation; whether refunds are included | Order state matches the confirmed transaction |
| Delivery | Regions, rates and restrictions; manual or automatic calculation | An agreed address receives the expected method and price |
| Handover | Accounts, instructions and project code; platform provider exclusions | The owner can sign in and perform the agreed operations |
Specify what each integration transfers
“Integration with 1C” can cover several separate tasks. Where do products and prices come from? Are orders sent back? Where are discounts calculated? Who changes a return’s status? How does an employee learn that the exchange has stopped?
Ask for the system and its configuration, transfer directions, fields, the method used to trigger exchanges and error handling. If the contractor has not yet received access to documentation or a test system, a final integration estimate remains an assumption. A separate investigation can resolve this, with a clear deliverable: an exchange diagram, identified limitations and an updated implementation cost.
Payment needs the same examination. Opening a payment form and receiving confirmation on the server are separate parts of the work. For example, YooKassa describes incoming notifications that tell a store about payment status changes. The estimate should include checking confirmation, cancellation and state recovery after an interrupted customer redirect. The chosen provider determines which specific scenarios apply.
Distinguish an installed module from a finished feature
A ready-made extension can reduce development work. The proposal should still name the extension, its licence and the configuration performed by the contractor. Any customisation adds its own scope and responsibility for compatibility after updates.
Licensing terms differ. For each component, specify how it is purchased and renewed, access to updates and support. “All plugins included” without a list leaves future costs and account ownership unclear.
Ask whose account will purchase the components and whether another developer will be able to obtain updates after the contract ends. This affects maintenance even when two proposals have the same initial price.
Separate launch costs from ongoing operation
Keep one-off work in the first part of the comparison: planning, design, development, data preparation, migration and launch. Put recurring costs in the second: the platform, server, extension licences, messages, maintenance and external service fees. Their charging bases differ: a subscription, transaction count, turnover or resource usage.
Use the same period and assumptions for every option. The model consists of one-off development, recurring payments for that period and variable costs at a stated number of operations. If sales volume is unknown, express the variable part as a formula. An invented turnover forecast creates false precision.
Keep the payment provider’s fees and technical support costs separate. The former depends on payments and connection terms; the latter on a contract for specialist work. This separation shows which costs can change with the technology and which depend on trading operations.
Clarify when the price can change
A fixed price requires an agreed scope. Hourly billing requires rules for recording work and approving expenditure. An uncertain project can combine the two: investigation first, followed by fixed-price implementation of understood parts. The crucial question is which event permits the amount to be revised.
If the client adds a delivery method, the change should have a description, an estimate and approval before implementation. If the developer corrects a failure to meet an agreed scenario, the contract should govern that correction. Distinguishing these situations reduces disputes over additional work.
Be specific about handover too. Agree on access, source code where it is created for the project, staff instructions and backup procedures. Handover for a cloud platform differs from a custom application: access to an account and its data does not itself provide the platform’s source code.
Make a decision after the comparison
Once proposals are comparable, the reasons for their differences become visible: a simpler process, a ready-made solution, more manual work for the client or additional technical commitments. The choice then depends on which option the company can maintain after launch.
If a proposal remains unclear, send the contractor a table with specific gaps. “Everything is included” does not resolve questions about importing data, returns or restoring the store. Both sides need a written basis for accepting the result.
An online store technical specification helps define the scope being compared by connecting trading rules with acceptance conditions.
If you are preparing a store and want to understand the scope, send us a description of your trading process and launch requirements. At pommeDeTerre, you can discuss online store development: which parts the first release needs and what source data a meaningful estimate will require.