KVN
System registry
SYS-0052026-06–present

Trippy

A beta travel-planning product that turns flexible trip plans, places, tickets, and practical details into one navigable timeline.

TypeProductEngagementOwnedTierCase StudyStateTestingActivityPaused
Open Trippy
01

Context

Trippy organizes personal travel around a timeline rather than a booking catalogue. A trip can connect destinations, saved places, multi-leg travel, stays, events, transfers, tickets, links, checklists, media, weather, and a focused Today view. The system accepts incomplete plans, generates timeline-visible occurrences from travel intent, calculates useful gaps when exact chronology exists, and positions untimed items without inventing false timestamps.

Core engineering problem

Keep the practical information needed during a trip—sequence, locations, tickets, links, timing, and free gaps—in one lightweight personal timeline.

Travel information is often split across booking messages, map links, files, notes, and separate apps. Trippy separates a planned travel object from the concrete timeline occurrences a person needs to follow, while keeping sparse or uncertain plans useful.

  • Keep incomplete plans useful by leaving most trip and timeline fields optional.
  • Distinguish exact chronology from fallback windows and explicit placement of untimed items.
  • Enforce owner or membership scope across trips, timeline data, sharing, and media.
  • Keep ticket documents and trip media behind authenticated access checks.
  • Extract useful context from supported map links without requiring every place to use an external lookup.
  • Isolate development, staging, and production-style services and persistent state.
02

My role

I created Trippy and own its product direction, architecture, full-stack implementation, deployment, and review.

Contribution boundaries

  • Beta MaturityThe public beta is deployed, but development is currently paused while Trippy remains a lower priority and waits for real-user feedback about its direction.
Owned

Product Direction

Product concept, travel-planning behavior, requirements, and beta direction.

OwnedDesignedDirected
Architected

Application Engineering

Django REST API, Next.js interface, trip and timeline domains, permissions, maps, media, and collaboration workflows.

ArchitectedModelledImplementedMaintainedReviewed
Designed

Integrations

Map-link interpretation, directions links, weather data, and authenticated media access.

DesignedImplementedIntegratedReviewed

Deployment And Operations

Containerized environments and the public beta deployment.

DesignedImplementedDeployedMaintained
03

Architecture

Level 01 / System

System context

07 boundaries · 08 declared relationships

  1. 01Responsive Trippy web applicationClient
  2. 02Next.js application and same-origin proxyService
  3. 03Django REST APIAPI
  4. 04PostgreSQL trip data storeDatastore
  5. 05Protected ticket and media storageDatastore
  6. 06Map links and weather providerExternal Provider
  7. 07Containerized application runtimeInfrastructure
Relationship mapInspect 08 connections
  • Responsive Trippy web applicationRequestNext.js application and same-origin proxy
  • Next.js application and same-origin proxyRequestDjango REST API
  • Django REST APIPersistencePostgreSQL trip data store
  • Django REST APIPersistenceProtected ticket and media storage
  • Django REST APIIntegrationMap links and weather provider
  • Containerized application runtimeHostingNext.js application and same-origin proxy
  • Containerized application runtimeHostingDjango REST API
  • Containerized application runtimeHostingPostgreSQL trip data store
04

Engineering decisions

01

Separate travel plans from timeline occurrences

Context

One user intent can represent a multi-leg journey or stay while the usable timeline needs distinct departures, arrivals, check-ins, and check-outs.

Selected approach

Model travel intent as a flexible plan and derive stable timeline occurrences through a dedicated synchronizer.

Rationale

Keep editing coherent at the plan level while producing an explicit, orderable timeline for use during the trip.

Trade-offs

  • Synchronization must preserve occurrence state and remove stale generated items safely.
  • Plan-level and occurrence-level data coexist while legacy items remain supported.
02

Keep incomplete plans useful without inventing time

Context

Real travel plans often contain a place or sequence before exact dates and times are known.

Selected approach

Combine exact chronology, safe fallback windows, manual order, and explicit anchors for selected untimed occurrences.

Rationale

Support planning in stages without presenting uncertain timing as fact.

Trade-offs

  • Ordering rules are more complex than a single datetime sort.
  • Gap calculations must ignore fallback anchors that are not committed moments.
03

Keep provider data separate from user-owned place data

Context

A saved place may begin as manual input and later gain provider metadata.

Selected approach

Persist user-owned and provider-supplied attributes separately and resolve effective values deliberately.

Rationale

Preserve user intent while allowing provider enrichment and reuse.

Trade-offs

  • Read paths must choose effective values consistently.
  • Matching and deduplication require normalized identities and coordinates.
04

Keep private travel files behind authorization checks

Context

Ticket files, booking references, and travel media can contain sensitive personal information.

Selected approach

Store files in private application storage and serve downloads through trip-scoped API views.

Rationale

Keep quick access without weakening the access boundary used for trip data.

Trade-offs

  • The application handles download traffic.
  • Object storage and presigned access remain future options.
05

Runtime ownership

  1. 01
    Containerization

    Separate Compose definitions keep frontend, backend, and database services isolated by environment.

  2. 02
    Reverse Proxy

    Host-level routing keeps the public beta separate from the application containers.

  3. 03
    Hosting

    I deployed and maintain the public beta application.

  4. 04
    Storage

    PostgreSQL persists application state and private mounted storage holds protected files.

  5. 05
    Deployment

    Development, staging, and production-style stacks use environment-provided configuration and separate runtime definitions.

    Inspect operational detail
    • The public beta was reachable during portfolio intake.
06

Current state

  1. Current

    The public Trippy beta is deployed while product development waits for real-user direction.

  2. Lesson

    Keep travel intent separate from the timeline items a traveler actually follows.

  3. Lesson

    Untimed plans need explicit placement rules instead of made-up timestamps.

  4. Lesson

    A technically working beta still needs real-user feedback before its product direction is settled.

Depth B / Technical inspection

Inspect supporting evidence

Domains, provider boundaries, and evidence classifications.

T1

Domain structure

  • Trips, destinations, and placesUser-owned trips, reusable places, trip-specific associations, ordered destinations, dates, timezone, currency, and visibility.
  • Travel plans and generated occurrencesFlexible plans for multi-leg travel, stays, events, activities, transfers, reminders, and their timeline-visible occurrences.
  • Timeline order and gapsExact times, preparation time, hotel windows, calculated gaps, manual order, and anchored placement for otherwise untimed items.
  • Maps and travel contextSaved coordinates, map-link interpretation, place links, transfer directions, current weather, and destination context.
  • Tickets, links, checklists, and mediaProtected attachments, quick-access resources, item checklists, and trip-level memory media.
  • Sharing and collaborationTime-limited share links, reader/editor memberships, visibility synchronization, and role-aware mutation rights.
  • Authentication and browser deliveryVerified access, short-lived API tokens, HttpOnly browser cookies, and a same-origin application proxy.
  • Today and calendar viewsDate-local filtering, calendar export, and focused views of the trip information needed now.
T2

Integrations

  • Maps And DirectionsMap-link providers

    Resolve embedded place context and open locations or transfers in familiar map applications.

    Provider-aware URL parsing and generated map links
  • Weather DataOpen-Meteo weather

    Add current destination context without making weather required for trip planning.

    Coordinate-based current-weather integration with application caching
T3

Capability evidence

  • Product and system ownershipI own the product concept, source, implementation direction, deployment, and review.
  • System architectureI designed the browser, application, API, persistence, media, and provider boundaries.
  • API designI implement versioned trip, timeline, place, media, sharing, and authentication APIs.
  • Frontend deliveryI built the responsive Next.js interface for globe, trip, timeline, Today, media, and editing workflows.
  • Domain modellingI separate trips, places, plans, generated occurrences, resources, and collaboration roles.
  • Transactional workflowsI synchronize a plan and its timeline occurrences inside explicit transaction boundaries.
  • Authentication and authorizationI apply owner, reader, and editor access across data and protected downloads.
  • Systems integrationI integrate map-link interpretation, generated directions, and cached weather context.
  • Relational persistenceI persist related trip, place, timeline, attachment, media, checklist, and sharing state in PostgreSQL.
  • Deployment and operationsI maintain containerized environment definitions and the public beta deployment.
  • Automated testingI maintain backend regression coverage for ownership, sharing, plans, ordering, maps, weather, media, and authentication.