Judge an e-commerce agency’s offer by the scope of work, how it will be accepted and the cost of later maintenance. Before comparing prices, check whether the contractors quoted the same features, integrations and data to migrate. A good offer lets you establish what you will get, how you will verify it and who will be responsible for the store after launch. A general promise of a “ready store” isn’t enough.
Compare the same scope
One agency may quote for configuring a ready-made theme, another for designing views and implementing them. Both items are often called “graphic design”. Similarly, “ERP integration” can mean setting up an existing add-on or building synchronisation with exception handling. At that point the price difference tells you nothing yet about value for money.
Prepare a shared table of requirements. For each item, ask for it to be marked: included, out of scope, optional or needs analysis. Add an outcome that can be checked. Instead of “discount handling”, write down a sample cart and the price calculation rules. Instead of “migration”, list products, customers, orders, images, content and URLs.
Also check the obligations on your side. Who provides descriptions and photos? Who cleans the product data? Who approves the redirect map? If the contractor expects to receive finished materials while the company expects them to be prepared as part of the price, the schedule stops being credible before work even starts.
Code rights, licences and project access
Separate three issues: the ability to use the software, access to its sources and the right to have someone else make changes. These are different questions. The store may work correctly, and yet its owner may lack deployment instructions, the module vendor account or the sources needed to rebuild the theme.
Ask for a list of the contractor’s own elements, code created to order and third-party components. Each should come with a description of the terms of use, updates and handover. Don’t assume that paying the invoice automatically settles all rights. The rules for transferring rights and licences follow from the contract and the law – in Poland, the Copyright and Related Rights Act. It is worth having the clauses for your specific project checked by a lawyer.
Organisationally, the domain, hosting, payment and analytics accounts should stay under the company’s control. The contractor can get their own access. Also agree on repository access, how often the code is handed over and how documentation is stored. Your ability to take delivery of the project shouldn’t depend on whether the same developer is still working on it a year from now.
How changes will be billed
A fixed price makes spending easier to plan if the scope and assumptions are well described. Hourly billing gives more freedom when requirements are still being discovered, but it needs transparent reporting and limits. A mixed model can combine quoted stages with a separate budget for tasks that can’t yet be precisely defined.
Ask what happens when a new need comes up. There should be a point where the impact on price and deadline is assessed, and a person who approves the change. The contractor shouldn’t learn about approval from an ambiguous conversation, and the client shouldn’t learn about the cost only from the invoice. Also agree how the used and remaining budget will be reported.
Separate fixing a mismatch with an agreed requirement from extending a feature. For example: if an accepted scenario provides for a discount above a threshold, calculating it incorrectly needs fixing. Adding a different threshold for a new customer group may be a change of scope. A well-described acceptance example helps settle such situations without arguing over what “discount” means.
What exactly “done” means
Acceptance should be based on checkable scenarios. The customer adds a product, chooses a variant, places an order, pays, receives a message, and the order reaches the fulfilment system. The provider’s confirmation must be saved correctly. A screenshot of the cart doesn’t prove this process works.
Require a description of how mobile devices, integrations and exceptional situations will be tested. What happens when a payment is interrupted? How will the store handle a temporary loss of connection to the ERP? Who will see the information about an order that wasn’t passed on? These questions reveal scope that isn’t visible when the best-case scenario is presented.
If the offer includes a performance promise, ask for the measurement conditions: catalogue size, load, server configuration and the views measured. “A fast store” is an opinion, not an acceptance criterion. Also agree who provides the test data, how much time the company has to check a stage and where it reports comments.
At the end of a stage you should have a working result, a list of known limitations and code that matches what was deployed. If the project can’t be run outside its author’s computer, taking it over remains difficult regardless of how good the presentation was.
Support after launch
Separate fixing defects covered by the agreement from ongoing maintenance and further development. Ask how the contractor treats a failure after an external module update or a change in the provider’s API. Not all future problems come from implementation defects. The offer should explain who diagnoses them and on what terms the work is billed.
Response time is not resolution time. Acknowledging a report within an hour doesn’t mean payments are restored within an hour. Agree on support hours, an emergency channel, priority levels and the escalation path. If the store also sells at weekends, check whether the contract provides any support then.
In the maintenance budget include updates, monitoring, backups and restore tests. Find out who keeps track of expiring licences and certificates. Also ask about reporting: it should be clear what work was done, which problems remain and what needs the store owner’s decision.
How the cooperation will end
Agree the terms for handing over the project before signing the contract. You need the sources, up-to-date documentation, a list of services, deployment instructions and a description of the integrations. On top of that come the rules for handing over work that has started but not yet been accepted. The form and effects of terminating the contract need to be checked against its specific clauses.
Check whether time is set aside for the new team’s questions and how much it will cost. Handing over an archive without configuration information may make it impossible to recreate the environment. A good technical criterion is whether a person who hasn’t worked on the project before can get a copy running.
If you are changing contractors right now, a separate checklist is in the article on taking over a store from an agency. It is also worth using when assessing a new offer, before any access problems arise.
Questions you can send to contractors
- Which features and views does the quoted price include, and which are excluded?
- Which assumptions still need confirming before the deadline is set?
- What exactly does each integration cover, and who is responsible for its errors?
- What data do you migrate, and how will you check the migration is complete?
- What materials and decisions do you expect from our team?
- How will a change of scope be priced and approved?
- Which scenarios will decide acceptance of the store?
- On what data and devices will you test?
- Which licences need renewing, and who will own the accounts?
- What code rights and materials will we receive at the end?
- What are the support hours and response times for a sales outage?
- How much does maintenance cost and what does it cover over the following years?
- What does handing the project over to another contractor look like?
Keep the answers with the final version of the offer. If an important point was agreed in a meeting, ask for it to be added to the document describing the scope. After a few months both sides may remember the conversation differently, and the team delivering the project may not have been involved in the sale. A written example and acceptance criterion reduce this risk.
Frequently asked questions
Does the cheapest offer always mean a smaller scope?
No. The contractor may have a ready solution and experience with a similar process. Still, ask them to confirm the same requirements and maintenance costs before treating the difference as a saving.
What should the agreement on code rights include?
You need to distinguish bespoke code, third-party components, sources and the ability to make further modifications. Agree the scope of rights or licences and when and on what terms you obtain them. A lawyer should check the clause against your specific contract.
Is it worth paying for pre-implementation analysis?
Yes, if it results in requirements, risks and a scope that lets you compare options. Before buying, agree which documents you will receive and whether you can use them when choosing a different contractor.
How do I check an agency’s past projects?
Ask which part of the store shown they were responsible for and when they did the work. With the client’s consent, ask for a conversation about communication, billing for changes and support after launch. The look of a website doesn’t show the quality of the cooperation.
Before you choose, collect the answers in one document and mark the items that remain unclear. If you need an independent assessment of the scope and order of work, see support with store growth decisions.