Tellex

Tellex in new form of social network provide internal Tellex numbers, an opt-in Telephone Index, a private notebook, permission-based call requests, and LiveKit voice rooms.

Comment

Tellex - The Telephone Index Reimagined

Inspiration

Telephone directories once gave every person and place a memorable number. Calling felt deliberate: you looked someone up, dialed carefully, and waited for a real conversation.

Modern communication is faster, but it often creates the opposite experience. Personal phone numbers are sensitive, unexpected calls feel intrusive, and social platforms prioritize feeds and messages over focused voice conversations.

Tellex started with a simple question: Can we bring back the human intention of the telephone directory while adding the privacy, consent, and accessibility people expect today?

What It Does

Tellex is a consent-first telephone directory for voice conversations.

  • Every user receives a private Tellex number. Their real phone number is used for verification but is never exposed in the public directory.
  • The Telephone Index is opt-in. Users can publish a safe display name, Tellex number, headline, and interests without publishing private contact details.
  • Availability is explicit. A user decides when they are available and which eligible people may request a call.
  • The private Notebook lets each user save contacts, favorites, and personal notes. Notebook data is owner-only and does not become part of the public profile.
  • The signature rotary dial is functional, not decorative. It is paired with keypad and typed-input alternatives for accessibility.
  • Entering a number first resolves a minimal public identity. The caller then chooses a conversation topic and sends a call request.
  • The recipient sees who is requesting the call, its context, and a countdown. They can accept or decline. A voice room is authorized only after acceptance.
  • During a call, either participant can mute, change speaker routing, reconnect, or end at any time.
  • Reserved number 140 opens the Telephone Index, while 00 is protected for future technical support behavior.

The result is intentionally different from both a traditional phone dialer and a social network: Tellex helps people become reachable without making them exposed.

How We Built It

Tellex uses a modular architecture with a strict control-plane/media-plane boundary.

  • Laravel 13 is the control plane. It owns authentication, phone verification boundaries, internal number assignment, directory visibility, availability, call permission, call state, auditing, and LiveKit token issuance.
  • PostgreSQL is authoritative for durable identity, directory, Notebook, and call records.
  • Redis owns short-lived presence, coordination locks, rate limits, and queue workloads. Permission checks fail closed when required presence state is unavailable.
  • LiveKit is the media plane. Clients never receive provider secrets; they request short-lived participant tokens from Laravel after an accepted call exists.
  • Flutter and Riverpod power the mobile experience, secure session restoration, typed API access, connectivity recovery, rotary interaction, call reconciliation, and active-call controls.
  • Docker Compose runs the repeatable local stack: Laravel, PostgreSQL, Redis, queues, scheduler, MinIO, and LiveKit.

The interface follows a Premium Vintage Telephone Exchange direction. Archival paper, Bakelite, brass, burgundy, olive panels, number plates, and indicator lights create the nostalgic identity. Interactive text and controls remain native Flutter widgets so the visual style does not compromise dynamic type, contrast, screen-reader semantics, or touch targets.

How We Used Codex and GPT-5.6

Tellex existed before Build Week as a docs-first Laravel backend. The pre-competition baseline is preserved at commit 2be38bc, and only later commits are presented as Build Week work.

During Build Week, I used Codex with GPT-5.6 to meaningfully extend that backend into a runnable product experience. Codex helped:

  • scaffold and structure the Flutter application around Riverpod;
  • connect authentication, directory, Notebook, availability, and presence APIs;
  • implement exact-number resolution, rotary dialing, and the consent-based call-request UI;
  • integrate Laravel-authorized LiveKit joining and active-call controls;
  • harden offline recovery and lifecycle reconciliation;
  • create the Premium Vintage visual system and responsive components;
  • run automated tests, Web packaging, Android APK builds, emulator checks, and real local-flow smoke tests;
  • document the boundary between pre-existing work and the competition extension.

I retained the product decisions: preserve the original Tellex concept, require phone verification and call consent, keep Laravel authoritative, never move permission logic into Flutter, and reject moodboard ideas that implied direct calls, public phone numbers, chat, or an artificial call-duration limit.

Challenges We Faced

Keeping Two Clients in One Consistent Call State

A call request crosses PostgreSQL records, Redis presence and locks, two mobile clients, and a LiveKit room. Duplicate taps, expiry, reconnects, and simultaneous acceptance can create races. We addressed this with durable state transitions, participant-scoped locks, idempotent actions, server reconciliation endpoints, and repeated permission checks at both request creation and acceptance.

Making Local Testing Behave Like a Real Product

The mobile client, Laravel, Redis, and LiveKit had to work together across emulator networking and short-lived sessions. Real two-user smoke testing exposed Redis prefix behavior that isolated unit tests had not revealed. Fixing the underlying coordination commands made the local flow repeatable instead of hiding the issue in demo-only logic.

Balancing Nostalgia With Usability

The first visual pass was accessible but too generic. A literal recreation of the moodboards would have introduced fake features and fragile layouts. We separated semantic state colors from physical materials, generated only subtle text-free textures, kept all controls native, and tested narrow 320px layouts at 200% text scaling.

Staying Honest About Readiness

The local product slice is working and testable, but production TURN/STUN evidence, background push delivery, the production OTP provider, persistent Trust & Safety workflows, and a full administration panel remain future work. We document these limits instead of presenting local verification as production readiness.

Accomplishments We Are Proud Of

  • Turned a backend architecture into a coherent, runnable Flutter product during Build Week.
  • Preserved privacy and consent rules across UI, APIs, Redis coordination, and media authorization.
  • Built a recognizable rotary interaction with accessible keypad and typing alternatives.
  • Created a visual identity that communicates the idea before the user reads an explanation.
  • Passed 52 Flutter tests with a clean analyzer, Web release build, Android debug APK, and Android light/dark visual QA.
  • Kept secrets, OTP values, provider credentials, and private Notebook content out of the client and repository.

What We Learned

The largest lesson was that a voice product is not primarily a media problem. The difficult part is deciding who may reach whom, under which state, and how every client recovers when that state changes.

We also learned that AI-assisted engineering works best when architecture and product decisions remain explicit. Codex accelerated implementation, testing, debugging, documentation, and design iteration, while the project constraints prevented speed from becoming inconsistency.

Finally, real local flows mattered more than isolated success. Running two identities against the actual PostgreSQL and Redis stack revealed integration behavior that mocks could not.

What's Next

  • Complete two-device media evidence across real networks and production TURN/STUN validation.
  • Add background incoming-call delivery through the selected push provider.
  • Implement persistent block, report, restriction, and moderation workflows.
  • Complete Arabic and English localization, RTL verification, and the final accessibility audit.
  • Build the least-privilege operational administration panel.
  • Publish a judge-accessible test build or hosted demo with documented test accounts.

Tellex is built around one belief: a number can make someone reachable without making them exposed.

Built With

Flutter · Dart · Riverpod · Laravel 13 · PHP · PostgreSQL · Redis · LiveKit · Docker Compose · MinIO · Codex · GPT-5.6 Sol ·

Built With

Share this project:

Updates