Tpomail — Private Verification Inbox

Built solo with GPT-5.6 + Codex: a bilingual serverless verification inbox on OpenAI Sites with deterministic extraction and a public Replay Lab.

Comment 1

Inspiration

Verification emails are tiny, but conventional inboxes make them unnecessarily slow to use. A one-time code can be buried inside branding, legal text, tracking content, and unrelated links. When operating temporary addresses across several owned domains, repeatedly locating the right message, code, or action link becomes distracting.

I built Tpomail as a focused, private inbox for one job: receive verification mail, retain only what is useful, and make the next action obvious.

What existed before Build Week

The core Tpomail mailbox existed before OpenAI Build Week. It already provided:

A private, single-user inbox protected by TOTP authentication Email reception across 10 owned domains Random and custom mailbox prefixes Mailbox deactivation and restoration Text-only message storage Gzip compression and seven-day retention A lightweight Cloudflare Email Routing, Worker, and D1 architecture An interface hosted with OpenAI Sites

The system intentionally does not use R2, Queues, or Durable Objects. This keeps the architecture understandable and appropriate for a small, single-operator mailbox.

What I built during Build Week

For Build Week, I created the Verification Replay Lab: a public, synthetic demonstration of Tpomail’s verification-extraction workflow.

The Replay Lab lets judges replay representative verification messages without exposing the private inbox or any real email. The complete product interface is bilingual in Chinese and English, while the synthetic message fixtures remain stable so extraction behaves identically in both languages.

It demonstrates how the product:

Detects likely one-time verification codes Makes a detected code available for one-click copying Collects links from the message Filters common footer destinations such as privacy, help, and unsubscribe pages Surfaces the strongest public HTTPS action-link candidate Provides separate Open Link and Copy actions

I also added compact sender-brand badges for recognized Instagram, Microsoft, Facebook, and YouTube addresses.

Brand recognition uses the domain from a strictly parsed From address. A badge is shown only when that domain matches an allowlisted brand domain at an exact domain or subdomain boundary. Naive substring matching is deliberately avoided, and regression tests cover lookalike domains and suffix-spoof patterns.

These badges are a visual convenience for quickly recognizing familiar senders. Every badge is explicitly labeled as an unverified From-domain match—not sender authentication—and does not claim that an email is authentic. Tpomail also does not describe a selected link as “safe.” It presents a deterministic candidate based on visible, explainable rules, while leaving the final decision to the user.

How it works

Incoming email is accepted through Cloudflare Email Routing and processed by a lightweight Worker. The pipeline normalizes the message into plain text, removes unnecessary presentation content, compresses the retained record with gzip, and stores it in D1. Messages expire after seven days.

The extraction layer is deterministic rather than model-dependent at runtime. It normalizes the subject and body, identifies likely code candidates, gathers visible and embedded links, removes low-value footer links, and ranks the remaining action candidates.

Sender-brand recognition follows the same deterministic approach. It parses the sender mailbox, extracts its canonical domain, and compares it against a small allowlist using strict domain boundaries. Addresses containing a brand name inside an unrelated or deceptive domain do not receive a badge.

The authenticated Tpomail interface provides the operational inbox, while the public Replay Lab provides an isolated proof surface built entirely from synthetic fixtures.

Built solo with GPT-5.6 + OpenAI Codex

Tpomail was built by one human working with GPT-5.6 through OpenAI Codex as an end-to-end engineering agent. Codex did much more than generate snippets: it inspected the existing product, implemented and refined features, operated the terminal and browser, tested real workflows, managed infrastructure and deployments, produced submission media, and maintained the GitHub and Devpost project surfaces.

Native OpenAI capabilities used

  • GPT-5.6 reasoning: decomposed product requirements, reviewed architecture and privacy boundaries, designed deterministic extraction rules, evaluated sender-trust risks, refined bilingual UX, and converted feedback into testable implementation decisions.
  • Codex software engineering: audited the pre-event codebase and implemented or refined the bilingual inbox, six-digit TOTP auto-submit, mailbox lifecycle UX, waiting mode, adaptive refresh, notes and tags, rules, pagination, time sorting, code and action-link extraction, sender-domain badges, resource metrics, and the public Replay Lab.
  • Codex terminal and testing: ran builds, linting, contract tests, behavior tests, regression checks, Git operations, deployment packaging, and media-processing commands. The release passed 253 automated checks.
  • OpenAI Sites: built, hosted, versioned, and published the web application as a serverless Sites project, including the authenticated product and its public bilingual demo.
  • OpenAI ImageGen: created the visual cover and thumbnail assets used in the submission media package.
  • Codex browser control: exercised the actual interface with synthetic inboxes, a mock account, and mock six-digit TOTP data; it validated language switching, mailbox switching, code copying, invitation-link handling, waiting mode, rules, and resource reporting without exposing production email.
  • Codex media production: planned and recorded a 78.7-second English product walkthrough, prepared English SRT subtitles and YouTube metadata, checked rendered frames and audio, and packaged the final 1080p video.
  • Devpost integration: used the Devpost connector to prepare and update the public project story, technology details, testing instructions, links, and submission metadata.
  • GitHub workflow: maintained the README, documented how Codex and GPT-5.6 were used, committed and pushed the implementation branch, and prepared the repository for judge access.
  • Cloudflare operations through Codex: Codex used Cloudflare APIs and CLI tooling to configure and verify the serverless mail path across ten owned domains, including DNS and Email Routing, a deliberately thin ingestion Worker, and D1-backed storage.

Build-time AI assistance vs. runtime architecture

GPT-5.6 and Codex were used to design, implement, operate, test, deploy, document, and demonstrate Tpomail. They are not placed in the live email-delivery path, and receiving an email does not require a per-message model call.

The production runtime remains deterministic and lightweight:

  1. Email arrives through Cloudflare Email Routing on one of ten configured domains.
  2. A thin Cloudflare Worker validates and streams the inbound message.
  3. The OpenAI Sites application normalizes and extracts compact text-focused data.
  4. Compressed message data is retained in Cloudflare D1 for seven days.
  5. The authenticated bilingual Sites interface provides mailbox controls, code and link actions, rules, and resource views.

The service intentionally uses no R2, Queue, or Durable Objects. This separation keeps runtime cost predictable while demonstrating how GPT-5.6, Codex, and OpenAI-native tools can carry a real product from architecture and infrastructure through implementation, verification, deployment, media production, and a judge-ready submission.

Challenges

The hardest challenge was deciding what “the important part” of an email means without relying on an opaque runtime model. A six-digit number may be a verification code, but it may also be a date, reference number, or footer value. Likewise, an email may contain many valid links even though only one advances the intended workflow.

Sender-brand badges introduced a separate trust challenge. A naive check such as “the sender contains microsoft.com” could label a suffix-spoofed or lookalike domain incorrectly. The matcher therefore operates only on the parsed sender domain, requires exact domain boundaries, and is protected by negative regression cases. The interface also states the correct trust boundary: a badge helps recognition but does not authenticate the sender.

Another challenge was demonstrating the system publicly without leaking private mailbox data. The Replay Lab solves this with synthetic messages that exercise the same narrow workflow while remaining separate from the authenticated inbox.

Finally, I wanted to improve the product without expanding its infrastructure unnecessarily. Keeping the design within Email Routing, a lightweight Worker, D1, and OpenAI Sites required deliberate decisions about compression, retention, polling, and storage.

What I learned

This project reinforced that a narrow workflow can benefit from deterministic, explainable automation. For verification mail, predictable extraction rules and explicit user actions can be more useful than adding a runtime AI dependency.

I also learned that recognition and verification must remain separate concepts. A small brand badge can improve scanning speed, but the matching rules and interface language must not imply an authentication guarantee that the system does not provide.

A synthetic replay environment proved to be an effective way to demonstrate private software. It gives judges a reproducible experience while preserving the boundary around real user data.

Most importantly, Codex and GPT-5.6 helped turn an existing utility into a clearly scoped, testable Build Week extension—and made the reasoning behind the product visible rather than hidden.

Built With

Share this project:

Updates