Why compare cost shape instead of cost figures?
This site publishes no prices, rates, day rates or payment terms, so this comparison cannot and does not state what any route costs. What it can do honestly is describe the shape of the cost: when money is committed, how spending recurs, and what makes it scale up or down. Shape is enough to check against your own numbers, which a borrowed figure from someone else's engagement never is.
Which three routes does this comparison cover?
The same three routes from four ways to get a web-to-print platform, collapsed to the two that carry genuinely different cost shapes against a commissioned build: a subscription platform you configure, an in-house team you employ, and a platform you commission from a specialist agency. A generalist development shop's cost shape is close enough to a commissioned agency's, project-based with a learning-curve premium, that it is not repeated as a fourth column here. When not to hire us covers the case where none of the three routes is the right next step yet.
How does the cost shape differ across the three routes?
Read the table by row. A single number from any one vendor, team or engagement would tell you less than the shape of where the spend sits and when it moves.
| Cost category | A subscription platform | An in-house team | A commissioned platform build |
|---|---|---|---|
| When cost starts | At signup, before the first order ships | Before any revenue, during hiring and setup | After discovery, before launch |
| How it recurs | Every billing cycle, for as long as you use it | Continuous payroll, whether or not the team ships | Mostly one bounded project cost, then optional ongoing work |
| What makes it scale | Usage the vendor's plan prices: seats, orders, stores or stores' volume, on that vendor's own terms | Headcount, not order volume | Fixed at commissioning; a volume-driven change becomes a separate, priced request |
| Cost of a changed pricing rule | The vendor's change-request queue, or a plan-tier limit | As fast as the team can ship it | A priced change-control request against the written scope |
| Who absorbs integration cost | Mostly you, for anything the vendor has no built-in connector for | Entirely the in-house team's time | Scoped into the engagement, or priced as a change |
| Cost of leaving the route | Data export plus a second vendor's onboarding effort | Rebuilding elsewhere, or losing institutional knowledge when staff leave | Set by the handover terms agreed at commissioning |
| Who prices the next feature | The vendor, on its own release schedule | Your own backlog, if the team is retained | Your own backlog, each item scoped and priced |
| Honest fit | A steady, standard-volume business that prefers not to manage its own cost scaling | A team whose time would otherwise sit unused, since payroll continues regardless of output | A business whose volume or rule complexity would otherwise push a subscription plan's own scaling terms higher over time |
Does switching routes later change the shape?
Yes, and the direction of the switch matters more than the shape of either route alone. Moving from a subscription platform to a commissioned build turns a recurring fee into a bounded project cost plus optional ongoing work, but only once migration cost, usually data export and re-import, is accounted for separately. Moving from an in-house build to a commissioned one turns continuous payroll into scoped, priced change requests, but surfaces whatever was never documented. Web-to-print migration and rescue describes the engagement shape for a platform that already exists and needs to change hands.
What does a commissioned build's cost shape actually include?
The default engagement is fixed-scope with written acceptance criteria and priced change control. Managed operations is a separate, opt-in agreement. Client-specific deliverables, access and handover are defined in the engagement contract. Pre-existing software, products, APIs and third-party components remain subject to their respective ownership and licence terms. That shape is why the bounded project cost in the table above is described as "mostly" bounded: a scope change is always possible, and it is always priced before it happens rather than absorbed silently. Web-to-print architecture and discovery is the engagement that turns an unclear requirement into a scope a cost can actually be bounded against.
What should you send to get a real cost conversation started?
A real cost conversation needs your current order volume, how often your pricing rules change, and whether a production system must receive orders automatically. Send those three facts in a project brief and the conversation starts from your shape, not a borrowed one.
Discuss your web-to-print project
Frequently asked questions
Because a range from a different business's volume, region or scope would be read as a quote, and this site publishes no prices, rates, day rates or payment terms. The shape in the table is the part that holds across businesses; a figure is not.
It is often the fastest route to revenue at low volume, which is a separate question from cost shape. Four ways to get a web-to-print platform compares time to first order directly.
Only the parts a client chooses to keep: managed operations is a separate, opt-in agreement, never bundled silently into a project price.
Count fully-loaded payroll, not base salary, across the whole time a platform takes to reach the same functionality a scoped engagement would reach, then compare that total to a single bounded project cost plus whatever ongoing work you choose to keep.
References (2)
- Internal claim registry (
data/evidence/claim-registry.csv), accessed 2026-10-15. - docs/strategy/positioning.md, section 7, "Differentiation against the three real alternatives," accessed 2026-10-15.