Alan Mortoni

Personal project · Active

Civicbase

A survey platform for measuring not only what people prefer, but how strongly they prefer it.

Civicbase turns Quadratic Voting for Survey Research into a complete consultation workflow: create and pilot a survey, collect responses, then interpret preference signals alongside their participation context.

I designed and built the current platform as sole engineer, covering the participant experience, researcher tools, backend, infrastructure, testing, and public methodology.

Open app ↗
Survey researchCivic technologyPreference intensityStructured consultation

Why I built it

A colleague approached me in 2020 to build a Quadratic Voting for Survey Research platform for the University of Michigan, in collaboration with Madeline, Chen, and Charlotte. I was hired to build the full platform, and the commissioned work later extended to a World Bank engagement.

That work showed me that the voting interaction was only one part of the problem. Researchers also needed a dependable way to prepare a survey, test it as a pilot, control participation, understand the response context, and preserve the result. Civicbase is my independent continuation of that work, built across roughly seven months of active development.

In the participant experience

Casting a quadratic vote. The pool on the left is the participant's budget: hovering a thumb previews what that press would cost, and each additional level of support costs more than the last. Pressing the opposite thumb hands the credits back, so support for one proposal is always weighed against the others.

The method

A conventional survey can show which option someone selected, but not how strongly they preferred it or what they would give up for it. In Civicbase, each participant receives a fixed credit budget and distributes it across the available proposals.

Stronger support costs progressively more: one level costs one credit, while four levels cost sixteen. Spending heavily on one proposal leaves fewer credits for the others, so the completed allocation expresses priorities and trade-offs rather than a simple ranking.

The product model

Surveys
Researchers define the questions, credit budget, participation rules, and messages that shape a consultation.
Deployments
A survey moves through pilot, published, and finished stages. Each stage makes its status clear and limits which changes remain safe.
Participation
Participants distribute a limited credit budget across proposals, expressing both direction and strength of preference.
Preference signals
Analytics describe breadth, intensity, direction, and non-response without turning those signals into a recommendation.
Integrity
Hash-chained deployment and survey events make later tampering with recorded activity detectable.

One consultation lifecycle

The platform treats a consultation as a sequence with explicit boundaries. A pilot is not a live result, and a finished survey is not still open for change.

  1. 01

    Create the survey

    Define the questions, available credits, participation limits, and the guidance shown to participants.

  2. 02

    Run a pilot

    Test the complete participant experience and review confidence checks before accepting live responses.

  3. 03

    Publish

    Open the consultation to its intended audience while protecting structural choices once responses exist.

  4. 04

    Read the signals

    Review participation and preference patterns together so a strong-looking result is not separated from its response context.

  5. 05

    Finish and export

    Close response collection, preserve the completed deployment, and export the data for further research.

In the organiser experience

The Civicbase dashboard listing six surveys, each labelled with its stage—published, pilot, or finished—alongside counts for the whole workspace.
The organiser's view. Every survey carries its stage on the card—pilot, published, or finished—so a consultation still being tested in test mode is never mistaken for one that has collected real responses.
The analytics view of a published survey, showing participation rate, device and browser breakdowns, a map of where responses came from, and responses over time.
Analytics for the platform's built-in demo survey. Participation is reported alongside the response count, because a consultation that reached few people is a different result from one that reached many—and organisers need to see which they have before reading the preferences.

The engineering follows the research

The important architecture is not the framework list. It is how the platform keeps the meaning of a survey consistent from the researcher's form to the participant's response and the final analytics.

  1. 01

    Frontend and backend share the same rules

    A shared TypeScript package owns survey schemas, validation, analytics calculations, exports, and report contracts so the two sides do not develop different meanings for the same data.

  2. 02

    Lifecycle state protects research integrity

    Pilot, published, and finished are product rules rather than decorative labels. Once a published survey has responses, structural edits are locked while safe copy changes remain possible.

  3. 03

    Analytics stop at evidence

    The platform presents preference signals and their context, but it does not tell an organiser what decision to make from them.

  4. 04

    Trust is built across the workflow

    Security rules, pilot checks, integrity events, automated tests, and explicit failure states support the consultation from setup through export.

Current state

Civicbase is live and currently covers the full survey lifecycle: creation, pilot testing, publication, response collection, preference analytics, reporting, collaboration, and export.

It remains an active personal project. I continue to develop it around the practical needs of researchers, organisers, and participants while keeping the interpretation of results deliberately neutral.

Technologies

Application
React 19, TypeScript, Vite, MobX, Tailwind CSS, shadcn/ui
Platform
Firebase Authentication, Firestore, Cloud Functions, Storage, and Hosting
Shared contracts
@civicbase/core, Zod, React Hook Form, TipTap, Recharts, pnpm workspaces
Product quality
Vitest, Firebase Emulator Suite, Playwright, GitHub Actions, accessibility checks

Civicbase is built around a simple boundary: the platform should make preference intensity easier to express and understand, while leaving the decision itself with the people responsible for it.