Start a web-to-print project brief

Describe the constraint, not a feature list

A useful brief starts with an example. Choose a product a customer can order today, or should be able to order. Describe its permitted sizes, materials, quantity rules, finishing and artwork requirements. Then show the point at which the current software stops representing the business correctly. A screenshot or redacted specification can help, but sensitive files should not be sent before an appropriate channel is agreed.

If the problem is in pricing, include a known-good estimate and the inputs behind it. If it is in print output, describe the required file and the rejection reason. If it is in the order handoff, identify the receiving MIS, ERP or scheduler and whether it offers a documented interface. If you do not know, write that. An unknown interface is a scoping question, not a reason to guess.

What to include

State who will use the system: retail customers, trade accounts, internal buyers or production staff. Name the systems that must remain in place. Tell us what cannot change, such as an existing approval chain, an established job identifier or a prepress workflow. Describe what you would accept as evidence that the new behaviour works. A small sample set of real orders or quotes, anonymised where needed, can become the basis for that acceptance test.

You do not need to provide a budget number through this page. The brief is for technical qualification, not a public estimate. It also should not contain live credentials, customer personal data or unrestricted artwork files.

Include the person who can confirm a correct result on your side. A pricing rule may be approved by an estimator, while an output file needs prepress review and an order handoff needs production review. One broad sign-off at the end can hide disagreement among those roles. Identifying them early helps turn a vague request into checks against real work.

What happens after submission

A brief gives us a basis for deciding whether a scoped discovery conversation is appropriate. Include any deadline and the event behind it so timing can be assessed.

An initial conversation can identify what is understood, what must be inspected, and whether the next useful step is a bounded discovery engagement, a more specific question, or a recommendation to use a packaged product. The output of a discovery engagement is written so that a supplier other than us can execute it.

The how we work page explains scope and acceptance. Read when not to hire us if your requirement is standard or time to first order is the main decision. The service list helps you name the engineering area, but the brief should stay anchored to your actual workflow.