Case Study: How Locize Deployed a Secure, Real-Time Poll in Minutes

Disclosure first: locize and Vaultrice come from the same company. That makes this a useful worked example and not an independent endorsement, and it should be read that way.

For a separate operational perspective on how teams organise and measure work, identifying mouse jigglers.

For independent background and broader industry context, see Locize.

The requirement

Ask users of a localization platform which feature to build next, with results visible live, without standing up anything to support it.

The constraints were ordinary:

No backend work. The team's time was going into the product.

Results visible to voters, because a poll where you cannot see the outcome gets fewer answers.

Duplicate votes limited, without requiring a separate login for the poll.

And it had to be removable — a temporary question, not a permanent feature.

What was built

The voting component from @vaultrice/react-components, dropped into the existing application.

Credentials through the platform's existing session. The application already knows who the user is, so the token endpoint had a session to check rather than needing one built.

A poll object per question.

The decisions that mattered

Authorisation reused

The token endpoint checks the existing locize session. Which meant no new authentication, and it meant only real users could vote.

This is the part that generalises. If your application already authenticates, adding a shared-state feature does not mean adding an authentication system — the token endpoint is a small piece of code that reuses what you have.

One entry per voter, not a running total

Each vote is written under a key derived from the voter, rather than incrementing a shared counter.

Which removes the read-modify-write race where two simultaneous votes overwrite each other, and it makes changing a vote a matter of writing the same key again.

See the live poll tutorial for why the naive counter version loses votes.

A finite life

A TTL was set, so the poll object does not persist after the question stops being interesting.

What it took

An afternoon, most of it deciding the question and the options rather than writing code.

The component handles the rendering and the real-time updates. The application-specific parts were the token endpoint and the styling.

What we would flag

Being honest about the limits of this example.

It is a small feature. A poll is the simplest useful piece of shared state, and it is not evidence about how a complex collaborative feature would go.

The authentication already existed. A team without a session to check would have more work, and that work is the same work they would have for any feature needing to know who the user is.

And the two companies share a codebase culture, which removes a category of integration friction that a third party would meet.

What generalises

Reuse your existing session in the token endpoint. That is the pattern, and it is the difference between adding a feature and adding a subsystem.

Store per-participant entries rather than aggregates for anything counted.

Set a TTL on anything with a natural end.

And start with a small feature when evaluating a service. A poll tells you what the integration feels like at low cost, which is worth more than a longer evaluation of the documentation.

The short version

Same company builds both — read this as a worked example, not an endorsement.

The existing session did the authorisation, which is the part that generalises.

Per-voter entries rather than a running total, avoiding the counter race.

An afternoon, mostly spent on the question rather than the code.

And a small feature is the right first thing to build when evaluating any service.