Web, iOS, Android and the infrastructure underneath — what TI One Voice is made of, and what it took to build it.
TI One Voice is a platform I designed, built and now operate for people who report being subjected to sustained, organised harassment. The practical problem they bring is concrete and largely unmet: years of scattered evidence, no structured way to record it, nowhere safe to keep it, and no route from a personal account into advocacy, legal process or research. The platform exists to close that gap.
I am writing it up because it is the largest system I have built, and because effectively every layer of it is mine: product and UX, backend, data model, two native mobile apps, the AI stack, the servers it runs on and the on-call rota for when they break. What follows is the engineering picture rather than the cause.
What the platform does
Six capabilities carry the product. Each one exists because members asked for it, and each one had a written design document before it had code.
- Structured evidence collection.The core of the product is an adaptive interview engine: 11 decision trees, 3,319 nodes and 780 terminal classifications that branch on previous answers, resume across sessions and turn free-form testimony into comparable, queryable records. A planner tells each member which interview to do next and why.
- Document management with provenance.Upload, OCR and full-text extraction, SHA-256 de-duplication, thumbnails, versioning, granular visibility, and expiring public share links with access logs — over a 77 GB store of 15,741 files.
- A curated knowledge base and wiki.Thousands of cross-linked source and concept articles, vector-indexed for semantic search, with an automated scoring pass that flags how much of an article is checkable claim versus speculation.
- Community and peer support.Direct and group messaging with reactions, replies, pinning and read receipts; per-conversation machine translation; a community wall, events, memorials, a buddy system, a vouched professionals directory, WebRTC calling and a 24/7 video channel.
- AI assistance.A streaming assistant with retrieval over the member's own documents and the knowledge base, document vision, a hands-free voice mode with streaming speech recognition and local speech synthesis, and automatic transcription of any audio or video that is uploaded.
- Advocacy and research tooling.A campaign builder with petitions, surveys and peer review, contact management and delivery tracking; and an analytics layer for researchers covering geographic, temporal and co-occurrence analysis, hypothesis testing with multiple-comparison correction, and exportable, de-identified evidence packages.
The architecture
The backend is an asynchronous FastAPI application: 74 routers exposing 1,251 REST endpoints, 207 service modules, and 213 PostgreSQL 16 tables behind SQLAlchemy. It is deliberately a modular monolith rather than a set of microservices. With one developer, one deploy unit and strong transactional integrity across features that genuinely share data beat the alternative — and the service-module boundary gives most of the separation a service mesh would have, at none of the operational cost.
Figure 1 — System architecture. Clients, edge, application, data and AI layers, with the two-node cluster and operations underneath.
Search and retrieval run on pgvector inside PostgreSQL plus a FAISS index with sentence-transformers embeddings, which is what makes the assistant able to answer from a member's own files. Realtime traffic — presence, typing, delivery, badges — goes over a WebSocket hub rather than polling. Long or expensive work (PDF rendering, OCR, embeddings, digests, campaign sends) is pushed onto background workers so no request blocks on it.
The web client is a React 18 single-page app of 94 pages and 182 components. The mobile apps are genuinely native — Swift on iOS, Kotlin on Android — rather than a wrapped web view, because the security features that matter most here need platform APIs: biometric-gated key storage, certificate pinning and a panic mode.
Underneath, the platform runs on hardware I own. Two nodes — an active macOS host and a hot-standby Linux host — are kept in step by PostgreSQL logical replication plus an application-level change-data-capture log that carries what replication alone cannot. Releases go out blue-green, so a deploy never drops a request; a watchdog daemon restarts anything that dies; and the full 131 GB corpus goes to encrypted off-site backup on a schedule I can restore from and have tested.
Security and evidence integrity
People who believe they are being watched have no tolerance for a platform that leaks, and evidence that cannot be shown to be untampered is not evidence. Both constraints shaped the design rather than following it.
- Layered authentication.Passwords with TOTP or email second factors, WebAuthn passkeys, federated sign-in, and DPoP — sender-constrained tokens bound to a device key and gated behind biometrics on mobile, so a stolen token is worthless off the device that minted it.
- High-risk action gating.Step-up re-authentication on exports and account changes, live session revocation, login-location alerts, and recovery paths that were tested against the case where the member has lost their second factor.
- Edge defence.An intrusion-detection layer with IP reputation feeds, honeypot endpoints, bot and spam classification, and rate limiting that keeps the platform's own traffic from tripping it.
- Provable integrity.Every document event and every declaration signature is appended to a SHA-256 hash chain, and documents receive RFC 3161 timestamps from a public timestamping authority. That a given file existed in a given state at a given moment can therefore be verified without trusting the platform, or me.
- Privacy by construction.Per-item visibility from private through signatory-only to public, de-identified research exports, and deletion that is auditable end to end.
What the data looks like
The platform is small but real, and the numbers are the live ones as of 16 September 2026. 808 people have registered; 501 of them have signed the platform's declaration; 257 have signed in within the last 30 days. They are spread across 53 countries, with the United States accounting for 55% of signatories — a concentration that shapes how the research layer is allowed to generalise.
Alongside the 16,237 documents sit 3,855 structured reports of specific reported experiences, produced by the interview engine rather than typed into a free-text box — which is precisely what makes them countable. That structure is the point: it is the difference between a pile of testimony and a dataset a researcher or a lawyer can work with.
It is also why the analytics layer is conservative by design. With a sample this size and this skewed, it applies multiple-comparison correction, reports confidence intervals rather than bare percentages, and declines to state effects the data cannot support. Building the restraint into the tool was a deliberate choice.
Figure 2 — Community growth and reach. Left: new signatories per month during 2026. Right: signatories by country.
Building it
683,000 lines of application code across four codebases, 1,726 commits, February to September 2026, one developer. The user interface ships in 50 languages across the web app, iOS and Android — three separate localisation systems that have to stay in lockstep.
Figure 3 — Engineering surface area. Code volume by client and platform-wide counts.
Three things made that pace possible. First, specification before code: 32 functional design documents — 57 versioned drafts — were written and reviewed before the features they describe existed, which is also why the system still has a coherent shape. Second, heavy use of AI coding assistance under strict review — the productivity gain is real, and so is the failure mode when the output is not read carefully. Third, treating operations as part of the job: automated deploys, a watchdog, intrusion detection and a tested backup mean incidents cost hours rather than weeks.
What I would take to the next system is mostly the unglamorous half. Write the design document. Make integrity verifiable by someone who does not trust you. Assume the deploy will happen mid-transaction. And decide early what the data is honestly allowed to say — because for the people on the other end of this one, being over-claimed on is its own kind of harm.
Stack. Python · FastAPI · SQLAlchemy · PostgreSQL 16 · pgvector · FAISS · React 18 · Vite · Tailwind · Swift/SwiftUI · Kotlin · Caddy · WebRTC · LiveKit · FFmpeg · Whisper · Piper · DeepSeek / Ollama · WebAuthn · DPoP · RFC 3161
The platform is at one.witysk.org. I am happy to walk through any part of the architecture in detail.