Print-on-demand hosting for stores that wait on a supplier API.
You do not hold stock. Every order has to reach a fulfilment partner, every product has more variants than a normal store, and every mockup is an image somebody generated rather than photographed.
Everything a dropship-print store asks of a host.
The store's slowest moments are all somebody else's infrastructure. The tuning is about not letting that become the customer's problem.
The supplier call leaves the checkout path
Submitting an order to a print partner is queued and retried rather than done inline, so a slow supplier API delays fulfilment by seconds instead of holding the customer on a spinning checkout.
Variant counts that break normal queries
A shirt in six colours, seven sizes and two prints is eighty-four variants. Product queries and indexes are tuned for catalogues where the variant table dwarfs the product table.
Generated mockups served from the edge
Mockups are images produced per design rather than photographed once, so there are thousands of them and they are all first-time views. They serve from the edge with long cache lifetimes.
Status syncs that run on time
Tracking numbers and production status arrive by webhook or are polled on a schedule. Both run on system cron so a customer is not told 'processing' three days after it shipped.
Backups that include the artwork links
Orders, designs and their supplier references in one nightly snapshot, replicated off the origin, so a restore does not orphan a print job.
Know the orders actually reached the printer.
The worst failure in print-on-demand is silent: the store took the money and the partner never received the job.
- One-click admin login, no shared passwords
- Supplier queue depth and failures visible
- Plugin and core updates with per-item status
- Restore any daily backup from the dashboard
Eighty-four variants, one fast page.
Product pages here do more work than in a normal store, because the variant matrix and the mockup set are both larger by an order of magnitude.
What we change for a print-on-demand store
These differ from a standard WooCommerce store on the same plan, because the inventory is infinite, the images are generated and the fulfilment is somebody else's API.
| Setting | What we do | Why |
|---|---|---|
| Supplier submission | Order handoff queued and retried in the background rather than called inline | A print partner's API is outside your control and occasionally slow, so calling it during checkout means the customer's payment confirmation waits on a third party that may be having a bad afternoon. |
| Variant indexing | Product and variation tables indexed for catalogues where variants outnumber products heavily | A single design across colours, sizes and placements produces dozens of variations each, so the variation table grows at a rate the default schema assumptions were never written for. |
| Mockup delivery | Generated images served from the edge with long cache lifetimes and range requests | Mockups are produced once per design and then never change, but there are thousands of them and almost every view is a first view, which is the opposite of a photographed catalogue. |
| Fulfilment status sync | Webhooks excluded from caching, polling driven by system cron | Tracking information arrives after the customer has already started wondering, so a status update that waits for the next visitor to trigger wp-cron arrives after the support email has been sent. |
| Failed-submission handling | Failures surfaced as a visible queue rather than retried silently | An order that was paid for and never reached the printer looks identical to a successful one from the store's side, and the first person to notice is otherwise the customer who never received anything. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Should the supplier API be called during checkout?
My product pages are slow with lots of variants. Why?
How are mockup images handled?
What happens if an order fails to reach the printer?
Do tracking numbers update automatically?
Run a print-on-demand store that never loses an order.
Free migration, supplier calls off the checkout path, and mockups served from the edge.