An Enterprise Data Collection Platform Unifying Web and Mobile

What made it hard

The same client — a regulated corporate mutual-aid and savings institution with tens of thousands of members — wanted a new system to collect requests and feedback from its member base on a regular basis.

The difficulty was not the requirement itself but the constraints around it. The institution's running systems were not to be touched. Their own IT team was not to write code. The system had to work in the mobile app and on the website, and users could not be asked to sign in a second time. And the business unit could not be sent into the development queue for every new form.

In a regulated institution with tens of thousands of members, meeting all of those at once turns the job from a development project into an integration problem. The hard part was not writing code — it was placing a new system beside a running one without disturbing anything.

The business unit defines the form, not a developer

At the centre of the platform is a definition engine that lets a form be built without writing code. The business unit creates the form in the panel, adds its steps and questions, and publishes it — without raising a development request.

The most useful capability is linked questions: the options in one question narrow according to the answer above it, the way choosing a vehicle brand should leave only that brand's models in the list.

We kept the system deliberately simple. Instead of a rules engine capable of expressing any condition we built a predictable structure, and for the user that means the form definition downloads to the phone in one go, the options narrow correctly even without a connection, and the user never waits on the server between questions.

The hardest part: two channels, one identity

The platform runs independently of the institution's identity system but still had to recognise the user securely — and from two different channels: the mobile app and the institution's website. The same person arriving from either channel had to be seen as one user.

We did not solve this by assumption. We measured the constraints of the live environment one by one and built the solution around what we measured, not the other way round.

What was achieved: the user does not sign in a second time, the institution's identity system stays exactly as it was, the platform stores no identity credentials of its own, and the same person is matched as one user across both channels. Total work required from the institution's own team: adding two lines to a page and one configuration change.

We also made a deliberate decision on identity matching: no automatic merging based on similar-looking details. The cost of a wrong match would be showing one member another member's data. We did not take that risk; unmatched records were kept separate.

Everything claimed was measured

We had a working principle on this project: nothing we believed to be true was left untested.

For example, we suspected a risk in the order the new version had to be deployed. We did not predict it — we deliberately did it in the wrong order in a controlled environment, watched what happened, established the correct order and wrote it into the release documentation as a warning.

The same discipline carried into handover: the package going to production was run and tested itself, and the files being delivered were unpacked and independently re-audited.

Outcome

The platform was delivered in two months and is live. Real member responses are coming in, the business unit defines its own forms from the panel, and notifications run across three channels — email, SMS and in-app. Not one line changed in the institution's existing systems.

It was handed over at a level where the client could continue with a different supplier if it chose to: full source code, a screen-by-screen user guide for the business unit, a 53-page handbook for the technical team taking over, deployment documentation and a key inventory. A system nobody else can take over has not really been delivered.