Sometimes the out-of-the-box component genuinely does not fit, and building something is the right call. Often the requirement is a process problem wearing a technical costume. Twopir Consulting builds the custom forms, interfaces, connectors and components that earn their place — and tells you plainly when a requirement does not. Interfaces, connectors, reusable components, branding and localisation.
Nintex customization services cover everything built beyond the standard configuration of the platform: custom forms and application interfaces, bespoke connectors, reusable components, branded and localised experiences, and integrations embedded into the systems people already work in. The useful question is never "can it be customised" — it can. It is which rung of the ladder a requirement genuinely needs, because each rung up transfers more maintenance from the vendor to you, permanently.
| Rung | What it means | Right answer when | What you take on |
|---|---|---|---|
| 01 · Configure | Using what the platform already does, set up properly — form rules, conditional visibility, standard actions, permissions. | Always try first. A surprising share of "we need custom" requests are answered here by someone who knows the product well. | Nothing. Upgrades are the vendor's problem and new features arrive for free. |
| 02 · Extend | Supported extension points — a custom connector built on the platform's own framework, reusable components, configuration-driven variation. | The capability exists but the specific system, calculation or reusable block does not ship with it. | Your extension, but on a supported contract. Usually carried through upgrades. |
| 03 · Customise | A bespoke interface or component — a purpose-built application screen, a guided experience, a dashboard the standard form cannot express. | The role genuinely needs an interface the standard components cannot express, and the productivity case is real. | Ownership. You re-test it on every upgrade and you maintain it when the person who built it leaves. |
| 04 · Build outside | Developing the capability in another system entirely and integrating it back. | The requirement is genuinely not what this platform is for, and forcing it in would be worse. | A second estate, with its own lifecycle, security posture and support model. |
We will always propose the lowest rung that meets the requirement, and say so explicitly when a request sits two rungs higher than it needs to. That is not caution — it is the difference between an estate that absorbs the next platform release and one that has to be re-tested against it.
These are the six categories where a custom build repays its maintenance cost often enough that we recommend it without hesitation.
Nintex Apps is the platform's low-code application builder — the product that came into the portfolio with the Skuid acquisition — and it is the right tool when a role needs a working screen rather than a form: a queue view, a guided multi-step task, a dashboard that combines data from several sources.
Complex conditional visibility, cross-field validation, repeating and table sections for genuine multi-line input, live lookups against other systems, and calculations that have to agree with a finance system to the penny.
When a system you depend on has no ready-made connector, the Nintex Xtensions framework turns its REST API into a first-class action in the designer — defined in OpenAPI, so it appears and behaves like any other connector rather than as a raw web request nobody can read.
The approval block, the escalation pattern, the address validator, the audit-logging step. Built once, parameterised, and used across the estate — so a defect is fixed in one place and a new builder inherits the standard rather than reinventing it.
Forms and interfaces that look like they belong to your organisation, work in the languages your users actually speak, and meet the accessibility standard you are held to — which for a public-sector or regulated client is a requirement, not a preference.
Putting the task where the person already is — inside the CRM record, in a collaboration tool, in a customer-facing portal — rather than asking them to learn a second application whose only job is to hold a button they press twice a week.
Nintex ships on a quarterly cadence. A customisation that assumed the product would stand still becomes a blocker on the release your team wants for something else entirely.
A supported mechanism has a contract behind it. An undocumented behaviour that happens to work today is not a feature, and it will be corrected in a release nobody warned you about specifically.
Custom logic lives in identifiable, named components rather than being woven through twenty workflows. When an upgrade requires a change, you want to know exactly which twelve things to re-test — not "everything, probably".
Every customisation carries a short record of the requirement it satisfies and why configuration could not. In two years someone will ask whether it is still needed, and without that record the answer is always "leave it, just in case".
Release notes get read against the customisation register, not skimmed. Sometimes the finding is that the platform now does natively what you paid to build — which is a good day, and the customisation gets retired.
Every custom component should have a plausible answer to "how would we remove this". Components with no exit route are the ones that outlive their purpose by years because removing them is scarier than keeping them.
We will still build it if you decide to after hearing the argument — it is your estate. But you will hear the argument.
Replicating a retired interface preserves habits rather than the requirement behind them. It is expensive, it ages badly, and it usually loses the improvements that motivated the replacement. Change management is almost always cheaper than pixel-matching.
A customisation serving one person is a maintenance obligation serving one person, and it usually outlives their tenure. Where the need is real we look for a configuration that serves the role rather than the individual.
When a custom component exists to compensate for a data model that does not reflect the business, you are paying twice — once to build it and forever to keep it in step. Fixing the model is harder and very nearly always cheaper.
If a capability is genuinely on the published roadmap and the need is not urgent, waiting is free and building is not. We will check the release notes before quoting, and tell you when waiting is the better trade.
Some requirements exist only because a process step is wrong. Automating them makes the wrong step permanent and harder to remove. That is a process conversation first — see Nintex process automation.
A role that genuinely needs a working screen, a system with no connector, a regulated accessibility or language requirement, or a reusable component that removes duplication across the estate. Those are straightforward cases and we get on with them.
Not if it is built on supported extension points, which is the main reason we insist on them. What genuinely creates upgrade risk is depending on undocumented behaviour, or scattering custom logic through the estate so that nobody can scope the re-test. We keep customisations isolated, named and recorded on a register, and we read release notes against that register — so an upgrade produces a specific test list rather than a general anxiety.
A form is for capturing or deciding one thing — a request, an approval, a submission. Reach for an application interface when the person needs to work rather than submit: see a queue and pick from it, compare several records, follow a guided sequence across multiple steps, or view data pulled from more than one system on one screen. The signal that you have overloaded a form is conditional logic so dense that nobody can predict what the user will see.
Yes, and we start by documenting what is there rather than by rewriting it. The assessment covers what each component does, whether it uses supported mechanisms, what breaks if it is removed, and whether the platform has since absorbed its function. That last one is worth checking every time — inherited estates frequently contain custom work that a later release made unnecessary, and retiring it is the cheapest improvement on the list.
As a design constraint from the start, because retrofitting accessibility into a finished interface costs several times more than building it in. In practice that means keyboard operability throughout, sufficient contrast, labels and error messages that a screen reader announces usefully, and not relying on colour alone to convey state. Where you are held to a specific standard, we agree which one and which conformance level before design begins, and test against it rather than assuming.
Whoever you decide, but the decision has to be made before the build rather than discovered afterwards. We hand over the component with its documentation, its register entry, its test cases and enablement for your team — so in-house maintenance is a genuine option. Some clients keep us on a support arrangement instead. What does not work is a custom component with no named owner: it survives untouched until it breaks, and then nobody knows how it was supposed to behave.
To build, sometimes only slightly. To own, always — and that is the number that gets left out of the comparison. A configured capability is maintained by the vendor and improved for free. A custom one is re-tested on every upgrade, has to be documented well enough to survive staff changes, and needs a decision every time the platform adds something similar. When we quote a customisation we say what it will cost to keep, not only what it costs to build.
Half the time there is a configuration that meets it. The other half, there is a genuine case — and it is worth knowing which before anyone writes a quote.
The lowest rung that meets the requirement, every time
