Project Info

Look After

Enjoy the excitement. Leave a clue, just in case. LookAfter is a mobile-first safety planner for dates and solo meetups. It helps someone record who they are meeting, where they are going, and when they expect to check in—before that information becomes difficult to recover.

Inspiration

The idea began with a simple question: What information would be useful if someone did not return or check in as expected? In many publicly reported cases, the problem was not a lack of concern. Friends and family simply did not know which trail someone had taken, where a date was happening, why a route home had changed, or who was behind a profile shared before a meeting. A small clue recorded in advance could provide important context later. However, I did not want to build a fear-based product or another invasive tracking service. LookAfter should not monitor the person being met, demand unnecessary verification, or behave like an emergency service. It should let the user decide what information is worth leaving behind. That led to the core idea: Create a simple safety plan before leaving, check in later, and preserve a useful record if the check is missed. What LookAfter does Before a date or solo meetup, a user can create a safety plan containing: The person they are meeting The meeting place A planned safety-check time How they met A profile or social account Identifying details Transport information Their plan for getting home Any additional note that may provide useful context The additional fields are optional. LookAfter keeps the primary flow short while allowing more detail when the situation calls for it. The user can then choose between two outcomes: Nominate a trusted contact who would receive a prepared information notice after a missed safety check. Keep a server-backed safety record without a contact, allowing the plan to remain recorded even when the user does not want to involve someone else. Before starting the plan, LookAfter previews exactly what the contact notice or server record will contain. This avoids vague buttons such as “send a message” without showing the user what would actually happen. Once the plan begins, LookAfter creates a record with a unique reference number and displays: The meeting details The remaining safety-check time The nominated contact, when one exists Sequential location updates The last recorded location Options to confirm safety or extend the deadline by 30 minutes If the user confirms that they are safe, the plan closes quietly and no notice is prepared. The completed safety record remains available for review. If the safety check is missed, LookAfter waits through a short grace period before preparing the contact notice or preserving the final server record. LookAfter is not an emergency service and does not prove that someone is in danger. Its purpose is narrower: to make sure that useful information is not lost. The real-stories casebook The landing experience includes a short casebook based on publicly reported situations. These stories show several recurring information gaps: No one knew which route someone had taken. No one knew where a date was happening. A planned route home changed unexpectedly. A profile shared before a meeting later became an important clue. The casebook is not included to create panic. It explains why the product exists and helps users understand the value of recording a small amount of information before leaving. How I built it I built LookAfter as a responsive, mobile-first web application because the product is intended to be used immediately before and during a meetup. The experience is structured around explicit plan states: Drafting the safety plan Reviewing the information Starting and saving the plan Running the safety-check countdown Extending the check time Handling a missed check Confirming safety Preserving the completed record Designing these states explicitly was important. A safety product cannot rely on disconnected screens or ambiguous button behavior. Each action must lead to a predictable result, and the interface must explain that result before the user commits. The application also includes: Mobile-responsive layouts English and Korean interfaces Form validation Optional additional-detail fields Contact and contact-free record flows Message and record previews Persistent server-backed safety records Sequential demo-location updates Completed-plan records How I used Codex and GPT-5.6 Codex and GPT-5.6 were used as development tools rather than being forced into the final user experience. I used them throughout the project to: Turn the initial concept into a structured product flow Define the safety-plan states and transitions Implement and refine the mobile interface Build form validation and conditional fields Implement contact and server-record alternatives Develop the message-preview experience Find and fix mobile layout problems Review unclear language and safety-related wording Test the complete flow repeatedly Identify unnecessary verification and remove friction Compare the running application against the intended requirements I remained responsible for the product decisions, particularly around privacy, tone, demo scope, and what information LookAfter should or should not collect. Codex accelerated implementation, debugging, testing, and iteration. GPT-5.6 was most useful when translating an ambiguous safety concept into explicit states, edge cases, interface copy, and testable behavior. Challenges I faced Communicating safety without creating fear The product deals with situations that can become serious, but an alarmist interface would discourage normal use. I had to keep the experience warm, calm, and appropriate for someone who is still excited about going on a date. Balancing simplicity with useful detail A long mandatory form would make people abandon the product. A form that was too short would fail to preserve useful context. The solution was to require only the person, place, and safety-check time while keeping all other information optional. Supporting users without trusted contacts Originally, the flow focused heavily on sending a message to another person. That excluded users who did not want to involve someone else or did not have an appropriate contact. Adding a server-backed record made the product more inclusive and gave every plan a meaningful outcome. Making the message understandable A generic “SMS test” did not explain what the contact would receive or what they should do. I redesigned this as a complete message preview containing the meeting information, safety guidance, and explanatory link. Demonstrating safely within a hackathon The public build does not send real SMS messages or collect real GPS data. It uses a complete SMS preview and sequential demo locations so judges can test the full product flow without sharing personal location data or contacting a real phone number. The interface clearly labels these boundaries rather than pretending that simulated behavior is live infrastructure. What I learned The most important lesson was that a safety product is not defined only by its features. Its states, language, defaults, and failure behavior are equally important. I also learned that: Optionality is essential when handling sensitive information. Users need to see the outcome of an action before committing. A contact should receive context and guidance, not only an alarming notification. A missed check does not prove danger. A useful record can still have value without continuous surveillance. AI does not need to appear inside the product simply because AI helped build it. Codex was most valuable as an engineering collaborator that helped me move repeatedly between product thinking, implementation, testing, and refinement. What I am proud of I am proud that LookAfter became a coherent working experience rather than only a safety-app concept. The final product demonstrates the complete journey: understand the problem → create a plan → choose a fallback → review the result → start the plan → check in or extend → preserve the record Every major action is visible and understandable on a mobile screen. What is next After the hackathon, the next steps would be: Integrating an authorized SMS provider Adding consent-based live location recording Encrypting sensitive plan fields Introducing configurable grace periods Allowing multiple trusted contacts Adding automatic record-expiration controls Conducting structured usability and safety testing Consulting professionals experienced in privacy, personal safety, and crisis communication LookAfter is not intended to replace emergency services. It is a small preventive tool designed around one specific promise: If something does not go as planned, one useful clue will still remain.

LookAfter

Leave a plan. Check in. Give someone a place to start.

Live demo · Apps for Your Life · Mobile-first PWA · English and Korean

One-line description

LookAfter is a mobile safety-plan demo that lets someone leave the person, place, check-in time, and optional clues before going out, then shows what happens after a safe check-in or a missed check.

Problem

When someone is late after a first date or solo outing, a friend may not know who they planned to meet, where to begin, or whether any useful record exists. Asking people to share everything live creates a different privacy problem. LookAfter focuses on a smaller action before the outing: leave a concise plan and choose what should happen if the check is missed.

Solution

The demo creates a server-backed safety record without requiring an account. The user may name a contact or choose a server-record-only path. A completed check closes quietly. For judging, a clearly labeled simulation can move through the missed-check states immediately; it either produces a sandbox message and recipient view or stores the record without a message.

Target users

The primary demo story is a young adult preparing for a first date. The same pattern can support solo travel or any outing where a person wants to leave a small set of facts without enabling continuous surveillance.

Core user flow

Read or skip the five mobile onboarding cards.
Enter the person, meeting place, and future safety-check time.
Optionally add factual clues.
Choose a named contact or the no-contact record path.
Review the exact SMS or server-record preview.
Start the plan, inspect the record ID and simulated location events, then check in, extend by 30 minutes, or explicitly run the missed-check demo.
Review the sandbox message/recipient page or the stored record.

Key features

Server-backed D1 safety records and deterministic state transitions
Contact-selected and no-contact branches
Random record IDs plus separate owner and recipient capabilities
Exact 30-minute wall-clock extension, including midnight rollover
Three server-saved simulated location events
Server-backed SMS outbox simulation and capability-scoped recipient page
Record history for the current browser tab, record deletion, and refresh restoration
English/Korean UI, keyboard/swipe onboarding, and mobile accessibility work
PWA manifest, install icons, service worker, and an offline fallback

Contact-selected flow

A contact name and phone number are required. The public demo stores the normalized number with the record and only displays a masked value after creation. The missed-check simulation moves through CHECK_DUE and GRACE_PERIOD, builds a deterministic message, and advances the server outbox through pending, sent, and delivered. No SMS provider is called and no real SMS is sent.

No-contact safety-record flow

The user can create a plan without naming a contact. The missed-check simulation creates no outbox row and moves the record to STORED. The owner capability can still open or delete that record in the current browser tab.

Technical architecture

Client: Next.js App Router, React 19, TypeScript, and CSS
Server: Next.js route handlers compiled by vinext to a Cloudflare Worker
Database: Cloudflare D1 accessed directly through the Worker binding; Drizzle defines the schema and migrations
Hosting: OpenAI Sites configuration in .openai/hosting.json
State: React component state for the UI; D1 is the record source of truth; sessionStorage retains the draft and owner capabilities for the current tab; localStorage retains only the language preference and performs legacy migration cleanup

See submission/ARCHITECTURE.md for diagrams and implementation details.

Plan state machine

The client draft is not stored on the server. A created record begins as ACTIVE, then can become CHECK_DUE, GRACE_PERIOD, NOTIFIED or STORED, and finally SAFE or CLOSED where the relevant transition is allowed. The server validates every action.

Data model

lookafter_records stores plan text, locale, IANA time-zone label, contact choice, normalized phone number, state, and latest simulated location. lookafter_location_events stores ordered simulated events. lookafter_outbox stores one sandbox message and its simulated status per record.

Record IDs use eight random bytes rendered as uppercase hexadecimal with an LA- prefix. Owner and recipient capabilities use 32 random bytes. Only SHA-256 digests of capabilities are stored in D1.

Local-time handling

The safety-check value is stored as the entered YYYY-MM-DDTHH:mm wall-clock value, together with the browser's IANA time-zone label. It is formatted without applying a second offset. A 30-minute extension performs calendar arithmetic on the stored wall-clock fields and correctly crosses midnight. The countdown maps that value to an epoch on the current device, so changing devices or time zones is a known demo limitation; this is not a production UTC scheduler.

SMS sandbox and recipient link

The final product calls no SMS provider. The server uses a fixed template, creates one outbox row, and simulates delivery states. The message contains a public explanation link with no plan data and a separate high-entropy recipient capability URL. The raw recipient capability is not stored in D1.

Mobile and PWA experience

The UI is designed around a narrow mobile frame, safe-area spacing, large primary controls, swipe/keyboard onboarding, focus handoff, and hidden inactive carousel slides. The service worker caches only a small non-sensitive shell and never caches API responses, query-bearing pages, or the recipient page.

Privacy and safety decisions

LookAfter keeps user-entered facts unchanged at runtime. It does not judge whether another person is dangerous, contact emergency services, verify identity, or continuously track location. The public demo is not an emergency service. See submission/SECURITY_AND_PRIVACY.md.

How Codex and GPT-5.6 were used

Codex was our primary product and engineering collaborator throughout Build Week, not a one-time code generator. We used it to turn an initially broad idea about personal safety into a focused one-minute judge flow, inspect the existing code before each iteration, implement changes across the client, API, database, and PWA layers, diagnose regressions, write focused tests, verify the deployed service, and prepare the submission evidence. The repository history records that collaboration from product exploration through the final deployment.

How Codex accelerated the workflow

Rapid product iteration: We could describe a user problem in plain language, test the resulting flow, and use Codex to trace the feedback to the relevant state, copy, component, API action, and test. This shortened the loop from idea to deployed, verified behavior.
Cross-layer implementation: Codex coordinated changes that otherwise required separate passes through React UI state, Next.js route handlers, D1 migrations, capability checks, the service worker, localization, and regression tests.
Evidence-driven debugging: When the same check-in time appeared differently across screens, Codex traced the conversion path, isolated the repeated time-zone transformation, introduced a single wall-clock model for the demo, and added Perth, Sydney, UTC, Los Angeles, midnight, and repeated-extension coverage.
Continuous verification: Codex converted recurring UX failures into maintained checks. The final test command performs a production build and runs 37 tests covering onboarding, localization, time arithmetic, record transitions, contact and no-contact branches, recipient capabilities, deletion, SMS sandbox wording, and PWA cache boundaries.
Submission readiness: Codex audited the public deployment, separated verified behavior from unimplemented production features, documented limitations, prepared a one-minute judge path, and linked technical claims to code, tests, migrations, and commits.

Product and design decisions made with Codex

Codex helped challenge feature ideas against the core user need: leave a small, useful record before an outing without creating another surveillance product. That led us to:

narrow the primary story to a first date while preserving a solo-outing use case;
remove login from the judge path so the safety plan can be understood in under a minute;
require only the person, place, and future check-in time before optional clues;
support both a named-contact route and a private server-record-only route;
show the exact message or stored-record outcome before a plan starts;
keep “What if I miss the check?” informational and place the state-changing simulation behind a separate, explicit judge action;
use a mobile-first carousel, large touch targets, visible focus states, keyboard/swipe navigation, and inaccessible inactive slides; and
state clearly where SMS, GPS, background scheduling, and emergency-service integration are simulated rather than presenting demo behavior as production capability.

These choices made the experience simpler while preserving the privacy boundary: LookAfter records user-provided facts, but does not score another person, infer danger, continuously track movement, or automatically contact emergency services.

Engineering decisions made with Codex

Codex helped design and implement D1 as the server-side source of truth, deterministic transitions across ACTIVE, CHECK_DUE, GRACE_PERIOD, NOTIFIED, STORED, SAFE, and CLOSED, and separate high-entropy owner and recipient capabilities whose raw values are never stored in the database. It also helped make child inserts idempotent, prevent late actions from recreating deleted records, exclude sensitive API and recipient URLs from service-worker caching, and keep the contact and no-contact branches consistent from the preview through the server transition.

The result is deliberately testable rather than theatrical: the missed-check judge action advances real server records, the SMS demonstration uses a server-backed outbox with deterministic pending, sent, and delivered states, and the recipient page is protected by a separate capability. No SMS provider is called and the three location events are labeled demo data, not real GPS readings.

How GPT-5.6 contributed

During Build Week we implemented and tested a privacy-bounded OpenAI Responses API safety-coach prototype explicitly using gpt-5.6. Commit 449b970 added the route, UI, structured-output validation, request limits, same-origin protection, rate limiting, and safety-boundary tests; commits ad4bd51 and e4b5809 hardened and verified it. The prototype helped us evaluate where model assistance could clarify a plan and where generation introduced unacceptable ambiguity in a safety-critical flow.

That evaluation produced an important final product decision. Commit eeb36c5 removed the runtime coach so names, places, times, clues, and outbound wording remain deterministic and are never summarized, rewritten, or inferred by a model. GPT-5.6 therefore contributed both a working technical prototype and the evidence needed to choose a safer final architecture. The deployed demo has no runtime OpenAI API dependency, but the implementation and tests remain auditable in Git history.

Codex contributed the sustained reasoning, implementation, debugging, testing, and deployment workflow; GPT-5.6 contributed a concrete product experiment that clarified the final safety boundary. Detailed file- and commit-level evidence is available in submission/CODEX_GPT56_USAGE.md.

Primary Codex /feedback Session ID: TODO: USER MUST PROVIDE

What was built during OpenAI Build Week

The Git history begins on July 14, 2026, after the official submission period opened. It contains the initial app and all subsequent iterations, including the mobile onboarding, time-model regression work, contact/no-contact flow, server-backed D1 records, sandbox outbox, recipient capabilities, PWA shell, record history, and deletion flow. See submission/BUILD_WEEK_CHANGES.md.

Local setup

Prerequisite: Node.js 22.18 or newer.

npm install
npm run dev

The app runs with the project-local Cloudflare development binding. Do not use real personal data.

Environment variables

No credential is required for the one-minute demo. LOOKAFTER_BASE_URL is an optional server-side HTTPS origin override for links produced in the SMS sandbox. Copy .env.example only if that override is needed.

Sample data

Use the fictional English demo identities Maya, Alex, and Sophie. The Korean UI localizes them as 민지, 민수, and 지은. Choose any future local safety-check time and a clearly fictional phone number that passes the 7–15 digit demo validation. See submission/SAMPLE_DATA.md.

Testing instructions

npm run typecheck
npm run lint
npm test

npm test performs a production build and runs the maintained 37-test Build Week suite. Judge paths and expected results are in submission/TESTING_INSTRUCTIONS.md, and verified results are in submission/VERIFIED_TEST_RESULTS.md.

Known limitations

There is no real GPS, SMS delivery, automated scheduler, account system, identity verification, emergency-service integration, token expiry, application-level record encryption, rate limiting, audit log, or production retention policy. Current records persist in the deployed D1 database until deleted by the capability holder or removed operationally. See submission/LIMITATIONS.md.

Third-party tools and licenses

The runtime uses Next.js, React, vinext, Drizzle ORM, and Cloudflare D1/Workers. Build tooling and the complete direct-dependency notice are documented in submission/THIRD_PARTY_NOTICES.md. Image provenance and the repository's project license still require owner confirmation.

Repository structure

app/ — UI, route handlers, recipient view, and server record logic
db/, drizzle/ — D1 schema and migrations
public/ — PWA assets and project imagery
tests/ — maintained Build Week tests plus legacy suites retained for history
submission/ — Devpost-ready descriptions, evidence, testing, and checklists

Submission links

Live demo: https://lookafter-buildweek.memkeeee.chatgpt.site/
Repository configured in Git: https://github.com/seoanz7x-eng/girlslookaftereachother
Devpost project URL: TODO: USER MUST PROVIDE
Public YouTube demo: TODO: USER MUST RECORD AND UPLOAD THE REQUIRED PUBLIC YOUTUBE DEMO VIDEO.

License

TODO: USER MUST PROVIDE. No root project license file was present during the submission audit. The repository must either be made public with an owner-approved license or remain private and be shared with the two judging addresses specified in the official rules.

Analysis

Compare with all teams

View

Metric

Codex
90

Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.

Technology

Found in codeClaimed only

CSSIn code
HTMLIn code
JavaScriptIn code
Next.jsIn code
ReactIn code
SQLIn code
SupabaseIn code
Tailwind CSSIn code
TypeScriptIn code
OpenAIClaimed

9 of 10 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

No AI coding agent signals were found in this repository.

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

495 KB

Source files

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.