Technical choices

No line in this table is there out of habit or fashion. Every technology answers a constraint named in your specification.

Layer	Technology	Why, for ERK+
Web	Nuxt — SSR + PWA	First useful paint < 3 s even on weak 4G; native offline; FR/EN built in; SEO to make you findable
Mobile	React Native	One codebase for iOS + Android with truly native rendering — smooth on the entry-level phones that dominate in Senegal
Backend	Go + PostgreSQL + Redis	2,000 concurrent users on sober infrastructure; lightweight concurrency; bank-grade ACID transactions
Media	Rust → WebAssembly	Photos compressed before upload, right on the phone: up to −70% data
Live camera	Adaptive LL-HLS streaming	Works everywhere — web, iOS, Android, unstable networks — where pure WebRTC fails behind mobile carriers
Vault	AES-256 + certified timestamping	Per-file keys, tamper-proof log, replication across 3 geographic sites
Payments	Local aggregator + internal ledger	Wave, Orange Money, MTN MoMo, Free Money & cards behind a single integration; XOF / EUR / USD
Desktop	Lightweight native app	The ERK+ Windows / macOS / Linux bonus, on the same business core — zero double maintenance
Operations	CI/CD · 3 environments · 24/7 monitoring	Continuous delivery, one-click rollback, uptime dashboards shared with you

Why Go, Rust and WebAssembly — and not "the framework of the month"

This is Vortex-Soft's engineering signature, and here it serves a concrete problem, not a talking point:

Go compiles to a single binary, starts in milliseconds and holds thousands of concurrent connections on a tiny memory footprint. On infrastructure sized for an African budget, that is the difference between holding 2,000 users and falling over.
Rust → WebAssembly puts near-native photo-compression code directly in the browser and the phone. Data shrinks before it touches the network — the only optimisation that truly matters when the bottleneck is bandwidth, not the server.
PostgreSQL brings the ACID transactions without which a payment ledger is just a spreadsheet that will eventually lie.

We do not "aim for" 3 seconds: we budget every millisecond of the journey, and going over breaks the build.

Request lifecycle

0.79s measured / 3.0s budget

The 3s ceiling is a blocking gate in our delivery pipeline — not an intention. Server-side budget above; the rest is bandwidth.

Server rendering + a CDN as close to Dakar as possible: useful content on the first network round-trip
Images adapted to the screen and to the real throughput, lazy-loaded by default
Offline mode keeps the dashboard and photos; everything syncs, in order, when the network returns
The 3-second ceiling is a blocking gate in our delivery pipeline, measured on every integration — not an end-of-project intention