Configuration vs. custom development
A blueprint is a proven structure, not an inflexible off-the-shelf product. We start from a repeatable workflow and a set of reusable components, then configure them around the client’s terminology, roles, approval rules, systems and data.
The choice is not between a rigid product and building from scratch. What you get is a structure that already works, adapted to how your organisation actually operates.
A blueprint lists what the pattern can include — its full capability menu, the same page for every reader. Which of those capabilities are included, adapted or built for you, and what we commit to, is set out in the offer for your engagement; nothing on a blueprint page is a commitment on its own.
| Standardised | Configured | Custom when justified |
|---|---|---|
| Portal / application foundation | Forms and field logic | Unique product configurators |
| Role-based access | Approval routes | Complex pricing or feasibility logic |
| Request and status lifecycle | Notifications and templates | Legacy-system adapters |
| Audit logging | Dashboards and KPIs | Proprietary operational algorithms |
| Automation patterns | ERP / CRM field mappings | High-volume or unusual integration architecture |
How to read the table
The first column is what we do not rebuild per client — it is the reason a blueprint is faster and safer than a bespoke project. The second column is where the client’s reality is absorbed, and it is where most of the adaptation happens. The third column is genuine development work.
The rule for the third column
Anything in the third column is scoped after discovery and contracted separately. It is never an implicit extension of a standard option, and we will say so at the point it comes up rather than at delivery.
Does one of these look like your operation?
Start with the diagnostic. We map how your work actually flows, then adapt the blueprint to it.