When not to hire us
-
Home
-
When not to hire us
When not to hire us
Do not commission a print software engagement without a defined outcome, lawful access to the systems involved and someone who can accept the result. A standard product may meet the requirement through configuration or integration. Custom development is appropriate only for the remaining gap, with maintenance and component rights understood before delivery.
When does a packaged product fit better?
If you sell a small catalogue with straightforward sizes, quantities and list prices, assess a packaged web-to-print product first. It may provide the behaviour you need without bespoke development. A services engagement can still be useful for setup, data preparation, integration or rollout; define that gap before commissioning code for behaviour the product already provides.
If the main requirement is a quick launch, limit the first release to a workflow that can be tested responsibly. Discovery and acceptance take time because they establish whether an order can actually be produced. A deadline should shape the scope; it cannot remove the need to check pricing, artwork and handoff. An integration still needs testing when most of the software already exists.
Illustrative example, not a delivered project: a stationer selling twenty SKUs of business cards at three fixed quantities does not need a custom pricing engine. A packaged product's own quantity-break configuration already prices those twenty SKUs correctly, and the only services gap is importing the client's existing artwork templates.
When is a team problem not a platform problem?
If nobody has agreed how a product should be priced or which artwork should pass, code cannot settle the commercial decision. Write the rules and appoint an owner first. If production staff use several names for the same substrate or finishing operation, the data model needs work before an integration can be trusted.
An inherited build may be salvageable. A new implementation is not automatically the answer. The first deliverable may be a decision to complete, replace, migrate or stop. That finding should be allowed to contradict the original plan.
What can we not claim, and what will we not do?
All engineering and delivery for Web2Print Solutions is performed remote-first from Hanoi, Vietnam. Web2Print Solutions has no office, legal entity, employee base, representative or local support window in any other location.
Web2Print Solutions does not act as a print broker, does not buy print on a client's behalf and does not hold client funds. We also do not take work whose purpose is to defeat another supplier's licence or activation conditions; a migration needs a lawful route to the data and components it will carry forward.
Which signals mean we are the wrong fit?
| Disqualifying signal | What it looks like | What to do instead |
|---|---|---|
| An off-the-shelf product already fits | A small catalogue with standard sizes, quantities and list prices | Assess a packaged web-to-print product first; use services only for setup, data or rollout |
| The product has no real complexity | Pricing, artwork and finishing rules are already agreed and simple | Configure the packaged product; do not commission code for behaviour it already provides |
| Budget or timeline cannot support discovery and acceptance | The only fixed requirement is a launch date, with no room to check pricing or artwork | Narrow the first release to a workflow that can be tested responsibly, or wait |
| On-site presence is a condition of the work | A local office, legal entity, support window or held credential outside Vietnam is required | Choose a supplier that can meet that condition; it is not one this site claims |
Where is the threshold for a custom build?
The strongest brief identifies a rule that customers or operators rely on and that the current product distorts: an unusual pricing model, an output contract prepress can enforce, or an order path into an existing MIS. Before committing, check this list:
- The gap cannot be closed by configuring a packaged product.
- A named person can accept the result and sign off on launch.
- The budget and timeline leave room for discovery and a written acceptance test.
- No condition of the work requires a presence outside Hanoi, Vietnam.
If every item holds, the services page shows the engineering scopes and how we work explains the acceptance route.
What should you send instead?
If a packaged product looks like the right answer, send a project brief naming the product you are evaluating and the one rule it cannot express; we will say plainly whether that is a configuration question or a services gap. See the evidence page for examples of engagements we did take on, to compare against your own catalogue.
Frequently asked questions
Yes. A services engagement for behaviour a packaged product already provides is a cost we would rather name than invoice for.
No vendor, partner or product is named or recommended on this site; the assessment is about the gap, not an endorsement.
Say so in the brief. We can scope a narrower release that can still be tested responsibly, or explain why the deadline and the acceptance test are in conflict.
We can assess a stalled, inherited or failing build and report plainly whether it should be completed, replaced, migrated or stopped, without criticising the previous supplier by name.