Mobile app for petitions: where signature collection breaks
A petition lives for exactly one burst: a post by a major author, a media mention, a repost in a community. In a minute, a mobile app for petitions receives as many requests as it has seen in a day.
If a signature is recorded synchronously with external verification of a phone number, email, or anti-bot check, the queue grows, response time exceeds the wait in the interface — and the person sees an error. They won't try again: closed and forgot.
This is what signature loss under peak load looks like. An external service may respond slowly, return a rejection, or count one request twice — and then online signature collection either stalls or fills up with duplicates.
A separate problem is profile integrity: one person signs from a phone and a tablet, an old account is tied to a previous number, logging in by email and by phone creates two records.
The vote is counted twice, and the campaign gets not support but a public dispute about inflated signatures.
Next, petition moderation gets stuck. While verification is manual, the flow at peak accumulates in a queue, authors wait for a response for days, and some requests are rejected on formal grounds.
Large platforms like Change.org have lived with this for years, but even there disputed cases are handled by people — automation only closes routine ones.
Finally, mobile app support on a leftover basis: failures are learned about from reviews, not metrics, no one checked duplicate recording, and logs don't reconcile.
Each of these failures is solved through engineering — idempotent signature recording, a queue with retries, a unified profile, staged verification. Let's break down how this works.
What changes after implementation: four measurable effects
Share of confirmed signatures
A signature is recorded only after two steps: the act itself in the interface and confirmation by the owner — via a code in a message or through a link to an account.
Deduplication is based on a stable device identifier and contact, so pressing again does not create a second record in the registry.
Instead of manually cleaning "raw" votes, valid ones are stored in the database right away — the share of confirmed signatures stops being a point of dispute with auditors.
Peak response time
A social media campaign brings thousands of people in minutes, and this is exactly where ordinary builds break.
Signature services scale horizontally by load, and recording goes through a queue: the peak doesn't bring down the form but is processed as resources allow, without losing clicks.
The engineering point is that the form responds in fractions of a second even at an order of magnitude above usual traffic.
Recovery time after failure
A scheme with a replica and regular backups allows the service to be restored in minutes rather than hours of downtime.
The procedure for rolling back to a previous build is worked out in advance: if a release behaves unexpectedly, the version is rolled back entirely, and confirmed signature data remains intact.
Petition status notifications are sent via Firebase — delivery does not depend on which node the service is running on at that moment.
A class of failures that disappears
A separate category of incidents is losing a signature at the moment of sending and double crediting on retry. The client saves the action locally, sends it with a unique key, and retries on its own until it receives confirmation from the server.
Duplicates on the server are filtered out by the key, so "signed but not in the registry" and "signed twice" disappear as a class.
All four effects are verified in acceptance tests before launch: we apply peak load, break the connection, and roll back the release.
Implementation formats: native code, shared codebase, web shell
The build format determines how a petition app behaves in the field: whether it accepts a signature with a weak connection, integrates with the camera and biometrics, and what the cost of app support is over several years.
Below are three working alternatives that teams choose between at the start, without "better/worse" labels.
Three options for the signature collection task
| Option | When it fits | Limitations |
|---|---|---|
| Native app development for each platform | Need document capture from the app, biometrics, background signature sending, fast transitions between screens | Two codebases and two release cycles: we edit signature logic twice, support is more expensive |
| Shared codebase | One product for both platforms, frequent edits to texts and campaign rules, small team | Document capture and heavy graphics require native inserts, some system updates arrive with a delay |
| Web app for signature collection | Fast launch, signature collection via a link from social networks, rare app visits | Limited access to camera and offline storage, notifications don't work on all devices, weaker retention |
The scenario matters more than the platform: if a signature is collected in the field without a stable connection and requires document verification, a shared codebase with native inserts solves the task; if the campaign lives in social media feeds, a web app provides reach without installation.
We fix the format before work starts — changing it midway means rewriting the signature layer and re-testing on both platforms.
How implementation goes: six stages from scheme to acceptance
Signature collection is more complex than a form with a button: one signature is one confirmed action by one person, and confirmability matters more than beautiful screens.
That's why we conduct implementation in a fixed sequence — from auditing how signatures are collected now to handing over the project with access and documentation. Below is the order of work, which shows at which step which risk is closed.
- Audit of current signature collection. We analyze how the process works today: paper forms, spreadsheets, email confirmations. We identify where records are lost, who checks duplicates and how, and what legal validity requirements must be preserved.
- Data schema audit. We describe the entities — campaign, signature, identity confirmation, action log — and deduplication rules. We check that the schema can withstand growth in the number of campaigns and exports for auditors.
- App design. Signature flow, confirmation, offline mode with weak connectivity, notifications, and the admin part for moderation and export of signature sheets.
- Setup and build. We implement the agreed schema, connect storage and the processing queue, configure operator roles, and log every change to a record.
- Load testing. We run the campaign's peak scenario: simultaneous signatures, deduplication on the stream, connection loss at the moment of recording. We look at the share of successfully saved signatures and rollback correctness.
- Acceptance and handover of the project to the client. We check against scenarios from an agreed list, then hand over access, configurations, the data schema, and instructions for operators.
After handover, you have a working system and clear documentation, not a black box: support, enhancements, and updates are discussed separately once the scope of work is clear. Describe the task — we'll come back with an estimate and a plan for these stages.
What we hand over: schemas, access, moderation procedures
We hand over not an archive of files but a working kit: for each artifact it is clear who the owner is, how to update it, and what to do in case of failure.
App store accounts, server keys, and the mailing panel are registered under your credentials with two-factor protection — access does not remain tied to the contractor.
- Signature data schema. Structure of a signature record, link to campaign and account, unique key against duplicate signing, change log. Collection results are verified by export, not by a counter in the interface.
- Access role matrix. "Role → action": guest, signer, moderator, campaign administrator, owner. It separately states who sees personal data and who sees only counters and statistics.
- Moderation procedure. What is published and what is rejected, review timelines, appeal procedure for the petition author, escalation of disputed cases.
- Moderator instructions. Step-by-step queue review, rejection criteria, reply templates for authors, actions for complaints and mass identical signatures.
- App documentation. Build and release, environment configuration, integration scheme, procedure for editing moderation rules without releasing a new version.
- Update release plan. Pre-publication verification procedure, conditions for rollback to a previous version, person responsible for on-call after release.
Case study: peak load and what we changed in the scheme
What it was before the changes
Publishing a campaign produced a spike 15–20 times the usual flow. The app handled steady traffic, but at peak the signature recording queued up: some sessions ended with an error, the person pressed the button again and created a duplicate that was later merged manually.
According to logs, before the changes about 8% of sessions at the moment of publication lost confirmation, signature submission took an average of 4 seconds, and handling a rejection took 3–4 hours of manual work by the on-call person.
What we changed in the scheme and what it became
We separated reads and writes: the campaign showcase is read from cache, and the signature goes through a queue with confirmation — the user sees a status, not a timeout.
We introduced idempotency by the pair "session + campaign", so a repeated tap does not create a second record but picks up the one already submitted.
Scaling was moved to Kubernetes: the number of replicas grows from queue length, not CPU load, — reaction starts before the visitor feels the delay. The signature registry was moved to read replicas, and the directory of active campaigns is warmed up before publication.
The share of lost confirmations at peak is 0.2% instead of 8%, signature submission is 0.6 seconds instead of 4. Response to a rejection via automatic notification dropped from three hours to 12 minutes, while the registry volume tripled.
The scheme handles the next peak without manual intervention by engineers — the same reserve works for campaigns that launch one after another.
How does a signature collection platform differ from a website form?
A web form and a signature collection app cover different segments of the same process. A website form is the entry point: a person came via a link from search, signed in a minute, no installation needed.
The mobile app takes on what a browser cannot handle: offline collection, identity confirmation, and reminders.
| Option | When it fits | Limitations |
|---|---|---|
| Website web form | One-off campaign, entry via link, embedding into an existing site | Without network the signature is not sent; repeat signatures are caught only by email and phone |
| Mobile app | Ongoing collection, series of campaigns, field collectors working "in the field" | Installation required; updates don't reach everyone at once |
| App and web form on a shared backend | Signing both from phone and from the site, unified campaign accounting | More expensive to develop: one identification scheme needed for both entry points |
The difference shows in identity confirmation. In website signature collection, the reliance is on a code from a message or an email, and one person with two addresses will leave two records.
In the app, verification happens once and is tied to the device, and each new signature is checked against the already stored identifier — duplicates are filtered out before recording.
Offline collection is something a web form fundamentally cannot do. The app stores the signature in local storage along with time and location tag, and when the network appears it sends what has accumulated via a queue. A collector with a tablet works in a hall without connectivity, and data is not lost on retry.
Notifications work differently: the app reminds you to confirm a signature or provide missing data, while a website form cannot do this.
Therefore, comparing approaches comes down not to "which is better" but to whether you need a one-off burst of signatures or ongoing collection with confirmation.
FAQ on moderation and petitions: addressing doubts
Petition moderation and protection against signature inflation are two topics that most often delay launch. Below are five doubts that come up at the estimation stage and how each is solved through engineering.
How do you distinguish real signatures from inflation?
We calculate behavioral signals: intervals between signatures from one device, matching fingerprints, form completion speed. Suspicious votes go into quarantine rather than being deleted immediately — the moderator sees a sample and confirms the decision.
The signature is confirmed by a one-time code, and the number or address itself is not stored in cleartext.
What will happen to already collected signatures during migration?
The database is transferred in batches, each batch is checked by checksum, duplicates are collapsed by the key "campaign + signer". The switch goes to reading from the new database, and the old one remains in a replica until reconciliation is complete. Rollback is one command, and it is available at any moment while the discrepancy is not zero.
Will the app withstand a peak during a high-profile campaign?
Signatures are written asynchronously through a queue, the confirmation screen is served immediately and does not wait for a database response. Counters and lists are cached, so a spike on one screen doesn't bring down the other sections.
The counter is rebuilt with a delay of a few seconds — this is a deliberate trade-off of accuracy for resilience.
What does app support include after launch?
On-call response to failures, updates for new platform versions, troubleshooting confirmation code delivery failures. We also handle moderation separately: petition complaints and rule configuration when a new inflation scenario appears. Filter thresholds can be changed without releasing a new build.
Who owns the collected signatures?
The database and exports remain on your side; we have access only during the work. Export to a spreadsheet or via API is available at any time, including campaigns that are still ongoing. After handover, access is closed and keys are revoked.
Let's discuss the task: what to send for an accurate estimate
To make the app development estimate based on facts rather than guesses, a few input materials are enough.
The more specific the inputs, the fewer assumptions in the timeline calculation and the more realistic the stage-by-stage implementation plan — from signature verification to exporting signatures to the recipient. Send what you already have; we'll clarify the rest with questions on a call.
- Scenarios for the signer and petition author: creation, moderation, signature collection, handover to the recipient.
- Signature verification rules: how a person's uniqueness is confirmed and what data remains in the system.
- Roles and permissions: moderator, agency representative, support, access to statistics and exports.
- Integrations: external registries, maps, notifications, analytics, official responses, and reporting.
- If a solution is already running — an audit of the current solution: bottlenecks, fault tolerance, support load.
- References and design: brand book, interface examples, accessibility requirements for visually impaired users.
- Requirements for personal data storage, server placement region, and history retention period.
- Priorities by stage: what must be in the first release and what can be postponed without losing meaning.
Describe the task in free form and attach what is already ready. We'll come back with an estimate of the scope of work, an implementation plan, team composition, and a list of risks related to timelines and data.