Frustration
Every trip lived scattered across a confirmation email, a boarding pass screenshot, a camera roll, and an airline app's delay alert. Nowhere did a flight become a record.
← All work
Book itFly itKeep it
SkyLog
The home of your life in the air.
A booking platform with real commercial logic on one side, and a mobile app that turns every flight taken into a personal aviation history on the other.
Year
2026
Role
Sole builder — product design, commercial model, frontend, backend, mobile app
Status
Live · Shipped
Stack
Next.js · Supabase · Flutter · Duffel API · AirLabs API · Google Places
The gap
Three things converging, not one lightbulb.
Obsession
I genuinely enjoy the record-keeping side of travel — airports, routes, aircraft, distance actually covered. No booking app is built to care about that.
Commercial gap
Duffel offers real inventory with payments built in, and nobody was pairing that booking capability with a genuine diary product on the other side.
Most apps pick a lane — book travel, or log travel. SkyLog's premise is that those are the same story told from two ends.
What I built
Two products. One story.
Departure · The website
Book it
A Duffel-powered booking platform for flights, stays, and rental cars, plus trip management, account tools, and support — all under one clear-pricing commercial model.
- Next.js
- Supabase
- Duffel API
Arrival · The mobile app
Keep it
Home, Flights, Insights, and Profile wrapped around one idea: every flight should become part of a travel story instead of disappearing into an inbox or a camera roll.
- Flutter
- AirLabs API
- Google Places
The journey
Four stages, one record.
- Stage 01
Book
Flights, stays, and rental cars sourced through Duffel, with service margin built into the displayed price rather than added after commitment.
- Stage 02
Capture
Flights arrive from four sources — SkyLog bookings, manual logs, forwarded email confirmations, and boarding-pass scans — and resolve into one vault.
- Stage 03
Approve
Anything SkyLog discovers on the traveler's behalf lands as a pending suggestion. Nothing enters the record without explicit approval.
- Stage 04
Relive
Insights turns the vault into a personal aviation history: route maps, total distance flown, top airports, cabin patterns, and milestones.
Inside the app
The vault and everything around it.
Eight surfaces, all feeding or reading the same travel record.
- 01
Flights
One vault for bookings, manual logs, imports, and scans
- 02
Boarding Passes
Files, barcodes, screenshots, or links — parsed
- 03
Email Sync
Confirmations become suggestions, never entries
- 04
Insights
Route maps, distance, top airports, milestones
- 05
Discover
Destination discovery via Google Places
- 06
Expenses
What a trip actually cost, per flight
- 07
Sky Atlas
The world you've covered, mapped
- 08
SkyLog Pro
Subscription tier for the deeper version
The commercial model
Profit inside the number, not beside it.
Margin flexes by cabin class, by domestic versus international routing, and slightly for nonstop or one-way itineraries — with rates authorized admins can adjust live. The traveler never sees any of that. They see one price.
Earn sustainably on every successful booking while remaining transparent about what the traveler will pay.
What the traveler seesOne price
Base fare
62%
Sourced live through Duffel
Service margin
22%
Flexes by cabin, route, and itinerary
Processing recovery
9%
Card costs absorbed, not passed on late
FX buffer
7%
Currency movement can't erode the margin
Illustrative shares · no surprise fees after commitment
The hardest problem
You can't out-code a support queue.
Ticket IT and FactsDeck were mine to fully control. SkyLog's core booking capability depended on a third party whose responsiveness and access tiers I had no leverage over — so I scoped around what each tier actually allowed, and built everything that didn't depend on Duffel to stand on its own.
- 01
Building on infrastructure I didn't control
Duffel's support queue moved in weeks and months rather than days, and several capabilities SkyLog needed sat behind account tiers requiring a formally registered business — an awkward fit for a deliberately low-commitment solo build. No amount of engineering shortens a vendor's support queue or a verification requirement.
- 02
Four sources of truth, one travel record
A booking, a manual entry, an approved email import, and a captured boarding pass all describe the same flight. Making them resolve into a single record — rather than four near-duplicates — was the core data problem behind the vault.
- 03
Reading boarding passes without retyping
The document vault accepts a file, a barcode scan, a screenshot, or a link, then surfaces route, seat, gate, and boarding group. Every format the traveler already has on their phone had to be a valid way in.
- 04
One product across two codebases
A Next.js and Supabase website and a Flutter app share no framework conventions. Consistency in language, visual identity, and the traveler's journey had to be enforced deliberately, because nothing in either stack does it for you.
Design principles
What kept two products feeling like one.
One connected journey
A booking, a manual log, an approved import, and a captured pass resolve into the same travel record — not four silos.
Traveler control, always
Nothing SkyLog discovers enters a record without explicit approval. Trust was a design constraint, not a legal afterthought.
Fast first, rich later
Logging a flight takes four fields. Photos, notes, ratings, and expenses layer on when the traveler wants them.
One product, two codebases
Next.js and Flutter share no conventions, so shared language and identity had to be enforced deliberately.
Product views
Inside SkyLog
Screenshot slots ready for web and app captures.
- Screen 01Booking flow
Search to checkout with one honest price - Screen 02Flight vault
Merged records from all four sources - Screen 03Insights
Personal aviation history and route map - Screen 04Boarding pass capture
Scan, parse, confirm
Takeaways
What it taught me
Not every dependency is a technical one
Some of the hardest constraints on a solo build are organizational — a support queue, an access tier, a business-verification requirement. The move isn't to fight the constraint; it's to design the rest of the product so it isn't hostage to it.
A commercial model is part of the product
Designing margin logic that is cabin-aware, route-aware, and FX-aware while still resolving into one honest number forced me to think like an owner with a business to sustain, not only an engineer shipping features.
Trust is a feature you design, not a policy you write
"Nothing enters your record without approval" could have been a privacy-policy line. Instead it's a UI state — a pending suggestion waiting for the traveler to act. Travelers feel the interaction, not the terms.