Petition hosting for a counter everyone is watching.
A petition is a write-heavy site with a public number on the front of it. Both halves fail at exactly the same moment - when it starts spreading.
Every visitor is a database write.
Most sites read far more than they write. A petition inverts that, and it inverts it during a traffic spike.
A signature is not a page view
When a petition spreads, most arriving visitors submit rather than browse. Capacity is planned for writes, which is a different shape from serving cached pages.
Duplicates and automation filtered
A petition's credibility rests on its number. Repeat submissions and automated ones are rejected at the edge, before they become rows somebody has to defend.
A counter that is current but cheap
The total is on every page and changes constantly. It is served from a maintained figure rather than counted from the table on each request.
Signatory data treated as personal data
Names, postcodes and email addresses given in support of a cause are sensitive by context. Storage and export are handled accordingly.
Delivery to the recipient
A petition ends by being handed over. The export has to be complete and reproducible, including at a point in time after signing has closed.
Traffic and writes arrive together.
A petition does not get gradually popular. It is shared somewhere and takes a year of signatures in an afternoon, all of them writes to the same table.
- Capacity planned for write throughput
- Duplicate and automated submissions filtered at the edge
- Counter served from a maintained figure
- Signatory export complete and reproducible
Accepting signatures, not queueing them.
The number that matters is whether a submission completes while thousands of other people are submitting the same form.
What we change for petition sites
The read-heavy assumptions behind most WordPress tuning are wrong here, and the public number makes correctness a credibility question.
| Setting | What we do | Why |
|---|---|---|
| Capacity shape | Planned for write throughput rather than cached reads | When a petition spreads most arrivals submit instead of browsing, which is the opposite of the traffic profile page caching is designed for. |
| Submission filtering | Duplicates and automated signatures rejected at the edge | The total is the petition's entire claim, so a number inflated by repeat and scripted submissions is worse than a smaller honest one. |
| Counter source | Read from a maintained figure, not counted per request | The total appears on every page and changes constantly, and counting a growing table on each view makes popularity into a slowdown. |
| Signatory storage | Handled as personal data given in a political context | A name and postcode attached to a cause is more sensitive than the same fields on an order, and the storage decisions should reflect that. |
| Handover export | Reproducible at a point in time after closing | A petition is delivered to a recipient, and the export has to be defensible later rather than a snapshot nobody can reproduce. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why does my petition slow down when it goes viral?
How do you stop fake signatures?
Does the signature counter slow the site down?
Can I export the signatures for delivery?
Take every signature.
Move the campaign across. Migration is free, signatures included.