How we work
-
Home
-
How we work
How we work
Web2Print Solutions runs a web-to-print engagement through five stages: brief, discovery, build, launch and operate. Discovery records product rules, system interfaces and output requirements before a build scope is agreed, a written acceptance test gates launch, and change control keeps a technical discovery from becoming an unbounded promise.
What is the engagement path?
Most failed web-to-print projects were scoped at the wrong altitude: loose enough that a demo gets mistaken for a working order path, or rigid enough that the first production exception has nowhere to go. Web2Print Solutions runs every engagement through five stages, brief, discovery, build, launch and operate, so that a build commitment is made only once the print workflow is understood well enough to accept against. Who is accountable for that route is set out on the about page.
How does the engagement move stage by stage?
- Brief. The first conversation is about the new workflow you need or the existing workflow you want to improve: a representative product, its known-good price or output, the systems that need to exchange data, and the step an operator still performs manually. For Media and Enterprise teams this also covers content approval, buying permissions and who can release a job.
- Discovery. A discovery engagement is appropriate when the brief cannot yet support a build commitment. The output of a discovery engagement is written so that a supplier other than us can execute it. It covers architecture, pricing-rule specification, integration inventory and a phased plan, with the unknowns made visible rather than hidden.
- Build. The default engagement is fixed-scope with written acceptance criteria and priced change control. Managed operations is a separate, opt-in agreement. An acceptance criterion names an input, an expected result and a way to inspect it: a pricing engine checked against known-good quotes, an output pipeline checked against specified geometry and preflight rules, an integration checked for acknowledgement, retry and rejection behaviour.
- Launch. Work ships only after the written acceptance test passes and the client signs off on representative orders, artwork checks and a rollback decision; migration adds record reconciliation and a controlled switch from the old buying path. Where the test does not pass, the scope is updated in writing rather than launched anyway.
- Operate. Acceptance involves the estimator, prepress operator and business owner who rely on the result, and status is reported back to the client on request rather than assumed. We can assess an existing print software stack for a maintenance or operations takeover. The assessment defines access, dependencies, recovery procedures, responsibilities and the support scope before any ongoing service is agreed.
(opens the full-size diagram in a new tab)
What does each stage deliver and decide?
| Stage | Client decision | What we deliver | How it is checked |
|---|---|---|---|
| Brief | Confirm the representative product and the manual step to fix | A scoped question, not a requirements document | The brief names one real product or order, not a wishlist |
| Discovery | Decide whether the brief can support a build commitment yet | Architecture, pricing-rule specification, integration inventory, phased plan | A supplier other than us could execute the written output |
| Build | Agree the fixed scope and the acceptance criteria | A build against named inputs, expected results and a way to inspect them | Each criterion is checked against a known-good quote, a specified output or logged interface behaviour |
| Launch | Sign off on representative orders and the rollback decision | A written acceptance test, a rollback plan, a migration cutover where relevant | The written acceptance test passes before anything ships |
| Operate | Decide whether to take on an assessed maintenance or operations scope | An access, dependency and recovery assessment before any ongoing service is agreed | The assessment is accepted like any other deliverable |
What must the client provide?
- A representative product or order, with its known-good price or output.
- The systems that need to exchange data, and who can grant access to them.
- The step an operator still performs manually today, and who does it.
- For Media and Enterprise teams: content approval rules, buying permissions and who can release a job.
- A named estimator, prepress operator or business owner who can accept the result.
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.
What does the build stage look like for one product?
Illustrative example, not a delivered project: a print business sells a folded A5 brochure in three paper weights with a quantity-break price table. Discovery records the known-good price for 250, 1,000 and 5,000 copies, the paper codes the print MIS already uses, and the one quantity break the current site prices wrong. The build scope is then a single pricing rule, not a storefront rewrite, and the acceptance test re-quotes the same three quantities against the client's own numbers before launch.
When does a different route fit better?
If the product rules are standard and a packaged system can already price and route them as they stand, assess that option before commissioning code for behaviour it already provides. When not to hire us sets out the disqualifying cases in full; this checklist is the short version:
- A representative product and a known-good price or output exist.
- Someone named can accept the result and sign off on launch.
- The systems involved are ones we can legally access or receive exports from.
- The requirement is not already met by a packaged product's own configuration.
If every item checks out, a project brief naming that product is the next step.
What proof stands behind this route?
The evidence page publishes case studies and group records so this process can be checked against a dated example rather than taken on description alone. The about page sets out who is accountable for the route, and when not to hire us names the cases where it is the wrong one.
Start with a project brief
Send a project brief naming one representative product or order, the systems it touches, and the manual step you want gone. That is enough to decide whether a discovery engagement or a scoped build is the right next step.
Frequently asked questions
Only when the brief already names a representative product, a known-good price or output, and the interfaces involved. Otherwise the build scope would be a guess, and the acceptance test would have nothing fixed to check against.
We draft them from the brief and discovery output, and the client confirms them in writing before the build starts. A criterion that was never confirmed is not grounds to withhold acceptance later.
The scope is updated in writing rather than shipped anyway. A failed test is a scoping finding, not a reason to lower the bar.
No. It means an access, dependency and recovery assessment agreed before any ongoing service starts. Managed operations is a separate, opt-in agreement, not a default add-on.