Independent product × product design × AI-assisted build

I wanted a trip planner that worked in the field. So I built one.

Atlas began as a tool for one family trip and became my first production product: a field-oriented travel guide designed around what matters now, what happens next, and the details needed to act.

Role: Product designer · builder · product owner
Stack: Next.js · Supabase · GitHub · Vercel
Build model: AI-assisted development with production testing and iteration

Why this matters

Atlas is the clearest expression of how I increasingly want to work: identify a useful problem, form a product point of view, design the system, build it, put it in front of real use, and keep improving it.

The problem

Most trip-planning apps are built for planning, not for traveling.

Reservations, notes, drives, activities, addresses, and timing spread across apps and documents. Once the trip is moving, the useful question changes: what matters now, and what do I need to do next?

CONFIRMATIONSNOTESMAPSMESSAGES

ATLAS / FIELD LOGOne operational view

01NOW

02NEXT

03ACT

Try the product

This is the real Atlas interface running on safe, fictional data.

Open days, inspect items, and explore the Field Log.

ATLAS / D01FIELD GUIDE

ROAD FILE · 2026

PACIFIC NORTHWEST

SEATTLE → OLYMPIC PENINSULA → PORTLAND

DATESOCT 15 — OCT 19

TRAVELERS2

MODEFLY / DRIVE

STATUSFIELD READY

4 NIGHTS3 STAYS · 2 REGIONS

ITINERARY / PORTFOLIO DEMO

Field log

Confirmed Planned Idea

LOCATION

Olympic Peninsula

OCT 16 — OCT 17

LOCATION

Portland

OCT 18 — OCT 19

This demo uses the production Atlas interface with a separate static dataset. It has no authentication, Supabase connection, or path to the private trip used in the live product.

The operating model

Real use became the design process.

01BUILD

→

02USE

→

03OBSERVE

→

04REFINE

→

05SHIP

Real trip data exposed chronology, location, session, editing, and progression problems that a static prototype never would have revealed.

Product decisions

The interesting work became less about screens and more about rules.

As Atlas matured, the design moved deeper into behavior: what should derive automatically, what deserves an override, how progression works, and where the system should get out of the traveler’s way.

01Make “what’s next” explicit.

Next Up surfaces the next operational event and the details needed to act on it.

02Prefer derived behavior.

Titles, routes, locations, and progression derive from trip data until a human intentionally overrides them.

03Keep the model trustworthy.

Chronology, normalization, conflict handling, and persistence matter as much as visual polish once the software becomes real.

04Reduce trip administration.

The product should help travelers operate the trip, not create another system they have to constantly manage.

What I learned

Building changed the kind of designer I can be.

Atlas forced design decisions all the way through data modeling, persistence, routing, authentication, responsive behavior, deployment, regression testing, and production bugs. It made the distance between “designing software” and “shipping software” feel much smaller.

1real product owned from idea through production

0handoffs between design intent and implementation

∞reasons to keep building things for myself

The goal was a useful trip tool. The bigger outcome was becoming a more capable builder.