Daytrip

Daytrip is a local-discovery app for the person who already lives here and has run out of ideas for their own city. Not a trip planner for tourists, and not an event finder for a specific night out. I designed it and built it solo, directing AI coding agents, from a few sketches to a running product with a real backend.

Introduction

The idea came after returning from my first solo trip to Portugal. Why can't I make everyday life feel like travel? I wanted a cohesive, done-for-you day trip experience that someone could just pick up, go, and discover their neighbourhood, proving that I could bring an idea from my head to something real.

My role

I worked on everything, with the help of Claude. Strategy, audience, product spec, voice, brand, the visual system, the motion system, the mockups, the component library, the API design, the data model, the launch plan, and the operations tooling.

I decided what gets built, and the strategy to take. Claude helps me find any spots I may have missed, particularly around implementation. Having some front-end background helped me understand the trade-offs better. For example, Claude suggested a live server instead of simpler API functions, which would have added unneeded costs for this app.

V1 in Replit

In late March 2026, during a Replit buildathon, I wrote a build plan and gave it to Replit Agent as the prompt. Within about a week it ran on my phone: a map, trips, stops, and a plan builder.

Then I restarted from scratch because Replit felt like a black box. I couldn't see inside what the agent had made, so I couldn't reason about it or trust it. However the buildathon showed me people liked the pitch. The project drew support from over 30 community members. My takeaway that week: building is quicker than ever, but getting something in front of people is as hard as it was before AI.

## Overview
Daytrip is a hyper-local, community-driven daytrip discovery and planning app. Locals submit, browse, and build itineraries from real neighbourhood stops. The tone is human, low-key, and curious; not touristy.

## Stack (let Replit decide)
Mobile app. use Google Maps.

## Visual Theme
1980s/90s paper map aesthetic
- Base map: custom Google Maps JSON style, desaturated, cream/tan base, reduced POI clutter, warm road tones
- Typography: slab serif or condensed retro font (Arvo, Zilla Slab, Playfair Display)
- Cards: off-white, subtle grain, colored top stripe per daytrip
- Icons: simple retro line-drawn category icons
- Route lines: thick polylines, color-coded per trip

## Data Models
User, Daytrip (stops[], localness_score, saves_count, color, status: pending | approved | rejected), Stop (name, category, coords, notes), Plan (stops[], source_daytrip_id, generated_prompt, synced), Review (rating, localness_rating)

## App Structure
Bottom nav: [ Explore ] [ Plans ] ---- [ + ]
- Explore: map base with browse sheet overlay
- Plans: saved, submitted, and local draft plans
- +: always visible, opens Create Plan

## Explore Tab
- Each approved daytrip = thick color-coded polyline connecting its stops in order
- Tapping a polyline or pin highlights its card in the browse sheet and snaps to it
- Browse sheet peeks ~30% up with a horizontal row of daytrip cards; pull up for the full list
- Card: colored top stripe (matches polyline), title, theme tag, stop count, localness score

## Daytrip Detail (in-sheet)
- Stop-by-stop list: category icon, name, short note
- Crowd localness score, 1-5, "Tourist spot" to "Hidden gem"
- "I tried this" leaves a rating + localness score
- "Build a plan with this" clones the stops into a new plan draft

## Create Plan
[ Edit manually ] [ Generate ]
- Manual: drag to reorder, swap, delete, add note; free-form, no enforced template
- Generate (subscription): prompt field with starters like "a slow rainy afternoon"; pulls from submitted stops only; result is an editable stop list
- [ Save locally ] [ Save & Submit ]

## Submit a Daytrip
Name it, pick a theme tag, add stops with a short note each, self-tag a vibe. Goes pending, then live on the Explore map after admin approval. First submission unlocks 1 free week of premium.

## Auth Gate
Contextual, not aggressive. Inline "Sign in to save". Full-screen flow only on Submit or Generate.

## Local Draft Sync
Not logged in: saved to localStorage. Log in later: drafts sync to Supabase. Never signs up: draft stays on device.

## Monetization
Browse: always free. Save, review: login. Submit: login + 1 free week. AI plan generation: $7/mo or $49/yr.

## Build Order
1 Supabase schema, 2 seed data (5-10 Vancouver daytrips), 3 Google Maps base, 4 Explore tab, 5 Daytrip Detail, 6 Auth, 7 Create Plan, 8 Submit flow, 9 Plans tab, 10 AI Generate, 11 Stripe, 12 Admin route

Decisions

An added benefit of building with Claude is that I kept a running log of every decision, built into the spec documents, code comments, and commit history. Here's a sample of decisions I found noteworthy.

• Anti-personas before screens. NOT for the tourist, the event-only seeker.
• Deciding on vibe. From tags to [mood + scene] to [energy + scope + social]. Cutting stamps as filter controls.
• 1990s kiosk design language, expressed structurally, physical compass, two-tier map markers, two motion registers that never mix, not just in colour.
• Sketch to screen with a paper trail: hand sketch, ASCII wireframe, HTML mockup, Penpot (I regretted this), component library, logged at every stage.

Outcome

I learned a lot of what it takes to bring an app to life. It showed me that when I fully own an idea I'm excited about, the words come easily - something I struggle with when an idea isn't genuinely interesting to me.

Despite not using its outputs, trying an AI building tool helped me get a sense of how an app should be structured. Intentionally asking it to teach me while it builds helped me broaden my understanding. In the end, the design is still owned by me as the creator of this app.