AI Build

RunQuickSurvey

RunQuickSurvey is one instrument, published to WhatsApp, Telegram, email, the web and a kiosk. Field teams were already collecting on paper, in chat threads and in spreadsheets, and the three never met.

A survey that assumes a signal fails where the answers are worth most: a remote clinic, a site, an interview that will not be repeated. It had to behave the same way with a connection and without one.

  • One instrument, every channel
  • Skip logic that survives a resync
  • Read the open text the same day
RunQuickSurvey interface screenshot

One instrument, every channel

The survey is authored once. A WhatsApp respondent and a kiosk respondent get the same questions. The channel is a transport. The author does not maintain five versions.

One formevery channel, authored once

Skip logic that survives a resync

Conditional questions and media have to come back intact. Duplicating a half-finished interview, or dropping it, is the failure that makes field software unusable.

Offlineskip logic survives the resync

Read the open text the same day

Themes in free-text answers surface without someone reading thousands of replies. That is the part of this product where a model earns its place.

Same daythemes from the open text

The build

Connectivity is the exception

The interesting data is collected where the network is worst. Treating online as the real product, with offline as a fallback, is how responses diverge. The client stores the answer locally, skip logic included, and syncs when it can.

RunQuickSurvey, Connectivity is the exception

Conflicts have to be boring

Two devices, one interview, a signal that drops mid-question. The sync resolves that deterministically, so a remote interviewer does not lose a partial response and does not file it twice. That is less visible than the form, and it is the product.

RunQuickSurvey, Conflicts have to be boring

The same questions, every channel

WhatsApp, Telegram, email, web, kiosk. If the person writing the survey has to keep a version per channel, the versions drift, and then the job is reconciling surveys rather than reading answers.

RunQuickSurvey, The same questions, every channel

A model on the replies, not the form

The model reads the open text. It does not decide the next question - the skip logic does, and it has to do that with no signal at all. Themes come back while interviews are still running, which is when a team can still change what it asks tomorrow.

RunQuickSurvey, A model on the replies, not the form

How we worked

What field products ask of us

The same engine, both modes

Offline is not a cache of the online form. It is the same engine with the network removed, or the two copies of the truth will not agree.

Authors who are not engineers

If a new channel means a new build, the survey will not be published there. The publishing path has to belong to the people running the study.

Insight while the work is open

A weekly export of comments is a report. Themes the same day are something a programme lead can still act on.

Technology

What it is built on

  • C#
  • MYSQL
  • Flutter
  • Python
  • PHP

Need something like this built?

Tell us what you are trying to ship and an engineer will reply within one business day.