What does an ecommerce platform cost to run, and what does it depend on?
A retailer or brand choosing between self-hosting Magento Open Source, WooCommerce, Saleor, Medusa or Sylius, a partner-built store, or a SaaS commerce platform should know that total cost depends on catalog and channel scope, who does the build and run work, PCI scope, and upgrade cadence. The open-source license is only one line in that total, because the software itself is usually free to download while the work to make it run is not. Ask every bidder to price the same catalog size, channels, currencies, and checkout design so the numbers can be compared.
The cost families are roughly these: platform licensing or subscription, hosting and infrastructure, search, cache and queue services, the build of the storefront and integrations, extensions and their upgrades, payment and PCI DSS validation work, and ongoing support. On a self-hosted stack, licensing may be zero for some products, but hosting, staging environments, and the people who patch the platform are recurring costs. SaaS platforms add subscription tiers and, as the topic facts show, Shopify lists a 0.2% fee on Plus for third-party payment providers, and Shopware lists monthly plans from 600 euros per month for Rise, 2,400 euros per month for Evolve, and custom pricing for Beyond. Confirm which tier, fees and support response times apply to your volume with each vendor in writing.
Upgrade cadence is often the largest recurring line. Adobe documents that each 2.4.x release has three years of standard support, with Magento Open Source 2.4.9 supported until May 31, 2029, and a full patch for the 2.4.x LTS line ships annually in May. Each upgrade touches PHP, database, search, and cache versions, and every installed extension. Ask a partner to state who applies security patches, how extensions are kept upgradable, and what a typical upgrade cycle includes in their fixed-scope quote, and ask a SaaS vendor which of these costs are included in the subscription.
Cost components for in-house, partner and SaaS ecommerce
This table compares who pays for each cost component under an in-house build, an implementation partner engagement and a SaaS commerce subscription, and whether each cost is one-time or recurring. Use it to ask the right questions before comparing quotes, since the same line item can sit in a license, a retainer or a transaction fee depending on the model. Note that the open-source license itself is usually free, so the recurring cost is mostly people, hosting and maintenance.
| Cost component | In-house | Implementation partner | SaaS |
|---|---|---|---|
| Platform license | Open-source license, usually no fee. Confirm any commercial edition or add-on license with the vendor. | Same open-source license. Partner fee covers scoping, not the license. | Recurring subscription, set by plan and tier. Confirm what the plan includes. |
| Hosting and infrastructure | Recurring, paid to your cloud or data center provider, sized by your team. | Recurring, usually billed to you directly under your own cloud account. | Included in the subscription. Confirm data location and any overage charges. |
| Initial build and migration | One-time, paid in internal staff time and contractor hours for catalog, customer and order migration. | One-time, fixed scope in writing before work starts. Ask for migration and testing deliverables. | One-time setup and onboarding fees may apply. Confirm migration tooling and who performs it. |
| Theme and extensions | One-time build, then recurring upkeep for each extension you rely on. | One-time build, with ongoing upgrade work priced separately if you retain the partner. | Limited to the vendor app store or plugin catalog. Custom work is often a separate fee. |
| Integrations (ERP, PIM, payments) | One-time build, plus recurring maintenance when ERP or payment APIs change. | One-time integration scope, with recurring support if retained. | Connectors may be included or charged separately. Confirm payment provider fees on top of the subscription. |
| PCI DSS validation work | Recurring staff effort for scope, script management and evidence, plus assessor fees when required. | One-time or recurring scope for checkout design, script controls and evidence. Assessor fees are paid to the assessor. | Shared responsibility is defined by the vendor. Ask for the responsibility matrix and the vendor's attestation status. |
| Security patching | Recurring, paid in internal staff time and emergency response. | Recurring if retained, covering patch testing and deployment on your infrastructure. | Included in the vendor's service. Confirm what is patched and on which schedule. |
| Upgrades | Recurring, planned around each platform release line and its support end date. | Recurring if retained, or one-time per upgrade project. | Included and applied by the vendor. Confirm downtime windows and extension compatibility. |
| Search and caching | One-time configuration, then recurring hosting for search, cache and queue services. | One-time configuration, with recurring hosting and tuning. | Included in plan limits. Confirm catalog size and request limits. |
| Support and staffing | Recurring, paid as salaries or contractors for developers, operations and on-call cover. | Recurring retainer or per-ticket support, with response times set in writing. | Recurring subscription tier, which sets support response times. |
| SaaS subscription and transaction fees | Not applicable for self-hosted platforms, except third-party payment and service fees. | Not applicable for self-hosted platforms, except third-party payment and service fees. | Recurring subscription plus transaction-based fees. Shopify lists a 0.2% fee on Plus for third-party payment providers (Shopify pricing page). |
Which ecommerce costs are one-time and which recur every year
Build work is front-loaded: discovery, data migration, theme and storefront development, payment and ERP integration, and go-live testing all land before launch and are paid once per project. The recurring side is what most budgets underestimate. Hosting, managed databases, search and cache services, monitoring, backups, security patching, extension maintenance, and annual PCI DSS evidence work repeat every year for as long as the store runs. For a self-hosted Magento Open Source store, the largest recurring line is usually the upgrade path, because the platform moves between supported release lines on a schedule you do not control. Ask each partner to price these items as separate annual lines so you can see what the platform costs to keep running.
Recurrence is tied to supported release lines. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and the listed end-of-regular-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Adobe ships a full patch for the 2.4.x LTS line each year in May, and security patches arrive at least annually for every supported line. Each store on an unsupported line must either move forward, which means regression testing of extensions and the theme, or accept unpatched risk. Confirm with your partner which release line the quote assumes, whether the upgrade is inside the fixed scope, and whether it is priced per cycle or as a retainer.
SaaS commerce costs recur by design. Subscription tiers, transaction fees and add-on modules are billed monthly or annually and rise as order volume, catalog size or staff seats grow. Shopify's pricing page, for example, lists a 0.2% fee on Plus for using third-party payment providers, which is a recurring cost that scales with revenue. Open-source platforms avoid platform license fees but move that spend into hosting, staff or partner retainers, and PCI DSS work. Model both options at your projected order volume for three to five years, and ask each vendor and partner to show the recurring cost at that volume, not only the entry tier.
What moves the ecommerce cost up or down
Most of the cost of a self-hosted store is set by a handful of early choices, not by the platform license, which is free for the open-source options. The six drivers below are the decisions that most often move the total up or down, and each one has a recurring cost attached.
Catalog size and channels
Catalog size, the number of channels, currencies and warehouses determine how much data, search capacity and pricing logic the store must run. Larger catalogs raise the cost of indexing, migration and hosting, and each extra channel adds configuration and testing. Decide early how many markets and channels launch in phase one, and ask any partner to price the catalog import and the channel setup as separate line items. Adobe's requirements for Magento Open Source, for example, include OpenSearch 3 and Redis or Valkey 9, both of which must be licensed, hosted and patched.
B2B features
Customer-specific price lists, quotes, approval workflows and credit terms are often the largest single source of custom work in a commerce build. They can be delivered through platform modules, paid extensions or custom code, and each option carries a different upgrade cost. Ask whether B2B needs are in the initial scope or the roadmap, and whether the partner will estimate them as fixed-scope work with written acceptance criteria.
Extensions and customizations
Every third-party extension and custom module is code that must be reviewed, tested and upgraded on each platform release. The count of extensions, not just the price of each, drives recurring cost. Ask for an inventory of extensions with their licenses, maintainers and the platform versions they support, and agree on a rule for when a custom change must be avoided in favor of configuration.
Payment page design and PCI scope
How the checkout collects card data determines the PCI DSS work the store must carry each year. A redirect or hosted payment page keeps card data off your servers and reduces scope, while self-built card forms expand it considerably. Check which payment page design the partner proposes, who maintains the script inventory and change detection, and whether the quote includes the assessment support you will need. Fees from payment providers are a separate recurring cost on top of the platform.
ERP and PIM integrations
Stock, prices, order status and product data flowing between the store, the ERP and the product information management system are usually the most expensive integration work. Costs rise with the number of systems, the number of data flows and the need for near-real-time sync. Ask for a written data map showing system of record for each field, the integration method, and who owns the middleware and its monitoring after go-live.
Peak traffic and hosting
Hosting cost scales with traffic peaks, cache layers and the number of always-on services. A self-managed Magento store, for example, runs Varnish as its full-page cache, while cloud-hosted Adobe Commerce uses Fastly instead, so the choice of hosting model changes who operates the cache. Decide early whether capacity is sized for average load or for a known peak, and ask for load test results and a runbook for the event. Budget for the staff time to patch and upgrade the full stack, not only the servers.
How open-source licensing differs from SaaS pricing
Open-source licenses do not carry a per-store license fee. Magento Open Source is licensed under OSL-3.0, WooCommerce under GPL version 2 or later, Saleor under BSD-3-Clause, and the core of Medusa and Sylius under MIT. Using any of these platforms for an unlimited number of stores or storefronts does not trigger a license invoice from the project itself. The money goes elsewhere: hosting, implementation, extensions, security work and upgrades, which are paid to you or to a partner. Medusa is the exception to check carefully. Its Enterprise Edition features based on role-based access control require a commercial agreement with MedusaJS, Inc., so if your B2B or back-office design depends on those roles, ask for that agreement in writing before the architecture is fixed. Confirm the license terms of every extension you plan to use, since each one carries its own license.
SaaS commerce is priced differently, and the fees recur for as long as the store runs. Shopify's pricing page lists a 0.2% fee on Plus for using third-party payment providers, a transaction-linked cost that grows with sales volume. Shopware's pricing page lists Rise at 600 euros per month, Evolve at 2,400 euros per month with B2B quotes and approvals, and Beyond at custom pricing with 1-hour 24/7 support. These are list prices at the time of research, not quotes. Plans, tiers, transaction rates and included support change, so confirm each figure on the vendor page and in a written proposal before you set a budget.
When comparing the two models, put both sides on the same 3-year total: the open-source column includes hosting, partner scope, extension licenses, PCI DSS evidence work and annual upgrades, while the SaaS column includes subscriptions, transaction fees, app subscriptions and any agency work. Ask each vendor which items recur, which are one-time, and what increases the bill as order volume or the catalog grows. Illustrative example: a store with high order volume may find a percentage-based fee larger than a fixed hosting contract, while a small store may find the reverse. Only your own volumes and scope can settle that.
How the three options change the budget profile
Your own engineering team selects, installs and runs the open-source platform. Licence fees are usually zero for the core, so the budget is almost entirely people, infrastructure and the time spent keeping the store current. Most of the spend lands in the first year as build effort, then continues as a standing team that patches, upgrades and supports the store.
- Hosting: Your team provisions, monitors and scales the servers, databases, search, cache and queue services. Cloud or data centre bills recur every month.
- Patching and upgrades: Security patches and minor releases must be tracked and applied by your staff. Adobe, for example, documents three years of standard support per 2.4.x Magento release, so upgrade planning becomes a recurring project.
- PCI DSS evidence: Your organisation owns the scope, the payment page script controls and the self-assessment questionnaire. This work competes with product priorities for the same people.
- Extension compatibility: Every third-party extension or custom module must be retested on each platform upgrade, and that testing is an ongoing internal cost.
- Main budget risk: Key-person dependency. When the engineers who built the store leave, upgrades slip, and an unpatched store becomes an unbudgeted emergency.
Ask your finance and engineering leads to estimate the recurring team size separately from the one-time build, because that recurring figure is the one most often underestimated.
An implementation partner plans, builds, hardens and documents the platform inside your own cloud account or data centre, and then supports it under a fixed scope or a retainer. You keep ownership of the hosting, data and licences. The partner's fee is the largest one-time line, and ongoing support is usually a separate, optional recurring agreement.
- Hosting: Your infrastructure bill remains yours. The partner builds the environment and documents it, so the hosting cost is the same as in-house, but the design risk is shifted to the partner's written scope.
- Patching and upgrades: Responsibility depends on the contract. Confirm whether patching sits in a retainer, in a separate upgrade project, or stays with your team.
- PCI DSS evidence: The partner can prepare checkout design, script management and change detection evidence for your assessor, but it does not issue the validation. Your organisation remains accountable for scope.
- Extension compatibility: Ask how extensions are selected, tested and kept upgradable before go-live, and who retests them after each release.
- Main budget risk: Scope creep and unclear handover. A fixed scope limits surprises only if change requests, acceptance criteria and documentation are agreed in writing before work starts.
Request a quote that separates one-time build work, infrastructure set-up, and any recurring retainer, with each deliverable listed.
A SaaS commerce platform is paid through a subscription, often with additional fees tied to transactions or to features. The vendor hosts, patches and upgrades the platform, so the budget shifts from infrastructure and staff toward recurring fees that grow with sales volume and plan tier. Setup is usually shorter, but the total cost depends on contract terms that you should read closely.
- Hosting and patching: The vendor carries these, and the subscription covers them. Your team's role is configuration and integration.
- Subscription tiers: Pricing rises with plan level and support response time. Shopware's public pricing, for example, lists monthly plans from 600 euros to custom pricing for its highest tier, with different support response targets at each level.
- Transaction and payment fees: Some platforms add a percentage on payments processed through third-party providers. Shopify's pricing page lists a 0.2% fee on Plus for using third-party payment providers.
- PCI DSS evidence and extensions: Check what the vendor's responsibility matrix covers, and which app or extension costs sit outside the base plan.
- Main budget risk: Recurring cost growth. Fees that scale with revenue, add-on apps and plan upgrades can exceed a self-hosted run cost at high volume, and migrating out later is itself a project.
Ask for a three-year cost model at your projected order volume, including every transaction fee, app and support tier, not only the headline monthly price.
Why PCI DSS work and upgrades are the cost most teams underestimate
A self-hosted store takes on PCI DSS responsibility for every part of the checkout it controls, and that responsibility is usually larger than the platform licence line in a budget suggests. The questionnaire type and the effort both follow from checkout design. If the card fields are hosted by a payment provider, the store's scope is narrower; if the store builds its own card forms or posts card data through its own servers, the scope grows and so does the recurring evidence work. Before costing anything, ask the partner which self-assessment questionnaire the design implies and who signs it each year, because that answer sets the internal hours and any assessor fees.
On a self-hosted Magento Open Source store, two requirements turn into recurring work. The first is script management on payment pages, covered by PCI DSS 6.4.3, and the second is change detection on those pages, covered by 11.6.1. Each third-party script on checkout needs an inventory, an authorization and a monitoring process, and the team must be able to show that process working. Magento 2.4.7 runs Content Security Policy in restrict mode by default on storefront and admin payment pages, so an extension or theme that loads an unlisted script can break checkout after an upgrade. Confirm with the partner how CSP policies are maintained and tested before each release.
Upgrade cadence is the recurring cost that most budgets miss. Adobe's lifecycle policy gives each 2.4.x release three years of standard support, and the 2.4.6 line reached end of regular support on August 11, 2026, so a store still on it has no vendor fixes for its checkout path. Each upgrade also re-tests every extension, and extension compatibility must be checked against the required PHP, MySQL or MariaDB, OpenSearch and Varnish versions listed for the target release. Ask for a written patch and upgrade calendar, a named owner for PCI evidence refresh, and an estimate of regression testing per release before you compare totals with a SaaS subscription. For the detailed control steps, see the sibling topics on PCI DSS 6.4.3 and 11.6.1 for Magento and on PCI DSS SAQ eligibility for self-hosted checkout.
How to build your own ecommerce cost estimate
This sequence turns a vague budget into a costed scope you can compare against SaaS fees and put in front of implementation partners. Each step produces a written input, and the final comparison shows where recurring costs sit over the life of the store.
Define catalog, channels, currencies and B2B needs
Start by writing down the size of the catalog, the sales channels (own storefront, marketplaces, point of sale, B2B portal), the currencies and markets, and any B2B features such as customer-specific price lists, quotes or approvals. Your merchandising and commercial leads own these answers, and your engineering lead checks them for feasibility. The step is done when every channel and market has a named owner and the B2B requirements are either listed or explicitly ruled out, because each one changes the platform, extension count and build effort.
Choose the checkout and payment design
Decide how card data flows through checkout, such as redirect or hosted payment pages, embedded fields, or a self-built form. Your payments lead and security lead make this call with your payment providers, since it determines which PCI DSS self-assessment questionnaire applies and how much of the payment page you must control and monitor. Record the providers, the payment methods per market and the expected transaction mix. The step closes when the design is written down and a security reviewer has signed off on the scope it implies.
List every integration and its data owner
Inventory each system the store must exchange data with: ERP for stock and order status, PIM for product data, tax, shipping, payment gateways, email and CRM, and analytics. For each one, record the direction of data flow, the update frequency and the team that owns the interface. Integration work is often the largest variable in a quote, so ask each owner to confirm the API or file format they will provide. The step is complete when every integration has an owner, a data flow diagram and an agreed acceptance check.
Set hosting and environments
Map the environments your team needs, usually development, staging and production, and the supporting services each one requires. For self-hosted options this includes the database, search, cache, message queues and background workers. Check the vendor's system requirements for the exact versions and memory needs; for example, Adobe publishes a supported combination list for each Magento Open Source release, and Saleor's Docker Compose setup asks for at least 5 GB of memory. Ask your infrastructure team to price cloud or data center capacity for each environment and to estimate ongoing patching and monitoring effort. The step closes with a hosting diagram and a capacity sheet that the quote can reference.
Count extensions, themes and custom work
Build a list of every extension, theme, module and custom feature the store needs, and mark each as available off the shelf, requiring configuration, or requiring custom code. For each custom item, note who will maintain it after launch and how it will be tested during platform upgrades. Extensions carry recurring license and compatibility costs, so record the vendor, license terms and supported platform versions. The step is done when every item has a classification, an owner and an upgrade test plan.
Add PCI DSS and accessibility work
Add the compliance workstreams to the scope: PCI DSS controls for payment pages and scripts, change monitoring, access control, logging and the evidence you will collect for your assessor or acquirer, plus accessibility work on storefront templates and checkout against WCAG-based expectations that apply in your markets. Name the people who will prepare evidence and who will review it. Ask your assessor or legal counsel which requirements apply to your store. The step closes when each compliance item has a scope statement, an owner and an evidence list. DeployOpen prepares systems and evidence for these assessments but does not issue audit reports or certifications.
Plan upgrades for each supported release line
Pick the release line you will run and read its support window before you cost anything. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, with end-of-regular-support dates such as May 31, 2027 for 2.4.7 and May 31, 2029 for 2.4.9. Plan a recurring budget for patching, minor upgrades and a major platform move when the line reaches end of support, and confirm how often each open-source project publishes security fixes. The step closes with a yearly upgrade calendar and a line item for testing extensions against each release.
Compare against SaaS fees at expected volume
Build a five-year view that puts the self-hosted model side by side with a SaaS commerce subscription, using your expected order volume, the SaaS plan tier you would need, and any transaction or payment-provider fees. For example, Shopify's pricing page lists a 0.2% fee on Plus for using third-party payment providers, and Shopware lists monthly plan prices with different support response times. Include self-hosted hosting, engineering, extension and compliance costs on the other side. The step is complete when both models show one-time and recurring costs, and the break-even volume is visible to the decision makers.
Request a written quote with scope and exclusions
Ask every implementation partner for a fixed-scope written quote that lists deliverables, acceptance criteria, timelines agreed before work starts, assumptions about your environment and the items excluded. Check that the quote states who applies security patches, how extensions are kept upgradable, what is included in testing and hand-over, and whether ongoing support is a separate retainer. Compare quotes against the same scope sheet from the previous steps so that differences reflect real choices rather than unstated assumptions. The step closes when every quote can be traced line by line to your requirements and the exclusions are clear enough that nothing important is left out.
What to ask for in a written ecommerce quote
Compare partner quotes only after each one describes the same scope in writing. DeployOpen does not publish a price list, and a quote follows from the scope agreed with the client. Most engagements are fixed-scope, so the document you ask for should list the platform and version, every integration by system name (payment provider, ERP, PIM, tax, shipping, email), the environments to be built (development, staging, production, disaster recovery), and the hosting account or data center where they will run. A quote that names only "checkout and catalog" cannot be compared with one that lists each connector and its direction of data flow.
Ask each bidder to state the PCI DSS responsibility split in a table: which controls the partner implements, which the client's hosting provider or payment provider covers, and which stay with the client's own team, including script management and payment page change detection. Also ask for patch and upgrade terms: who applies security patches to the platform and to each extension, how many upgrade cycles are included, and whether testing of extensions after a core upgrade is in scope. Support hours, response expectations and the handover of runbooks and credentials should appear as separate lines, so the cost of running the store after launch is visible.
Require a clear split between one-time and recurring items. One-time work usually covers discovery, build, data migration, testing and launch. Recurring items usually include hosting, monitoring, backups, licenses for any commercial extensions, security testing and support. Ongoing support, upgrades and continuous testing are available as retainers, so ask whether each recurring item is priced as a retainer, a separate fixed fee or left to the client. Confirm that the timeline and acceptance criteria are written into the same document as the scope, and that any change request has a stated process for re-pricing.
Ecommerce cost questions buyers ask before hiring help
How much does self-hosted ecommerce cost compared with SaaS?
Self-hosted ecommerce usually costs more up front and less in predictable subscription fees, but the total depends on your own volume, hosting and team. The cost components are the platform license (zero for MIT, BSD-3-Clause, GPL and OSL-3.0 code, though some vendors sell commercial add-ons), infrastructure, implementation, extensions, PCI DSS work and ongoing upgrades. SaaS commerce adds subscription fees that scale with plan tier and often transaction-linked charges. For example, Shopify's pricing page lists a 0.2% fee on Plus for using third-party payment providers, and Shopware's pricing page lists plans from 600 euros per month (Rise) to custom pricing (Beyond). Build a three-year model with both options, using quotes for your own volume, and ask each SaaS vendor for every fee that applies to your checkout design.
Is Magento Open Source free to run?
The software license is free, but running it is not. Magento Open Source is licensed under OSL-3.0, so you pay nothing to download or use it, yet you still pay for hosting, search, caching, queues, monitoring, developers and security patching. Adobe's system requirements for 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30, and Adobe supports only the listed combinations, so each of those components is a running cost to plan for. Confirm with Adobe which release line and support window applies to your store, since Adobe's lifecycle policy gives each 2.4.x release three years of standard support.
How long does an ecommerce build take and what does it need from our team?
The timeline depends on catalog size, integrations, checkout design, the number of markets and how many extensions need custom work. A fixed-scope engagement starts with a written scope, deliverables and timeline agreed before work begins, so ask for those in writing rather than relying on a generic duration. Your team typically needs to supply a product owner who makes decisions on catalog and checkout rules, an owner for payment provider accounts, access to the ERP or PIM the store must connect to, and staff to review test results and sign off on cutover. Ask any partner to list those inputs by name and date in the proposal.
Can our own developers do the work?
Yes, if they have hands-on experience with the chosen platform's stack and can own it after launch. Magento needs PHP and database skills, Saleor needs Python, Django and GraphQL with PostgreSQL, and Medusa needs Node.js and TypeScript. A self-hosted Medusa deployment alone needs PostgreSQL, Redis, and two Medusa instances (one server, one worker), with database credentials, COOKIE_SECRET and JWT_SECRET values set. Be honest about bench depth: a store that needs security patches, load testing before peak trading and a documented runbook is a team effort, not a one-person job. Many organizations split the work, keeping day-to-day ownership in-house and buying a partner for the build, hardening or upgrades.
What drives PCI DSS cost for a self-hosted store?
PCI DSS cost is driven mainly by how your checkout handles card data. A store that sends customers to a hosted payment page usually has a smaller scope than one that posts card data through its own server or builds its own card form, and the self-assessment questionnaire type follows from that design. Other cost drivers are payment page script management, change detection on the payment page, the hosting environment, and how often you need an independent assessment. Confirm with your acquirer which self-assessment questionnaire applies, and confirm with a qualified security assessor how your payment page controls will be evidenced. For Magento, Adobe's developer documentation notes that Content Security Policy headers are supported from 2.3.5, which helps with script control.
What recurring costs should we budget for after launch?
After launch, recurring costs fall into four groups: hosting and managed services, platform upgrades and security patches, extension and integration maintenance, and support or retainer hours. Hosting includes compute, database, cache, search, queues and backups, and it rises with traffic and catalog size. Upgrades recur because each platform publishes new releases on its own schedule: Magento 2.4.9 was released in May 2026, and Adobe says full patches for the 2.4.x LTS line ship annually in May, with security patches at least annually for all supported release lines. Payment fees, PCI assessment fees and support retainers also recur. Ask any partner for a quote that separates one-time implementation from these monthly and annual items.
How DeployOpen scopes, delivers and supports ecommerce implementations
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted commerce platforms inside your own cloud accounts, data centers or air-gapped networks. For cost decisions, we start by turning the build, partner and SaaS options into a written scope with the cost components visible, so each figure in your comparison can be traced to a named responsibility.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which cost lines we would carry, such as hosting setup, extensions, payment page work and upgrades.
- We confirm which costs stay with your team, your payment provider or a platform vendor, so the comparison is complete.
How we build
- We implement the chosen platform in your environment, with hosting, databases, caching and background workers configured for production.
- Extensions and integrations are reviewed for upgrade impact, so the cost of future upgrades is visible before go-live.
- Security testing of the storefront, checkout and APIs runs alongside the build, with findings tracked in the written scope.
How we hand over
- Handover includes documentation of the architecture, configuration, hosting cost drivers and the upgrade path for your team.
- We prepare the controls and evidence that support a PCI DSS or accessibility assessment, without issuing any audit report or certification.
- Runbooks cover backups, restores, patching responsibilities and who pays for each recurring service after handover.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers, priced separately from the build.
- Retainer scope can be set to match the recurring cost lines your quote identified, such as patching and platform upgrades.
- We recommend reviewing the recurring cost model with your team at each major platform release to keep the comparison current.
