Custom plugin brief: what to prepare before you ask for a quote

A custom plugin brief is a short document. In it you describe the goal, the technical environment, the expected behaviour and the acceptance criteria. Why bother? So the developer can price the work straight away, not after three rounds of follow-up questions. And if you are not sure yet whether to go for a custom or ready-made solution, take a look at our January 2022 post about that decision. Here we assume the decision has been made and focus on the order itself.

What is a custom plugin brief and why does it get you a quote faster?

A brief is input material. The developer uses it to prepare the full technical specification, so you do not have to write documentation like a programmer (and nobody expects you to). It is enough to describe honestly what you need and in what conditions. In return you get a quote closer to the real cost, fewer surprises along the way and offers you can actually compare. The most common sin in enquiries? A single sentence like „I need a discount plugin”. That could mean a two-day project or a two-month one. Guess how the quote turns out.

What business problem should the plugin solve?

Start with the problem and the goal. Not with a list of features. Write down who will use the solution: the store’s customer, the administrator, the warehouse, or maybe accounting. Show how the process works today and where it hurts - retyping orders by hand, the same mistakes over and over, no integration with another system. Also add how you will know the rollout worked. For example, when invoices no longer need manual fixes. A simple measure, but it works. If you have looked at ready-made extensions, add two sentences on why they did not make the cut. That way the developer will not suggest something you have already rejected.

Technical environment: what to check in the admin panel before you send an enquiry

The developer needs to know what the plugin will run on. That determines the scope of testing and the risk of conflicts during updates. Prepare:

• your WordPress and WooCommerce or PrestaShop version,
• the PHP version on the server,
• the type of theme: off-the-shelf, child or custom,
• a list of active plugins or modules,
• the hosting provider’s name and whether a staging environment is available,
• the store’s languages and currencies.

In WordPress most of this data is under Tools > Site Health, in PrestaShop under Advanced Parameters > Information. Five minutes of clicking. On top of that, external integrations: ERP, couriers, payments, wholesalers. If you have API documentation, attach it right away. When ordering a custom PrestaShop module, give the exact store version, because the differences between the 1.7, 8 and 9 lines really do change the scope of work.

How do you describe the plugin’s behaviour so the specification is unambiguous?

Vague slogans do not work. Step-by-step scenarios from the user’s point of view absolutely do. Each one can follow a simple layout:

1. Who performs the action.
2. Where in the store they do it.
3. What the system does then.
4. What the user sees.
5. What happens if something goes wrong.

And do not forget edge cases: returns, order edits, products with variants or extra product fields, items out of stock. These are exactly what surfaces at acceptance, when it is too late for a calm quote. Split requirements into „must have” and „nice to have”. The developer can then price the core version and the extensions separately, and you decide what you can afford. Add screenshots, sketches or sample import files. Anything that helps turn the description into a concrete plugin specification.

WordPress plugin quote: budget, deadline and terms of cooperation

A budget range in the brief does not weaken your negotiating position. It lets the developer propose a scope that makes sense for what you can spend. Also separate a hard deadline (season, campaign) from a preferred one. Agree who will handle maintenance after launch: updates for new WordPress versions, WooCommerce or PrestaShop, support, fixes. Code ownership and licence? Into the contract, in black and white. Oh, and if the plugin will process customers’ personal data, say so in the brief, because it changes how the whole solution is designed.

Acceptance criteria and mistakes that drag the project out

Acceptance criteria are the list of checks after which you consider the work done. It is best to write them down in the brief already. They might look like this: the scenarios from the previous section work on a copy of the store, the plugin does not clash with key extensions, and everything displays correctly on phones. What most often stretches a project? Three things. Adding features mid-way without an annex. No staging environment. And the only decision-maker being away right at acceptance (a classic).

A well-prepared custom plugin brief is a few pages that save weeks of emails and revisions. You can send the finished material through the K4 plugin quote form, where Web Systems builds custom WordPress plugins and PrestaShop modules.

Frequently asked questions