Overview
What Incico is, why version 3 exists, what it keeps from versions 1 and 2, and what it sets out to achieve.
Updated: 12 September 2026
Incico (Inner Circle Contacts) keeps the contact details people share with each other correct without anyone having to ask. You maintain your own details once. You decide, per detail, which of your sharing circles may see it. Everyone you are connected with receives the version meant for their circle, automatically, and can push it on into their own address book. The tagline since v2: Never ask “new number?” again.
Why a version 3
| Version 1 (released) | Version 2 (never released) | Version 3 (this design) | |
|---|---|---|---|
| Client | Blazor shared UI in .NET MAUI Hybrid and Blazor WASM | React Native with Expo | Native Kotlin/Compose and Swift/SwiftUI |
| Backend | ASP.NET Core API + Duende IdentityServer + Azure (SQL, Service Bus, Blob, Container Apps) | Mock API with a documented REST contract | Supabase (Postgres, Auth, Storage, Edge Functions, Realtime) |
| State | Live, little used | Rich functional design, unfinished, insecure placeholders | To be built |
| Security | Serious defects (TLS validation off, secrets in source) | Placeholder auth, service-account key in repo | Designed in from the start |
v1 proved the product idea and the data model but shipped with a heavy, expensive backend and security defects. v2 rethought the experience (onboarding as a guided flow, four-tab dashboard, richer detail sharing such as hiding a birth year, field-level address sharing, custom types, cross-referencing an address book against Incico) but never got a real backend. v3 takes v2’s functional design, v1’s hard-won rules, Saymail’s native-app engineering practice, and a backend that a one-person company can run.
Goals
- Works like v2. Every v2 screen and flow exists in v3 unless this design explicitly retires it, with the same names and the same order of steps.
- Twin native apps. Android and iOS look and behave the same, on phones and on tablets, built from one specification the way Saymail’s mobile apps are.
- Privacy you can verify. Visibility rules are enforced in the database and covered by tests, not implemented in the client.
- Cheap to run. One Supabase project, no servers to patch, no identity server.
- Free for users. No ads at launch; a later optional supporter purchase is possible but not designed in detail.
Non-goals for v3.0
Web app, business profiles, family auto-connect trees, SMS verification, German, ads. See Roadmap.
Who it is for
People who keep in touch with a stable inner circle (family, close friends, colleagues, a sports club) and are tired of stale address books: the parent whose children’s friends’ parents move house, the freelancer with a work number and a private number, the grandparent who wants birthdays to be right. See Personas and scenarios.
How to read this documentation
- Product explains the concepts and the language.
- App design describes every screen and flow, platform-agnostic, in the order a user meets them.
- Platform & data covers the database, access rules, security and Supabase.
- Delivery covers stack, repository, build, test and phases.
- Decisions & questions lists the assumptions made without asking and the product owner’s answers to the twenty questions on the questions page.
Each page carries a status: decided (built, or confirmed by the product owner), proposed (written but not yet built or confirmed), draft (incomplete). Since 2026-10-30 every page describes what the Android app does and is decided.