Documentation

How Incico is designed and built: the product, the app, the platform and the decisions behind them.

Product

Overview

What Incico is, why version 3 exists, what it keeps from versions 1 and 2, and what it sets out to achieve.

Concepts and glossary

The nouns of Incico, defined once, with their Dutch equivalents as used in the app.

Personas and scenarios

Four representative users and the end-to-end scenarios the design is checked against.

Design principles

The rules that settle arguments while building Incico v3.

Brand and assets

The Incico logo, its colours and typography, and where every brand and marketing asset lives in the repository.

App design

Navigation and screen map

Every screen in the app, how they connect, and the navigation rules both platforms follow.

Sign-in and onboarding

The sign-in screen, account creation and verification, and the guided first-run flow that builds the first profile.

Profile and details

The Profile tab: viewing and editing names, phone numbers, e-mail addresses, addresses, special dates and photos, custom types, verification and the per-detail circle selector.

Sharing circles

The Circles tab: creating, editing and deleting circles, seeing what a circle can see, and moving contacts between circles.

Contacts and invitations

The Contacts tab: finding people, sending and answering invitations, the contact card, favourites, nicknames, relations, removing and blocking.

The Services tab: connecting the phone's address book and Google Contacts, choosing circles, running a sync, resolving the reconciliation buckets, and cross-referencing an address book against Incico.

Notifications

Every notification the app produces, how it is delivered (in-app, push, e-mail), its wording, and what the user can control.

Settings and account

Everything under the gear: appearance, language, contact display, notifications, devices, privacy (export, delete, blocked, telemetry), help and about.

Tablets and adaptive layout

How the app lays itself out on iPads and Android tablets, following the Saymail tablet specification.

Visual design system

Colour tokens, typography, spacing, radii, components and motion shared by both apps: the circle-first look decided on 2026-10-29 (A101).

Offline behaviour and data sync

How the app keeps a local copy of everything the user may see, how it learns about changes, and what happens without a network.

Platform & data

Architecture overview

How the native apps, Supabase and the website fit together in Incico v3.

Data model

Every table, column and enum in the Incico v3 Postgres schema, with the reasoning behind each.

Access control and visibility

How row-level security, security-definer functions and snapshots guarantee that a detail is only ever seen by the circles it was shared with.

Security design

Threats, the security problems found in v1 and v2, and the concrete measures v3 takes against each.

Supabase backend

Project setup, Auth configuration, edge functions, storage buckets, realtime, push delivery and the deployment script.

Languages and accessibility

Supported languages, how translations are structured and tested, and the accessibility bar both apps must meet.

Telemetry and privacy

What the apps measure, what they never send, consent, crash reporting, and the data inventory behind the store privacy labels.

Delivery

Tech stack and coding guidelines

Languages, frameworks, project structure and the coding rules both apps follow, taken from the Saymail mobile apps.

Repository layout and git strategy

The IncicoV3 monorepo layout and the main/develop branching model inherited from Saymail.

Build, sign and release

How Android is built on the Windows PC, how iOS is built headlessly on the Mac mini, and how a release reaches the stores.

Testing strategy

What is tested where: Postgres rules with pgTAP, edge functions with Deno, app logic with unit tests, screens with UI tests, and the full flow end to end.

Roadmap and phases

The order in which Incico v3 is built, what each phase delivers, and what is explicitly deferred.

End-to-end test process

How the whole Android app is tested end to end: what runs, against what, which scenarios cover which part of the design, when the suite must be green, and how a failure is handled.