A third-party low-code platform, not our software. We implement it, build on it, and support what we have built, and this page sets out where that is a good idea and where it is not.
What we do with it.
Design and build applications on the platform: request and approval workflows, registers, inspection and data capture forms, and the integrations that connect them to the systems that hold the records. We also put the operating model around it, which is the part that decides whether the estate is still manageable in two years.
Where it fits well.
Process-shaped problems with a clear owner and a moderate user base: a workflow that currently runs on email, a register that lives in a spreadsheet somebody maintains by hand, a form that has to reach a queue and be tracked. Speed of delivery is a genuine advantage in those cases, and the configuration surface is deep enough to avoid custom code for most of it.
Where it does not.
Anything that should be the system of record for regulated data, anything a customer touches without authenticating, and anything with a genuinely complex transaction model. We will say so rather than build it, because migrating a successful application off a platform later is considerably more expensive than choosing a different home at the start.
What we insist on.
A named owner per application, separated development and production, a naming convention, and a light review gate before anything goes live. None of that is interesting and all of it is the difference between a catalogue somebody can audit and forty applications nobody can account for.
Licensing and support.
The platform licence is the vendor's, and we will tell you plainly what it costs and what it covers rather than bundling it into a project figure. Support for what we build is ours, under an agreed response model. Support for the platform itself sits with the vendor, and we will help you raise and track anything that belongs there.