Travel Vient Blog

75 Destinations Ranked by Daily Budget: 2026 Data

cadendeveloper@gmail.com (Travel Vient) — Wed, 13 May 2026 00:00:00 GMT

I started planning a beach trip this summer. Pulled up the destination data on my site to compare options. Maui was sitting at $170 a day. Cancun was $45. Cartagena was $40. The number that caught me was not the cheapest, it was the gap. A week in Maui at the budget tier runs as much as four weeks in Cartagena. Same beach archetype, four times the spend.

That sent me down the ranking. 75 destinations, sorted by daily budget cost in 2026. The cheapest is 12% of the most expensive.

How I built the dataset

The site has structured JSON files for 75 destinations at travelvient.com. Each file includes a typicalCosts object with three tiers: budgetPerDayUsd, midrangePerDayUsd, and luxuryPerDayUsd. The budget tier is what most cost-of-travel guides quote. It assumes a single traveler staying in hostels or budget guesthouses, eating local food, using public transit, and doing free or cheap activities.

For each destination I read the budget field, sorted ascending, and grouped by continent. The data was last updated between April 23 and May 4, 2026. Full CSV: 75-destinations-daily-cost-ranking-2026.csv.

A few things this number does NOT capture, and they matter more than the ranking:

No airfare. The biggest fixed cost of any trip is not in this dataset.
Season variance. Maui in April is not Maui in December. The number is a year-round midpoint, not a peak or shoulder season quote.
Single-traveler baseline. Couples and families do not scale linearly per person. A $90 hotel room is $45 per person when split, but a $40 hostel bunk is still $40.
Exchange-rate snapshot. These numbers shift quarterly with currency moves, especially in Argentina, Turkey, and Japan.
Hostel-friendly assumption. Cities where the budget tier assumes a hostel ($25 Bangkok) compare unfairly with cities where the budget tier assumes a 2-star hotel because no hostel scene exists ($110 Charleston).

If your trip style does not match the budget-tier assumption, your daily spend will be higher. Most travelers’ actual spending sits closer to the midrange tier, which has a median of $160 per day across the same 75 cities.

The full ranking

Bar width shows daily budget in USD. Color shows continent.

AsiaAfricaSouth AmericaEuropeMiddle EastOceaniaNorth America

Ho Chi Minh City$20

Chiang Mai$25

Hanoi$25

Bangkok$30

Oaxaca$30

Marrakech$35

Medellin$35

Cairo$40

Cartagena$40

Krakow$40

Mexico City$40

Tbilisi$40

Bali$45

Buenos Aires$45

Cancun$45

Cozumel$48

Istanbul$50

Lima$50

Nassau$50

Prague$50

Athens$55

Budapest$55

Costa Rica$55

Osaka$55

Seoul$55

Vancouver$55

Berlin$60

Kyoto$60

Porto$60

Cabo San Lucas$65

Hong Kong$65

Taipei$65

Dubai$70

London$70

Portland$70

Edinburgh$75

Lisbon$75

Rome$75

Singapore$75

Sydney$75

Tokyo$75

Washington$75

Barcelona$80

Cape Town$80

Copenhagen$80

Denver$80

Florence$80

Madrid$80

San Juan$80

Santorini$80

Boston$85

Dublin$85

New Orleans$85

Orlando$85

Austin$90

Dubrovnik$90

Paris$90

Vienna$90

Amsterdam$95

Nashville$95

Seattle$95

Venice$95

Chicago$100

Las Vegas$100

San Diego$100

St. Thomas$100

Charleston$110

Los Angeles$110

Miami$110

New York City$120

Reykjavik$120

Grand Cayman$125

Honolulu$130

San Francisco$130

Maui$170

The cheap end is geographically narrow

The 10 cheapest destinations are all in three regions: Southeast Asia (Ho Chi Minh City, Chiang Mai, Hanoi, Bangkok), Latin America (Oaxaca, Medellin, Cartagena, Mexico City), and one North African and Eastern European entry (Marrakech and Krakow). That is the entire bottom of the chart. Not Western Europe, not the Caribbean, not North America outside Mexico, not Oceania.

Ho Chi Minh City sits at $20 per day. Maui sits at $170. The ratio is 8.5x. A traveler doing a budget-tier 14-night trip would spend $280 in Ho Chi Minh City and $2,380 in Maui, before flights.

The Southeast Asian numbers are also striking because they cluster so tightly. Five Vietnamese and Thai cities span $20 to $30 a day. That is the same range you would pay for a single sit-down dinner in Reykjavik.

US cities pile up at the top

Of 19 US destinations in the dataset, 18 sit above the global median of $85 per day. The single exception is Portland at $70, which is still above 60% of the global ranking. Washington DC at $75 is the only other US city under $80.

Hawaii is the outlier even by US standards. Maui at $170 and Honolulu at $130 both clear San Francisco ($130) and New York City ($120). For most of the US ranking the pattern is: smaller-market mainland cities ($70 to $95), mid-tier coastal cities ($100 to $110), and the truly expensive few ($120 to $170). Hawaii dominates the top.

The Caribbean entries break similarly. Grand Cayman ($125), St. Thomas ($100), Nassau ($50), San Juan ($80). The spread inside a single region of beach destinations is 2.5x.

Europe splits east versus north

Europe’s 24 destinations range from Krakow at $40 to Reykjavik at $120. The cheapest 6 are all Eastern or Southern European: Krakow ($40), Tbilisi ($40), Istanbul ($50), Prague ($50), Athens ($55), Budapest ($55). The most expensive 4 are all Northern: Copenhagen ($80), Amsterdam ($95), Reykjavik ($120), and Paris ($90) for the Western anchor.

For a European trip, the daily-cost arithmetic alone says go east. Krakow at $40 is one-third the cost of Reykjavik at $120, in a continent where flight differences between the two are often under $100.

The honest counterpoint

The daily-cost number is the easiest metric to publish and the worst metric to plan a trip with. The reason is fixed costs.

I am sitting here looking at a beach trip from the US this summer. Maui at $170 a day looks brutal. Ho Chi Minh City at $20 a day looks like paradise on the spreadsheet. The math at one week:

Maui, 7 nights at budget tier: $1,190. Round-trip flights from the US West Coast for two people: roughly $1,000 to $1,400. Total: ~$2,400.
Ho Chi Minh City, 7 nights at budget tier: $140. Round-trip flights from the US West Coast for two people: roughly $2,800 to $3,800. Total: ~$3,200, plus visas and time.

For a week, the cheap destination is not cheaper. The flight is the trip’s largest line item, and a 22-hour journey each way burns a day of the trip on either side. The Maui math gets ugly. The Ho Chi Minh City math is worse.

Now run it at three weeks. The flight cost holds flat. The daily cost compounds. Three weeks in Maui hits $3,570 plus flights. Three weeks in Ho Chi Minh City hits $420 plus the same fixed cost. Now Southeast Asia is half the trip cost.

This is the trap of the daily-budget metric. It looks like a comparison and it is actually a function of trip length. Anyone publishing a $/day number and not stating the assumed trip length is selling you on a number that flips depending on your itinerary.

If you live in the US and you want a beach trip in summer, the daily-cost ranking is misleading. You are not choosing between Maui and Hanoi at the same trip length. You are choosing between a 6-hour flight to a $170-a-day destination and a 22-hour flight to a $20-a-day destination, and the only way the second option wins is if you stay long enough for the daily savings to absorb both the flight cost and the lost vacation days at each end. For most US travelers with two weeks of PTO, Hawaii wins on math.

What I actually do now

When I look at the destination chart, I read three numbers, not one. The daily cost. The likely round-trip flight from where I live. And the trip length I can realistically take.

For a 7-day trip from the US, the cheap-daily destinations rarely beat the expensive-daily destinations once flights are in. The exception is a deep value where the daily number is so low that even short trips justify the airfare (Cancun, Cartagena, Mexico City from most of the US).

For 14-day trips, the math becomes a coin flip and personal preference dominates.

For 21-day-plus trips, the cheap-daily destinations dominate. This is why long-term travelers and digital nomads cluster in Chiang Mai and Medellin and Bali. The fixed cost is fully amortized and the daily savings stack.

If you want to compare specific cities, I keep the full guide set at /destinations/. The destination page for each city shows the budget, midrange, and luxury tiers side by side, plus the season-by-season crowd and weather data. Useful for the daily picture. Not a substitute for pricing your actual flights.

What I’d want to analyze next

The data essay that would actually answer the question I am asking: a flight-included total cost ranking. Three columns: 7-day total from a major US hub, 14-day total, 21-day total. The ranking would shuffle dramatically. Hawaii would dominate short trips. Southeast Asia would only show up at three weeks. Eastern Europe would probably win the middle.

That requires real flight pricing data and a defensible US-hub assumption, which I have not built yet. It is the next post in this series if I can find a clean public source.

For now: the daily number tells you what a day on the ground costs. It does not tell you what the trip costs. Both numbers matter. Most cost-of-travel writing only quotes one of them.

I'm Only Building Dead Simple Apps From Now On

cadendeveloper@gmail.com (Travel Vient) — Thu, 07 May 2026 00:00:00 GMT

I opened Bloons TD the other day to play a quick round.

The screen was wall to wall buttons. A daily challenge banner. A season pass popup. A currency reward I had to claim. A new event I had to dismiss. Then another modal selling me an upgrade pack. By the time I was looking at the actual map, I had tapped six things I did not want to tap.

I closed the app without playing.

It is a tower defense game. I wanted to place towers and pop bloons. That used to be the whole loop. Now the loop is wrapped in five other loops, and the original one is somewhere down inside, waiting for me to dig it up.

This is not a Bloons problem. This is every app I open.

The job to be done is three taps deep

Pick any app on your phone right now. Open it. Count how many things appear before you can do the thing you opened the app to do.

Banking app: a promo carousel about a new credit card before the balance. Streaming app: three rows of recommendations before search. Food delivery: a wall of paid placement before the restaurants you usually order from. Social app: a story tray, a creator subscription pitch, an explore feed, a “see what your friends are up to” prompt.

The actual product is buried. The shell around it has eaten the product.

I do not think the people who built these apps are bad at their jobs. I think the framing has rotted out from under them. Engagement is the metric, not job-completed. So every quarter another team gets staffed, another OKR gets set, another ribbon of UI gets added on top. Nobody is paid to remove anything. The apps grow rings like trees.

What I am going to do about it on my end

I cannot fix Bloons TD. I can fix what I ship.

From now on, every app I build does exactly one thing. No accounts. No settings screens. No in-app upsells. No notifications. No “while you’re here, why don’t you also.” If a feature does not make the core thing better, it does not ship. If the second feature is not strictly necessary, the app stays a one-feature app.

I already have one of these in the App Store and I like the way it feels.

Mic to Clipboard is my dead simple iOS app. One screen. One button. You tap it, you talk, and your words land in your clipboard. Paste them anywhere. There are no settings. There is no account. There is no history view. There is no premium tier. The whole app is the thing it does.

I built it because Claude Code on Bedrock does not expose microphone access and I was tired of typing every prompt by hand. So the app fixes exactly that one friction point. Nothing else. When I open it I am in for two seconds and out, which is exactly what I want from it.

The next thing I am building is a local events app. Same philosophy. You open it, you see what is happening near you tonight, you close it. No social feed. No RSVPs. No friend system. No “create an account to save events.” If you want to go, screenshot it or write it down. The app’s job is to tell you what is on tonight, not to become a daily habit.

Why one feature is a feature

There is a real argument here, not just a vibe.

It ships faster. A one-feature app is one or two weekends of work. A ten-feature app is a year of work, half of which is plumbing between features, navigation between screens, settings to control feature interaction, and edge cases where feature A breaks feature B.

Users understand it instantly. When the app does one thing, the user has nothing to learn. They open it, they see the thing, they do the thing. There is no onboarding because there is nothing to onboard them into.

The bug surface is small. Every feature is a place a bug can live. One feature, one place. Less code to maintain, less to break when iOS updates, less for me to forget how it works six months later.

Constraints are a feature. When I tell myself the app is only allowed to do one thing, I have to make that one thing really good. If I let myself add a settings screen, I would spend a week tuning the settings screen instead of making the core flow shorter. Forbidding the escape valves forces the work into the part that matters.

This is not anti-feature

I want to be clear about what I am not saying. I am not saying apps should never grow. I am not saying every app should be a single button with no settings.

I am saying: add the second feature when the first one stops being enough, not because the roadmap says Q3. Add the settings screen when users are actively asking for a setting, not before. Add the account system when there is a real cross-device need, not because the team’s OKR is “increase signed-in users.”

Most “features” do not exist because anyone needed them. They exist because somebody had to ship something this quarter and that was the cheapest thing to attach. Then it gets attached. Then it gets defended in the next quarter’s review because killing it would be admitting it was unnecessary. Then the app feels like Bloons TD.

The bar I am holding myself to

If a feature does not make the core thing better, it does not ship.

If the app cannot be explained in one sentence, the scope is wrong.

If the user has to read instructions, the design is wrong.

If I am tempted to add a settings screen, I should be tightening the defaults instead.

If I am tempted to add an account, I should be making the offline experience better instead.

If you have felt the same fatigue lately, opening apps that used to be useful and now feel like a department store, you are not imagining it. The apps actually did get worse. The good news is some of us are going the other way.

That is what I am building toward. Apps you open, use, and close. Apps that respect that you have something else to do today. Apps where the entire app is the thing it does, and there is nothing else in the way.

Related: see side projects.

How to Book Connecting Flights Without Ruining Your Trip

cadendeveloper@gmail.com (Travel Vient) — Tue, 05 May 2026 00:00:00 GMT

I missed a connection in Dallas once because I booked a 55-minute layover on a ticket that required me to switch terminals, re-clear security, and sprint past 47 gates. The fare was $80 cheaper than the two-hour option. I spent that $80 and then some on a last-minute rebooking, a sad airport sandwich, and a hotel I didn’t plan on needing.

That was the trip that made me stop guessing at layover times. Now I check before I book. This calculator factors in terminal layouts, customs buffers, and TSA rescreen times for 70 airports:

Pick the airport you’re connecting through and it’ll tell you exactly how much time you need, broken down by scenario. I check this every time before I book a multi-leg itinerary now. Here’s why it matters.

The myth of minimum connection time

Every airport publishes a minimum connection time (MCT), which is the shortest legal gap the airline will sell you on a connecting itinerary. What they don’t tell you is that “minimum” means “theoretically possible if everything goes perfectly.” Your inbound flight lands on time. You’re seated in row 3. The gates happen to be next to each other. Nobody in front of you takes nine minutes to find their bag in the overhead bin.

In reality, a 20-minute delay on your first leg eats the entire buffer. And delays aren’t rare. They’re the norm.

Here’s my rule: for domestic connections, book at least 30 minutes over the MCT. For international connections where you need to clear customs and re-check bags, book at least 60 minutes over it. If you’re connecting through a mega-hub like Atlanta, Dallas/Fort Worth, or Denver during peak hours, add another 15 on top of that.

The tricky part is that MCTs vary wildly by airport, by terminal combination, and by whether you’re connecting domestic-to-domestic versus international-to-domestic. Atlanta’s MCT for a domestic connection is about 30 minutes if you stay in the same concourse. But if you’re arriving international and connecting domestic, you need to clear customs, re-check your bag, go through TSA again, and take the train to a different concourse. That’s a completely different number.

The 3-hour sweet spot

For most domestic connections, I aim for a 2 to 3 hour window. Short enough that you’re not wasting half your day in an airport. Long enough that a typical 30-minute delay doesn’t matter. You can grab food, stretch your legs, and still get to your gate early.

For international connections, especially through airports like London Heathrow or Tokyo Narita where you might need to change terminals via a bus or train, I won’t book anything under 3 hours. Four is better. I’ve been burned too many times.

If you’re traveling with kids, add an hour to whatever number you’d book for yourself. Kids don’t sprint through terminals. They stop to look at things. They need bathrooms at the worst possible time.

The carry-on problem nobody talks about

Here’s the other thing that can wreck a connection: getting your carry-on gate-checked on leg one and having to wait at baggage claim to retrieve it before your next flight.

This happens more than people realize, and it’s almost always because the bag is technically over the airline’s size limit. Most travelers assume carry-on sizes are universal. They’re not. A bag that fits perfectly in the overhead on a United 737 might be oversized for the regional jet operating your first leg on American Eagle.

Even on the same airline, carry-on allowances can differ between mainline and regional flights. Some airlines have strict weight limits (looking at you, most European carriers). Some charge for carry-ons entirely if you’re on a basic economy fare.

Before I fly, I always double-check the actual carry-on dimensions and personal item limits for my specific airline. Here’s a quick way to do that:

The weight limits are the sneaky ones. Ryanair’s 10 kg carry-on limit has caught more first-time European travelers off guard than any other rule in aviation. And if your bag is over at the gate, you’re paying the oversized fee on the spot, which is always more expensive than prepaying online.

My pre-booking checklist

After enough bad layovers, I now run through these five things before I click “purchase” on any connecting itinerary:

Look up the MCT for the connecting airport. Not the airline’s generic recommendation. The actual terminal-specific minimum.
Add my buffer. 30 minutes domestic, 60 minutes international, more for mega-hubs.
Check the aircraft type for each leg. If leg one is a regional jet, your overhead space is smaller. Plan for it.
Verify carry-on limits for each airline. If the itinerary is on two different carriers (common with codeshares), check both. Your bag needs to comply with whichever airline is operating the flight.
Check the terminal map. Some airports (looking at you, JFK) have terminals that require you to exit security and re-enter. That eats 30+ minutes even if the airline says the MCT is shorter.

The overnight layover trick

If you’re flexible and the fare difference is significant, an overnight layover can actually be a feature, not a problem. I’ve had some of my best travel memories from unplanned overnight stops.

A 14-hour layover in Reykjavik let me see the Northern Lights. An overnight in Lisbon gave me an evening of incredible food I wouldn’t have experienced otherwise. Some airports even offer free or subsidized city tours for transit passengers (Singapore Changi, Istanbul, and Doha all have programs like this).

The key is knowing it’s coming and planning for it. Don’t check your bag through to the final destination if you want to leave the airport. Pack a change of clothes and your essentials in your carry-on. And make sure you don’t need a transit visa for the country you’re stopping in.

The real cost of a cheap layover

That $80 I saved on the Dallas connection ended up costing me around $340 when I added the rebooking fee, the hotel, the meals, and the Uber. And I lost an entire evening I was supposed to spend with family.

The math almost never works in favor of the tight connection. Book the extra time. Check your carry-on dimensions before you leave for the airport, not at the gate. And treat the layover as part of the trip, not an obstacle between you and the destination.

Your future self, the one standing calmly at the gate with 45 minutes to spare, will thank you.

15 Countries Where Your US Plug Fits but the Voltage Doesn't

cadendeveloper@gmail.com (Travel Vient) — Mon, 04 May 2026 00:00:00 GMT

Your US-shaped plug fits the wall in 15 countries that deliver double the voltage your device was built for. Phone chargers and laptops switched to dual voltage years ago. Hair dryers, curling irons, electric razors, and small kitchen appliances mostly did not.

Thailand, Vietnam, the Philippines, Cambodia, Laos, Myanmar, China, Peru, Bolivia, Paraguay, Bangladesh, Antigua and Barbuda, Guyana, Saint Kitts and Nevis, and Saint Vincent and the Grenadines. All 15 accept Type A or Type B sockets (the flat US shape) but run a 230V to 240V grid. The data comes from a 221-country plug-and-voltage table cross-checked against IEC standards.
The plug fit is not the question. The voltage is. A 110V US hair dryer plugged into a 230V Bangkok outlet draws four times its rated wattage. The heating element fails, the fuse blows, or the housing melts. Some pop on the first second.
Phone and laptop chargers are mostly safe. Look at the small print on the brick. If it reads 100-240V, you are fine anywhere on the list. If it reads 120V only, treat it like a hair tool and leave it home.
Single-voltage hair tools are the most common casualty. A US-bought curling iron rated 120V draws 1500W in Hanoi, Manila, or Phnom Penh and will burn out before it warms up. Travel-specific dual-voltage hair tools exist. The drugstore version on your bathroom counter does not.
A travel adapter does not change voltage. It only changes plug shape. Running a 110V device on a 230V grid takes a step-down transformer, which is heavy and rarely worth it. For most travelers the answer is leaving the device at home.

Check the input range printed on the charger before you pack it.

I Checked 21 Airline Pet Fees. The Spread Is $74 to $300.

cadendeveloper@gmail.com (Travel Vient) — Mon, 04 May 2026 00:00:00 GMT

Editor’s note (May 2026): This data essay was published before Spirit Airlines ceased operations on May 2, 2026 (Chapter 7 liquidation). Spirit’s pet fee below reflects its policy while it operated and is kept as a historical snapshot; Spirit is no longer bookable.

The same 15-pound dog in the same under-seat carrier costs $74 round-trip on one airline and $300 on another.

Most pet owners book flights by schedule and price, then discover the pet fee at checkout. The fee varies 4x depending on the carrier, and nothing about the service changes between the cheapest and most expensive.

WestJet charges $37 one-way. That is $74 round-trip for the exact same under-seat pet carrier every airline requires. Allegiant is $50 one-way ($100 round-trip). Both are lower than Delta’s $95 one-way, which most travelers assume is standard.
The middle tier clusters around $100-$125. Delta charges $95, Alaska $100, Southwest $125, JetBlue $125. Spirit also charges $125, which means Spirit’s pet fee matches Southwest’s despite Spirit being the “budget” option.
American and United both charge $150 one-way. That is $300 round-trip. For two pets on a family trip, that is $600 in pet fees alone on a single domestic round-trip.
Nine airlines charge under $100 one-way. WestJet, Allegiant, Eurowings, Gol, Breeze, Sun Country, Air Canada, Delta, and Frontier. The cheapest five are all under $75.

The airline with the lowest base fare is not the cheapest airline to fly with a pet.

Building a Travel Power Adapter Tool with Claude in a Weekend

cadendeveloper@gmail.com (Travel Vient) — Sun, 03 May 2026 00:00:00 GMT

I travel a lot. And every single time, I’m standing in an airport Googling “do I need an adapter for Thailand” while my boarding group is already lining up. The existing tools for this are bad. They’re buried in blog posts from 2016 with popup ads, or they’re a wall of text that doesn’t actually answer the question.

I already had most of the data. My destination guides on Travel Vient cover dozens of countries, and each one tracks the local plug type and voltage. The pieces were sitting there. I just needed to turn them into something interactive.

What it does

You pick where you’re from and where you’re going. It tells you: do you need an adapter, do you need a voltage converter, or do you need nothing. It covers 221 countries, all 15 plug types (A through O), and links you to the right adapter on Amazon if you need one.

There’s a collapsible section with plug diagrams, a voltage comparison, and a converter guide. A table of popular routes (US to UK, US to France, etc.) with pre-computed answers. FAQs for the common questions. And the whole thing also works as an embeddable widget other travel sites can iframe in.

How I worked with Claude on this one

This was almost entirely Claude Code agentic runs. I described what I wanted, pointed it at my existing destination data, and let it build. My role was more like a product manager reviewing output than a developer writing code. I’d describe the feature, Claude would ship a complete implementation, I’d review it, and then tell it what to fix.

The initial build took one agentic run. The restyle took another. The whole thing was done in two sessions over two days.

The stack

Astro static page with all logic running client-side in a single <script> block. No framework, no React, no build step beyond what Astro already does. The country data and plug type info get serialized into JSON script tags at build time, then the client-side JS reads them and renders results.

I considered making this a separate app like PackSmart, but it didn’t need a backend. Every possible result is just a comparison between two objects in a JSON array. No API calls, no server, no loading states.

export function getAdapterVerdict(origin: CountryElectrical, destination: CountryElectrical): AdapterVerdict {
  const originPlugs = new Set(origin.plugTypes);
  const shared = destination.plugTypes.filter((p) => originPlugs.has(p));
  const missing = destination.plugTypes.filter((p) => !originPlugs.has(p));
  const needsAdapter = shared.length === 0;
  const voltageMatch = Math.abs(origin.voltage - destination.voltage) <= 20;
  const needsConverter = !voltageMatch;

  const freqOrigin = Array.isArray(origin.frequency) ? origin.frequency : [origin.frequency];
  const freqDest = Array.isArray(destination.frequency) ? destination.frequency : [destination.frequency];
  const frequencyMatch = freqOrigin.some((f) => freqDest.includes(f));

  return { needsAdapter, needsConverter, sharedPlugTypes: shared, missingPlugTypes: missing, voltageMatch, frequencyMatch };
}

That’s the core logic. If none of your home country’s plug types exist in the destination’s list, you need an adapter. If the voltage difference is more than 20V, you need a converter. Simple, but it handles the edge cases: countries with multiple plug types, dual-voltage regions, frequency mismatches.

The hard part

Information hierarchy. The tool needs to answer one question fast: “do I need to buy something before my trip?” But it also needs to handle the follow-up questions: “what type?” and “what about my hair dryer?”

Claude’s first implementation threw everything at the user at once. Plug diagrams, voltage charts, converter guides, notes about regional voltage variations. It was technically complete and practically unusable. Nobody landing on this page from Google wants to parse a wall of technical data. They want a yes/no verdict with a link to buy the thing.

The fix was progressive disclosure. The verdict sits at the top in a bold banner. The Amazon link is right below it. Everything else collapses behind a details element:

<details id="pf-details" class="pf-details mt-3">
  <summary class="pf-details-summary">
    <span>Voltage details, plug picture, and converter guide</span>
  </summary>
  <div class="pf-details-body">
    <!-- Plug type cards, voltage comparison, converter advice -->
  </div>
</details>

Simple pattern, but it took two full restyle passes to get there because Claude kept defaulting to “show everything.”

Where Claude surprised me

The data layer. Claude compiled a 221-country JSON dataset with plug types, voltages, frequencies, and edge-case notes in a single pass. Countries like Brazil where voltage varies by region, Cambodia where five different plug types are in use, Bangladesh where Type D and G are most common despite officially supporting five types.

{"name": "Brazil", "iso": "BR", "plugTypes": ["C", "N"], "voltage": 127, "frequency": 60, "notes": "Voltage varies by region: 127V in most of the southeast (Sao Paulo, Rio) and 220V in the south (Brasilia, Florianopolis) and northeast (Recife, Salvador). Always check before plugging in."}

I spot-checked a bunch of these against IEC standards and travel forums. They were accurate. Claude also generated all 15 plug type SVGs inline, each with the correct pin layout, grounding, and shape. No external image files needed. That saved me from sourcing or licensing illustrations.

Where Claude fell short

The initial UI was a disaster. Claude built something that was technically functional but impossible to actually use. The country selectors were basic dropdowns with no search. The results showed every data point at once with no hierarchy. There was no visual distinction between “you need nothing” and “you need a specific adapter.”

I had to run a complete restyle. The first attempt at the restyle was still too busy. I ended up having to be very specific about what I wanted: a horizontal picker row with flag emojis, a single bold verdict line, a dark CTA button, and everything else hidden behind a collapsible. Claude needed that level of direction to produce something clean.

The country picker alone went through multiple iterations:

function initPicker(root: HTMLElement, onSelect: (iso: string, name: string) => void) {
  const trigger = root.querySelector('.pf-picker-trigger') as HTMLButtonElement;
  const panel = root.querySelector('.pf-picker-panel') as HTMLElement;
  const search = root.querySelector('.pf-picker-search') as HTMLInputElement;
  // ...keyboard nav, filtering, popular chips, scroll-into-view
  return { setTriggerDisplay, selectIso };
}

This picker has search, keyboard navigation, popular country chips, and proper ARIA. None of that existed in the first version. Claude could build each individual piece when asked, but it couldn’t intuit what the right UX shape was from a high-level description.

What went wrong overall

Scope was actually fine here. The real problem was making two things at once: a standalone tool page and an embeddable widget. The widget version needs to work in an iframe at arbitrary widths, with theme detection, without any of the page chrome. That doubled the surface area for styling bugs.

I also launched it hidden behind a sitemap exclusion initially, which means I didn’t get real feedback on the UX until I enabled it on the tools page. If I’d shown it to someone earlier, I might have caught the information-overload problem faster.

Where it is now

Live at /tools/plug-finder. Indexed, included in the tools listing, has an embeddable widget version for outreach. The affiliate links are working. It handles URL parameters (?from=US&to=GB) so you can deep-link to specific routes.

What I would do differently

Start with a wireframe. Not a pixel-perfect mockup, just a rough sketch of the information hierarchy: what does the user see first, what’s hidden, what’s the action. Claude is great at building whatever you describe, but it defaults to “show all the data” when you don’t constrain the layout upfront. A 30-second sketch on paper would have saved me the entire restyle pass.

I’d also be more explicit about the “nothing needed” state. That’s actually the most satisfying result for the user, and it deserves its own distinct treatment. Claude’s first version treated it as just another line of text. Now it gets a big “Nothing.” headline. Small thing, but it’s the difference between a tool that feels good to use and one that just dumps information.

I tested the 'avoid August' rule against 67 destinations

cadendeveloper@gmail.com (Travel Vient) — Thu, 30 Apr 2026 00:00:00 GMT

We went to Hawaii in September. Not early September, not “end of summer” September. Properly into the month. Locals at a trailhead on Oahu mentioned how packed it had been the week before, how the parking lots had overflowed all through August, how we had just missed the chaos. We hiked Diamond Head with maybe fifteen other people. The North Shore beaches were empty enough to sit wherever we wanted. One week earlier, apparently, you could not find a parking spot.

That timing stuck with me. The difference between August and September at the same destination was the difference between fighting for space and having it to yourself. And it got me wondering: is August actually the universal worst-case for every destination, or is that mostly a European and North American story?

So I tested it. 67 destinations. One question per city: what is the crowd level in August?

22 of 23 European cities hit peak crowd. But 16 destinations globally, nearly a quarter of the dataset, sit at low crowd in August.

How I tested this

I maintain structured JSON files for 67 destinations at travelvient.com. Each file includes a seasons array with crowdLevel classifications (peak, high, moderate, low) broken out by month range, plus a bestTimeToVisit.avoidPeriod field where the data explicitly warns against certain months.

For each destination, I found the season entry whose month range includes August and read its crowdLevel value. I also checked whether August appeared in the avoidPeriod string.

The data was last updated between April 23 and April 29, 2026. Four destinations (Bali, Cartagena, Dubai, Lima) lacked August crowd data and are excluded from the crowd-level counts but included in the chart with “n/a” markers.

The full dataset is downloadable as a CSV: 67-destinations-august-crowd-test-2026.csv.

Two things this test does NOT do. It does not measure crowd levels with sensors or ticket-gate counts. These are editorial classifications based on tourism board data, occupancy patterns, and published travel guides. Different sources would draw the lines differently. And it classifies at the city level, not the country level. A city being “peak” does not mean the entire country is packed. Rural Provence in August is a different experience from Paris.

The chart

Bar width shows the August high temperature in Fahrenheit (scaled to 109°F, Cairo’s high). Color shows crowd level: red = peak/high, amber = moderate, green = low.

Peak / HighModerateLow

Europe (23)

Amsterdam72°F

Athens93°F

Barcelona84°F

Berlin77°F

Budapest90°F

Copenhagen72°F

Dublin68°F

Dubrovnik93°F

Edinburgh68°F

Florence95°F

Istanbul84°F

Krakow86°F

Lisbon84°F

London76°F

Paris79°F

Porto82°F

Prague76°F

Reykjavik59°F

Rome89°F

Santorini90°F

Tbilisi87°F

Vienna86°F

Madrid97°F

Every single bar is red. Madrid is the closest thing to an exception, classified as “high” rather than “peak” because the 97°F heat drives tourists toward coastal Spain. But high is not moderate. Europe in August is wall-to-wall.

North America (24)

Boston82°F

Chicago92°F

Denver93°F

Los Angeles85°F

Nashville95°F

New York City89°F

Orlando92°F

Portland82°F

San Diego77°F

San Francisco67°F

Seattle79°F

Honolulu87°F

Las Vegas106°F

Maui88°F

Washington, DC90°F

Austin98°F

Cabo San Lucas95°F

Charleston91°F

Cancun93°F

Costa Rica90°F

Mexico City77°F

Miami92°F

New Orleans95°F

Oaxaca85°F

North America is more interesting. The US cities you associate with summer, from New York to Seattle to Hawaii, are all peak or high. But scroll down to the green bars. Cancun is low-crowd in August (hurricane season scares people off). Mexico City at 77°F and low crowd is one of the best-value entries in the entire dataset. Miami and New Orleans are low-crowd because the heat and humidity are brutal, and the locals know it.

Asia (11)

Osaka93°F

Hong Kong93°F

Kyoto95°F

Singapore91°F

Tokyo89°F

Bangkok93°F

Chiang Mai90°F

Ho Chi Minh City93°F

Seoul86°F

Taipei95°F

Balin/a

Zero peak-crowd cities. Only Osaka hits peak. The Japanese cities (Kyoto, Tokyo) are moderate because the Obon holiday in mid-August brings domestic travel, but international tourist volume is lower than spring cherry blossom season. Southeast Asia is almost entirely low-crowd in August: it is monsoon season across Thailand, Vietnam, and Taiwan, which drops prices and thins crowds even though the rain is usually a short afternoon burst rather than an all-day washout.

Seoul at 86°F and low crowd is a standout. The city has excellent transit, the food scene does not slow down in summer, and August sits between the spring and autumn tourist waves.

Africa (3)

Cairo109°F

Cape Town63°F

Marrakech108°F

All three African cities are low-crowd. All three green. But look at the bar widths. Cairo hits 109°F and Marrakech 108°F. These are not hidden gems. They are empty because the heat is dangerous. Cape Town is a different story: it is winter in the Southern Hemisphere, 63°F, and genuinely pleasant for hiking and wine country if you pack layers.

South America (4)

Medellin78°F

Buenos Aires64°F

Cartagenan/a

Liman/a

Buenos Aires in August is winter. Highs around 64°F, low crowds, and steak dinner prices that look like a rounding error compared to Paris. The city does not shut down in winter; the theater and restaurant scene stays active.

Oceania (1) & Middle East (1)

Sydney63°F

Dubain/a

Sydney in August is mid-winter, 63°F, low crowd. The Opera House, the harbor walks, and the Blue Mountains are all open. You will want a coat.

The findings, ranked

The rule is right in Europe. 22 of 23 cities hit peak. 14 of those 23 explicitly list August in their avoid period. This is not a nuanced finding. If you are going to Europe in August, you are going at the most crowded, most expensive time.

The rule breaks down outside Europe and the US. Asia has zero peak-crowd cities in August. Africa has zero. South America has zero (Medellin is “high” but not peak). The “avoid August” advice is really “avoid August in the Northern Hemisphere’s wealthy tourist corridors.”

The Southern Hemisphere flips the script. Cape Town, Sydney, and Buenos Aires are all in winter during August. Low crowds, lower prices, and weather that ranges from brisk to mild. This is the most reliable August contrarian play in the dataset.

Some low-crowd cities are low for a reason. Cairo at 109°F and Marrakech at 108°F are not invitations. They are warnings. Miami at 92°F with peak humidity is technically low-crowd, but if you have spent an August afternoon in South Florida, you understand the tradeoff. “Low crowd” and “good time to visit” are not the same thing.

The genuine surprises are Seoul, Mexico City, and Bangkok. Seoul (86°F, low crowd) has comfortable weather and does not thin out its food and nightlife scene in summer. Mexico City (77°F, low crowd) is 7,350 feet above sea level, which keeps August temperatures mild, and the rainy season means brief afternoon showers rather than gray all-day rain. Bangkok (93°F, low crowd) is hot, yes, but it is always hot, and the monsoon-season hotel rates can run 40-50% below peak.

If you want to check seasonal details for any of these cities, I keep updated destination guides at travelvient.com.

What this data does not tell you

These crowd levels are editorial classifications. I built them from tourism board data, published travel guides, and hotel occupancy patterns. They are not measured with turnstile counts or cell-phone density data. A different source might draw the peak/moderate/low boundary in a different place, and I would not argue with them.

The city-level view also hides a lot of variance. Paris being “peak” does not mean every arrondissement is equally packed. The Marais and the Eiffel Tower area are shoulder-to-shoulder in August, but the 13th arrondissement is not. Edinburgh during the Fringe Festival in August is a different city than Edinburgh the week before the Fringe starts.

And “low crowd” sometimes just means “bad weather.” I flagged this in the Africa section, but it applies elsewhere too. Cancun is low-crowd in August because it is hurricane season. The statistical likelihood of a direct hit during your specific week is small, but the risk changes your refund calculus, and some hotels close their beach services during storm watches.

The real problem is pricing

Here is the take I would defend at a bar. The crowds are manageable. You can book timed-entry tickets for the Uffizi. You can reserve a restaurant in Barcelona a week ahead. You can wake up early and beat the lines at Dubrovnik’s walls. Crowds are an inconvenience, not a dealbreaker.

The pricing is the dealbreaker. A round-trip flight to Rome in August can run $1,200 from the East Coast. The same flight in October: $550. A hotel in Santorini that costs $180/night in May costs $400+ in August. For a family of four on a ten-day trip, the August premium can add up to $3,000-$5,000 in flights and hotels alone. That is not an inconvenience. That is a second vacation’s worth of money.

The 16 low-crowd destinations in this dataset are interesting not because they are secret or obscure, but because they are priced for off-season while the rest of the world’s travelers pile into Europe and pay the premium.

What I want to test next

I have seasonal data for all 67 destinations, not just August. I want to run the same test for every month and find the month where the most destinations globally hit low crowd. My guess is February or November, but the data might surprise me. I also want to cross-reference crowd level against the daily budget cost data I maintain for these same cities, which would answer a more practical question: where is the cheapest low-crowd destination for each month of the year?

The dataset CSV is here: 67-destinations-august-crowd-test-2026.csv. If anything looks wrong or you have crowd data from a city I missed, I would like to hear about it.

I Checked Carry-On Rules at 75 Airlines: The Real Trap

cadendeveloper@gmail.com (Travel Vient) — Tue, 28 Apr 2026 00:00:00 GMT

Editor’s note (May 2026): Published before Spirit Airlines shut down on May 2, 2026 (Chapter 7 liquidation). Spirit’s numbers in the dataset below are a historical snapshot from when it still flew; the airline no longer operates.

I watched someone put their backpack in a sizer at a gate a couple of months ago. It was less than an inch over the personal item rule. The agent apologized, said no, and made her check the bag. She walked away frustrated. I walked away thinking about the data.

That moment kicked off a small project. I pulled the published carry-on and personal item rules for 75 airlines and tested both. The carry-on data came out about how I expected: 20 of 75 airlines reject a standard 22 by 14 by 9 inch suitcase outright on at least one published dimension. The personal item data did not. 21 of 75 airlines do not publish personal item dimensions at all, including Delta, the largest US carrier. Among the 54 that do, the smallest published allowance is roughly one third the volume of the largest.

How I tested

The data lives in a JSON file on my server. 75 airlines, each with a carryOn object and a personalItem object. Both have a published dimensionsIn field for length, width, and height when the airline publishes them, plus a flag for whether basic economy includes the carry-on. The data is verified against airline policy pages on a rolling 30-day cadence; the snapshot behind this post was last re-verified on May 21, 2026. The full per-airline dataset including everything below is at /data/75-airline-personal-item-trap-2026.csv.

The test bag is 22 by 14 by 9 inches. That is the size most US travelers picture when they hear “carry-on,” and the size most US-made hardshell suitcases ship as. I categorized each airline three ways. Pass means all three published dimensions are at or above 22, 14, and 9. Borderline means a single dimension is within half an inch of the test bag, and the others pass. Fail means at least one dimension is more than half an inch short of the test bag.

I used a dimension-by-dimension test, not the linear-inches sum. Linear inches (length plus width plus height, capped at 45 in most rules) hides the cases where a deep bag fits a tall slot. The dimension test is the version that tracks how a gate sizer actually checks: the bag has to drop into the slot, in any orientation, on all three sides.

The carry-on results

passes 22 by 14 by 9within 0.5 in below on one dimensionmore than 0.5 in below on at least one dimension

Sun Country Airlines24 in

Southwest Airlines24 in

Frontier Airlines24 in

Spirit Airlines22 in

British Airways22 in

Norse Atlantic Airways22 in

Saudia22 in

easyJet22 in

Thai Airways22 in

Allegiant Air22 in

Volaris22 in

Viva Aerobus22 in

Transavia22 in

Porter Airlines22 in

Discover Airlines22 in

SunExpress22 in

Air India22 in

Air Arabia22 in

Iberia22 in

Virgin Atlantic22 in

Etihad Airways22 in

Cathay Pacific22 in

AirAsia22 in

Qantas22 in

Virgin Australia22 in

Copa Airlines22 in

Delta Air Lines22 in

American Airlines22 in

United Airlines22 in

Alaska Airlines22 in

JetBlue22 in

Hawaiian Airlines22 in

Breeze Airways22 in

Jetstar Airways22 in

Bamboo Airways22 in

VietJet Air22 in

China Airlines22 in

EVA Air22 in

Cebu Pacific22 in

WestJet22 in

Aeromexico21.7 in

TAP Air Portugal21.7 in

ANA All Nippon Airways21.7 in

Japan Airlines21.7 in

Aer Lingus21.7 in

Lufthansa21.7 in

Wizz Air21.7 in

SWISS International Air Lines21.7 in

Austrian Airlines21.7 in

SAS Scandinavian Airlines21.7 in

Finnair21.7 in

Turkish Airlines21.7 in

Air New Zealand21.7 in

ITA Airways21.7 in

Vueling21.7 in

Singapore Airlines21.7 in

Korean Air21.7 in

Emirates21.7 in

flydubai21.7 in

Air France21.7 in

KLM Royal Dutch Airlines21.7 in

IndiGo21.7 in

Azul Linhas Aereas21.7 in

GOL Linhas Aéreas21.7 in

Norwegian Air Shuttle21.6 in

Condor21.6 in

Eurowings21.6 in

Ryanair21.6 in

Pegasus Airlines21.6 in

Avianca21.6 in

LATAM Airlines21.6 in

Air Canada21.5 in

Scoot21.3 in

Qatar Airways19.7 in

Spring Airlines12 in

37 airlines pass the test. 18 are borderline. 20 fail outright. The shape is rougher than I expected: more outright failures than the first cut showed, after the May refresh against airline policy pages.

The pass list groups along familiar lines. Three US ultra-low-cost carriers top the chart with 24-inch length allowances: Sun Country, Southwest, and Frontier. The big middle band sits at exactly 22 inches: US legacy carriers, a mix of European flag carriers, the major Asian and Middle Eastern carriers that map their published rule directly to the US convention. Volaris and Saudia both sit at 22, not 22.4, after the May verification pass.

The borderline cluster is more interesting. Almost all of it sits at 21.7 inches. That number is not arbitrary. 21.7 inches is exactly 55 cm. Most non-US carriers set their published rule in centimeters, then convert to inches with a touch of rounding, and 55 cm is the number they use. The standard US carry-on is 22 inches. The standard international carry-on is 55 cm. Those are not the same number. They are 0.3 inches apart. By the published rule, a US-bought 22-inch suitcase is technically out of spec at Lufthansa, SWISS, Air New Zealand, ANA, Japan Airlines, Aer Lingus, ITA, Turkish, and several Nordic carriers. The gap is small enough that gate sizers usually do not catch it. The gap is also why every traveler who has flown both has felt some version of this confusion.

The outright fails sort along their own logic. Ryanair, Pegasus, and Vueling publish 55 by 40 by 20 cm, which is 21.6 by 15.7 by 7.9 inches. The 7.9-inch depth is what kills a 9-inch standard suitcase. Singapore Airlines and Korean Air both publish 21.7 by 15.7 by 7.9 inches; the depth is what kills them on the test, not the length. Emirates publishes 21.7 by 15 by 8.7, just shy on length and just shy on depth. flydubai publishes 21.7 by 15 by 7.9, failing on the same two axes. Air France and KLM both publish 55 by 35 by 25 cm, which works out to 21.7 by 13.8 by 9.8 inches. The 35 cm width is what gets them: a 14-inch standard bag is just over their 13.8. The same width problem catches IndiGo, Azul, and the now-deduped GOL Linhas Aéreas (Brazil’s two big carriers map their cabin rule to the European 55 by 35 by 25 standard). WestJet’s published rule reads 22 by 9 by 14 with width and depth swapped relative to most other carriers; either way, a standard 14-inch-wide bag exceeds the published 9-inch width. Spring Airlines is the strictest in the dataset at 12 inches on the longest dimension, with a 7 kg (15.4 lb) weight cap that would fail a loaded carry-on regardless.

A side fact worth filing away: 25 of 75 airlines block carry-on entirely in basic economy. The list runs through the European budget set (Ryanair, Pegasus, Vueling, Condor, Norwegian, Eurowings, Wizz Air, Transavia) and crosses over to the European mainline group whose cheapest fare also strips the cabin allowance (Air France, KLM, SWISS, SAS, plus a handful of others). Add WestJet, Air Canada, Aeromexico, GOL, and a stack of US ULCCs, and the count is one in three airlines tested. On those airlines the suitcase that fits the rule cannot board unless you upgrade the fare. The published rule is gateable. The gate just is not open.

I expected the post to end there

While running the analysis I noticed every airline record had two carry-on fields, not one. The personal item. I expected this to be a copy-paste of the carry-on data, just with smaller numbers. It was not.

Of the 75 airlines, 54 publish personal item dimensions. 21 do not. That includes Delta, the largest US carrier by revenue. Delta’s published rule says only “must fit under the seat in front of you” and lists examples: purses, small backpacks, laptop bags. There is no length, no width, no depth. Alaska and Hawaiian leave their personal item dimensions unpublished too. The rest of the unpublished group skews international: Cathay Pacific, ANA, Japan Airlines, Singapore, Korean, Emirates, Etihad, Qatar, Air New Zealand, and a handful of South American and Asian budget carriers. The personal item rule for many of the largest airlines in the world is, in writing, “vibes.” American (18 by 14 by 8) and United (17 by 10 by 9) are the US legacies that do publish, and they are the exception, not the norm.

Among the 54 carriers that do publish personal item dimensions, the range is dramatic. The smallest published allowance is a three-way tie at 723 cubic inches. AirAsia, Condor, and Scoot each publish 15.7 by 11.8 by 3.9 inches, a thin folio shape. IndiGo, India’s largest domestic carrier, is the smallest by single longest dimension at 13.8 by 9.8 by 5.9, a small box about the size of a paperback novel laid flat (volume 798 cubic inches). Volaris in Mexico allows 17.7 by 13.7 by 9.8 inches, the largest published rule in the dataset at 2,376 cubic inches. The volume difference between Volaris and the smallest cluster is more than three to one.

The European mainline carriers cluster tightly at 40 by 30 by something cm, with most heights pinned at 15 cm (5.9 inches). Air France, KLM, Lufthansa, SAS, SWISS, Austrian, Finnair, Turkish, TAP, Iberia, ITA, Virgin Atlantic, and Pegasus all sit on or near that line. The 5.9-inch depth is the trap. A typical small backpack is 5 to 8 inches deep when packed; the published European personal item slot just barely accepts the slimmer end of that range, and only when unpacked enough to compress. The three carriers that cluster at the slimmest depth (3.9 inches) are AirAsia, Condor, and Scoot. Two of the three are budget carriers; one is a Lufthansa-owned leisure brand. The slim folio is not a regional pattern; it is a budget pattern dressed up as one.

The published personal item dimensions are widest at the US ULCCs and a few other carriers: American, Spirit, Saudia, and Viva Aerobus all publish 18 by 14 by 8 inches. Frontier publishes the same numbers in a different order (14 by 18 by 8). JetBlue and Breeze are similar at 17 by 13 by 8. Southwest is an outlier in shape: 18.5 by 8.5 by 13.5 inches, narrow but tall. United at 17 by 10 by 9 is on the smaller end of the US-published group; Delta, Alaska, and Hawaiian do not publish at all. The contrast between the European 15.7 by 11.8 by 5.9 rule and the American 18 by 14 by 8 rule is roughly two to one in volume.

If you want to check your specific bag against a specific airline, the data above powers a free checker at travelvient.com/tools/widgets/carry-on-size. It uses the same JSON file and updates on the same cadence.

What this data does not capture

None of the above accounts for gate enforcement. The published rule is the floor, not the ceiling. A bag that meets every published number can still get rejected at the gate. A bag that fails by half an inch can fly fine for years.

Ryanair will measure your bag and weigh it before you board. They have to: the fees on non-compliant bags are how the airline makes money. Lufthansa rarely measures and almost never weighs. American gate agents will eyeball most bags and only test in the sizer if the bag clearly looks oversized or the flight is full. The same airline can be strict at one station and loose at another. Summer routes to Europe are stricter than winter routes to anywhere. The flight that ramps up after a missed connection is stricter than the early morning bank. Whether your bag flies often depends on which side of someone’s bad day you arrive on.

The dataset is the scoreboard. The actual game is played at the jet bridge by a person whose mood you cannot predict. The gate moment I started this post with, where the bag was less than an inch off and the agent said no, is the part the data cannot reach.

Why I built the dataset

I built this because I needed structured airline data for the comparison pages on my travel site. There are 71 airline-vs-airline pages that all needed bag fees, carry-on dimensions, basic-economy rules, and a few other fields. Pulling those numbers from prose every time was a non-starter. Once it was structured, exposing it as a public tool was the obvious next step. The widget powering the bag size checker is the same JSON file behind this post and behind the comparison pages. There is one source of truth, and it gets refreshed on a 30-day cadence against the airlines’ own published policy pages.

That is also why this post can be specific. Every number above traces to a record in the file, and every record has a lastVerified date and a sourceUrl. The CSV linked at the top has all of that.

What I am still figuring out

The unanswered question is whether the airlines that do not publish personal item dimensions are stricter or looser at the gate than the ones that do. The Delta-style “fits under the seat” rule is permissive on paper and may translate to permissive in practice. Or it may not. I do not have that data. The next analysis I want to run is a sample of routes per airline at the gate, with a real bag, watching what gets through and what does not. That is a longer project and probably needs help from people who fly more than I do.

If you have a story about a personal item that got rejected (or one that should have been rejected and breezed through), I want to hear it. The stories are the part of this dataset that is missing.

Building a Layover Calculator That Knows Every Terminal at JFK

cadendeveloper@gmail.com (Travel Vient) — Mon, 27 Apr 2026 00:00:00 GMT

I already had 70 airports in the database. Each one had terminals, TSA wait times, lounges, ground transport, and layover guidance. The data was there because we built airport guides a few weeks earlier, and the research had gone deep. Minimum connection times were sitting in every airport record. The question “is my layover long enough?” was answerable with the data I already had.

So I built a calculator that answers it. Not a lookup table, not a blog post that says “most experts recommend 90 minutes.” A tool that takes your airport, your connection type, your terminal, and your layover duration, then tells you whether to relax or run.

What it does

The connection time calculator returns one of four verdicts: below MCT (the airline will not sell this connection on a single ticket), tight (meets MCT but leaves thin margins), comfortable (well above the suggested buffer), or long enough to leave the airport (6+ hours at airports with good city center access).

It factors in five things: the airport’s published MCT for your connection type (domestic-to-domestic, international-to-domestic, etc.), the terminal transfer time if you are changing terminals, customs and immigration wait time if arriving internationally, TSA re-screening if you leave the secure area, and checked-bag recheck time if you have bags on an international arrival.

The full page has a sortable comparison table of all 70 airports, 13 real-world scenario cards (“Is 60 minutes enough at JFK domestic-to-domestic?” with a verdict and reasoning), customs wait times broken out by region, and a 14-question FAQ. The calculator itself also ships as a free embeddable widget for travel blogs.

How I worked with Claude on this one

This was a tight back-and-forth in Claude Code. I described a section, Claude built it, I reviewed and redirected, repeat. The pace was fast because the widget infrastructure already existed from the carry-on and checked bag fee widgets. The iframe resize handshake, the embed page template, the customizer layout with live preview, the URL parameter validation patterns: all of that carried over.

The new work was the assessment algorithm, the enrichment data layer (terminal transfers and customs buffers for every airport), and bulking up the tool page from a bare calculator to 770+ lines with depth. I wrote a handoff document specifying seven scope items and the patterns to copy from sibling tool pages. Claude executed against it one section at a time while I verified data accuracy and caught theme bugs.

The stack

Same as the other widgets: Astro 5.x, fully static, Cloudflare Pages. The widget component lives at src/components/embed/ConnectionTimeWidget.astro with all CSS and JavaScript inline. Airport data gets compressed into short keys before serializing to a JSON script tag at build time:

const airports = allAirports.map(a => ({
  slug: a.slug,
  iata: a.iata,
  name: a.name,
  city: a.city,
  tc: a.terminalCount,
  terms: a.terminals.map(t => t.name),
  mct: {
    dd: a.minConnectionTimes.domesticToDomesticMin,
    di: a.minConnectionTimes.domesticToIntlMin,
    id: a.minConnectionTimes.intlToDomesticMin,
    ii: a.minConnectionTimes.intlToIntlMin,
    ac: a.minConnectionTimes.airsideConnected,
    ts: a.minConnectionTimes.transferSystem,
  },
  tsa: { peak: a.tsa.typicalWaitMinPeak, offpeak: a.tsa.typicalWaitMinOffPeak },
  enriched: hasEnrichment(a.slug),
}));

Each airport has about 50 fields in the full data model. The widget needs 15. The compression cuts the serialized payload roughly in half, which matters when you are shipping 70 airports inline.

The hard part: the enrichment data layer

The trickiest part of the entire build was not the algorithm or the UI. It was the data underneath.

Every airport already had a minimum connection time. But MCT alone does not tell you much. A 45-minute MCT at LAX means something very different depending on whether you are walking between gates in Terminal 4 or taking a shuttle from TBIT to Terminal 7 and re-clearing TSA. I needed pairwise terminal transfer data for multi-terminal airports, and customs wait estimates that were airport-specific rather than “30 minutes everywhere.”

The result was connection-enrichment.json, 516 lines of structured data covering all 70 airports:

{
  "dfw": {
    "terminalTransfers": [
      { "from": "Terminal A", "to": "Terminal B", "minutes": 8, "mode": "Skylink", "airside": true },
      { "from": "Terminal A", "to": "Terminal C", "minutes": 10, "mode": "Skylink", "airside": true },
      { "from": "Terminal A", "to": "Terminal D", "minutes": 12, "mode": "Skylink", "airside": true },
      { "from": "Terminal C", "to": "Terminal D", "minutes": 6, "mode": "Skylink", "airside": true }
    ],
    "customs": {
      "typicalMinPeak": 35,
      "typicalMinOffPeak": 15,
      "globalEntryMin": 5,
      "notes": "International arrivals clear customs in Terminal D."
    }
  }
}

Each transfer record captures the terminal pair, the transfer time in minutes, the mode (Skylink, Plane Train, AirTrain, shuttle bus, underground train, walking), and whether you stay airside. That last field is critical. If airside is false, you leave the secure area and need TSA re-screening, which adds 10 to 35 minutes depending on the airport and time of day.

The assessment function layers all five factors into a single recommended buffer:

const recommendedBufferMin =
  Math.max(mctMin, terminalTime + 30)
  + customsBuffer
  + securityBuffer
  + bagRecheckBuffer;

The Math.max is doing real work. At some airports, the terminal transfer time plus a 30-minute cushion exceeds the published MCT. At others, the MCT already accounts for the transfer. Taking the larger of the two prevents the calculator from recommending less time than the airport’s published MCT.

Where Claude surprised me

The enrichment data. I expected to spend a full day researching terminal transfers and customs waits for 70 airports. Claude produced the entire 516-line JSON file in one pass: pairwise transfers for the top 20 hubs (DFW has 9 terminal pairs, JFK has 10, LAX has 9), customs peak and off-peak estimates for all 70 airports, Global Entry times, and notes explaining the specifics at each airport.

The data was not perfect. I spot-checked a dozen airports against official sources and found the numbers were in the right range. JFK’s T1-to-T4 AirTrain transfer at 15 minutes matched. ATL’s Plane Train at 15 minutes between domestic and international was right. CDG’s CDGVAL times were reasonable. The customs estimates tracked with CBP’s published wait time data for US airports.

I was prepared to write all of this by hand. Claude doing it in one shot saved hours, and the structure it chose (pairwise terminal pairs with an airside flag per transfer) was exactly the schema I would have designed. That does not always happen. Sometimes Claude picks a schema that works but is awkward to query. This time it nailed the access pattern.

Where Claude fell short

Dark mode. Twice.

The first problem was in the tool page itself. Claude used hardcoded Tailwind color classes throughout: text-emerald-400 for success badges, text-rose-400 for danger, text-amber-400 for warnings. These look fine in dark mode. They look terrible in light mode because the 400-weight palette is designed for dark backgrounds. The site uses a data-theme attribute on the HTML element, not prefers-color-scheme, so these classes need to adapt per theme.

I caught this when I toggled the site to light mode and saw pale-on-white text everywhere. Claude replaced all the hardcoded classes with theme-aware CSS using [data-theme="dark"] and [data-theme="light"] selectors. That fix was straightforward.

The second problem was subtler. The widget renders inline on the tool page (not in an iframe), and it has its own theme system with CSS custom properties. Claude’s initial implementation only checked for a ?theme= URL parameter or fell back to prefers-color-scheme. It never looked at the site’s data-theme attribute. So you could toggle the site to light mode, the entire page would flip, and the calculator widget would stay dark.

The fix was a MutationObserver that watches the HTML element for data-theme changes:

var siteTheme = document.documentElement.getAttribute('data-theme');
if (siteTheme) root.setAttribute('data-theme', siteTheme);
var obs = new MutationObserver(function() {
  var t = document.documentElement.getAttribute('data-theme');
  if (t) root.setAttribute('data-theme', t);
  else root.removeAttribute('data-theme');
});
obs.observe(document.documentElement, {
  attributes: true,
  attributeFilter: ['data-theme']
});

This pattern syncs instantly when the user clicks the theme toggle. It also turned out the same bug existed in the three older widgets (carry-on, bag fit, checked bag fees), so we retrofitted the fix into all four. Claude should have caught this during the initial build. The theme system is not new, and the data-theme attribute is visible in the site’s global CSS. But the widget’s self-contained design (its own CSS custom properties, its own theme logic) meant Claude treated it as isolated from the host page’s theme. In iframe mode, that is correct. In inline mode, it is not.

What went wrong overall

The commit was too big. The entire feature landed in a single 2,874-line commit: the widget component, the enrichment data, the full tool page, the embed page, the customizer, the theme fixes across four widgets, the index page cards. That is too much surface area to review in one pass, and it makes git bisect useless if something breaks later.

The reason it happened was velocity. The back-and-forth with Claude was fast enough that breaking for a commit felt like an interruption. The handoff document laid out seven scope items, and we knocked them out sequentially without stopping to checkpoint. That worked for shipping speed. It did not work for reviewability.

Where it is now

The calculator is live at travelvient.com/tools/connection-time with the full depth pass: sortable MCT comparison table, 13 scenario cards, customs-by-region panel, best and worst airports for connections, methodology section, and 14-question FAQ. The embeddable widget is also live with the same customization options as the other three widgets: light/dark/auto themes, accent color, corner radius, compact mode, and URL parameters to pre-select the airport and connection type.

What I would do differently

Commit after each scope item, not after all seven. The handoff document had clean boundaries: enrichment data, widget component, tool page sections, embed page, customizer, theme fixes. Each one was independently shippable. Batching them into one commit saved no time and made the code review harder. Claude and I both knew there were seven items. We should have committed seven times.

Establish the widget theme contract before building any more widgets. The MutationObserver pattern should have existed from the carry-on widget. Every widget we build inline will need to sync with data-theme. Retrofitting four widgets at once is a sign that this should be a shared utility or at least a documented convention, not something each widget reinvents.

Test the enrichment data against primary sources before building UI on top of it. Claude’s data was close enough that I did not catch any errors in my spot checks, but “close enough” is a dangerous bar for a tool people use to decide whether they will make their flight. I should have run a systematic verification pass against CBP wait time data and airport websites before the data went live, not after.

Forbes Featured the Travel Vient Carry-On Tools

cadendeveloper@gmail.com (Travel Vient) — Sat, 25 Apr 2026 00:00:00 GMT

A small but quietly meaningful thing happened today. I am Caden Sorenson, the developer behind Travel Vient, and Forbes travel columnist Christopher Elliott published Here’s Your Summer 2026 Digital Survival Kit For Flight Delays And Cancellations, a roundup of the apps and tools he recommends travelers use this summer. Two of the Travel Vient tools made the cut.

In the “Lost luggage tracker and security tools” section, Elliott wrote:

Sorenson built a pair of tools that let travelers enter bag dimensions and see instantly which of 75+ airlines will accept it as a carry-on or personal item. Every entry is manually verified against airline published policy.

The Forbes piece links to the Travel Vient homepage, but the two tools the column is actually about are the carry-on size checker and the checked bag fee calculator. Both pull from the same hand-curated database of 75+ airlines, and both are free with no signup.

The line I appreciated most was “every entry is manually verified against airline published policy.” The reality is a bit more nuanced: most of the data comes straight from official airline sources that are straightforward to cite, and we spot-check the entries that are harder to verify or where published policies are ambiguous. It is not a full manual audit of every row, but it is a lot more diligence than scraping and hoping for the best. Gate agents do not care that a third-party aggregator said your bag was fine, so getting the numbers right matters. The site has a methodology page that walks through the sourcing process and how policy changes get caught.

Christopher was looking for sources on travel tools, and I pointed him to a few options including Travel Vient. He tried them out and liked them enough to include them in the piece by name.

If you came here from the Forbes piece: welcome. The carry-on size checker is the right starting point if you are trying to figure out whether your bag will fit, and the checked bag fee calculator is the right one if you are trying to figure out what a trip will cost you in baggage. If you run a travel blog, the embeddable widgets are free to drop into any post.

I Let Claude Design My Homepage Hero and Shipped What It Built

cadendeveloper@gmail.com (Travel Vient) — Fri, 24 Apr 2026 00:00:00 GMT

I had been staring at the homepage hero for a while. It was fine. Clean text, a couple of CTA buttons, the usual indie-dev landing page. But for a site about travel tools, it felt static. The homepage for a site that tracks flight routes and airline data should probably look like it knows what a flight route is.

I did not have a design in mind. I barely had a direction. I knew I wanted something animated, something that said “travel” without being a stock photo of a suitcase, and something that would not tank my Lighthouse score. That was the whole brief.

So I opened Claude Design and gave it basically nothing to work with.

The “decide for me” conversation

Claude Design starts by asking a battery of questions: what kind of animation, what tone, whether you are open to layout changes, how interactive you want it, how content should integrate. Normal design-tool intake stuff.

I answered all six questions the same way: “Decide for me.”

That sounds lazy, and it sort of was. But I was genuinely curious what would happen if I handed creative direction entirely to the AI and just played the role of someone with veto power. No mood boards, no reference links, no “I want it to look like the Stripe homepage.” Just: here is my site, here is my content, go.

Claude came back with a specific, opinionated concept: a layered world map with animated flight paths arcing between real destinations, plane sprites traveling the routes, and destination pins that pulse when planes arrive. It committed to a design system before writing a single line of code. Deep charcoal background, amber accent at #f5b82e, geometric plane silhouettes, mouse parallax across three depth layers.

The fact that it committed to a design system first, before building anything, was the moment I started paying attention. That is not how I expected a “decide for me” prompt to go.

Two concepts, not one

After I saw the first prototype and told Claude I liked it, I asked for a second option. Not because the first one was bad. I just wanted to see if it could produce something genuinely different, or if it would give me a variation on the same idea.

It proposed a split-flap departure board. The old mechanical kind you used to see in airports, where characters flip through the alphabet until they land on the right letter. Rows would cycle through real routes and airlines from my content, with status columns flashing “BOARDING” and “DELAYED” in amber and red. Pure DOM with CSS 3D transforms for the flap physics.

That was a legitimately different concept. Not a reskin, not a color swap. A completely different visual metaphor with a different rendering approach (DOM vs. canvas) and a different emotional register. The world map feels atmospheric and exploratory. The departure board feels tactile and data-forward.

The departure board had problems, though. The CSS for the split-flap cells was wrong on the first pass. The character positioning inside the half-flaps broke because rotateX(180deg) on the back panel interacts with bottom: 0 positioning in a way that is not intuitive. Claude had to reason through the 3D transform chain multiple times, talking itself through “at animation start the parent has rotateX(0), the front panel faces the viewer showing the top half” and so on. It eventually got the math right, but it took several rounds.

The board also overflowed its container on mid-size viewports. Claude set the breakpoint at 900px but the board was still too wide at 924px. It had to bump the breakpoint to 1100px and tighten cell sizes. These are the kind of layout issues that feel trivial in hindsight but burn real iteration cycles when you are going back and forth with a tool.

What I shipped

I picked the world map. The departure board was cool, but the map felt more like a homepage and less like a feature demo.

The engine Claude built is a vanilla JavaScript IIFE that draws on three stacked <canvas> elements. No animation libraries, no framework code. Just requestAnimationFrame and the Canvas 2D API.

The continents are not loaded from an image or SVG. They are approximated with 23 rotated ellipses, and a function checks whether any given lat/lng coordinate falls inside one:

const LAND_BLOBS = [
  { cx: -100, cy: 45, rx: 40, ry: 22, rot: 0.1 },   // North America
  { cx: 90,   cy: 55, rx: 48, ry: 18, rot: -0.05 },  // Europe/Asia
  // ... 21 more blobs
];

function isLand(lng, lat) {
  for (let i = 0; i < LAND_BLOBS.length; i++) {
    const b = LAND_BLOBS[i];
    const dx = lng - b.cx, dy = lat - b.cy;
    const c = Math.cos(b.rot), s = Math.sin(b.rot);
    const x = dx * c - dy * s, y = dx * s + dy * c;
    if ((x * x) / (b.rx * b.rx) + (y * y) / (b.ry * b.ry) < 1) return true;
  }
  return false;
}

It is not geographically accurate. It is stylized enough to read as “world map” while staying under 30 lines of code. No GeoJSON, no tile server, no external assets. I thought Claude would reach for a library or a data file for the continents. The blob approach was a genuine surprise.

Flight paths use quadratic Bezier curves with a lifted control point to simulate great-circle arcs:

const dx = this.b.x - this.a.x, dy = this.b.y - this.a.y;
const len = Math.hypot(dx, dy);
const mx = (this.a.x + this.b.x) / 2;
const my = (this.a.y + this.b.y) / 2;
const nx = -dy / len, ny = dx / len;

const lift = Math.min(len * 0.35, 180);
const sign = ny < 0 ? 1 : -1;
this.c = { x: mx + nx * lift * sign, y: my + ny * lift * sign };

The lift is capped at 180 pixels so long-haul routes (like JFK to NRT) do not arc off the top of the screen. Short routes get proportionally flatter arcs. That cap was something I would have had to debug myself if Claude had not thought of it.

The parallax runs at three depth levels. The world dots shift at 14px, the routes and planes at 22px. Mouse position is smoothly interpolated each frame so the motion feels fluid rather than jittery:

this.mouse.px += (this.mouse.tx - this.mouse.px) * 0.06 * this.cfg.parallax;
this.mouse.py += (this.mouse.ty - this.mouse.py) * 0.06 * this.cfg.parallax;

The plane sprites are drawn purely with moveTo/lineTo calls. No images, no SVG embeds. About 12 lines of path commands per plane, with a shadowBlur glow behind them in amber:

ctx.shadowColor = PAL.accent;
ctx.shadowBlur = 8;
ctx.fillStyle = PAL.accent;
ctx.beginPath();
ctx.moveTo(5, 0);
ctx.lineTo(-3, -1.6);
ctx.lineTo(-2, 0);
ctx.lineTo(-3, 1.6);
ctx.closePath();
ctx.fill();

Tiny geometric silhouettes that read as airplanes at the scale they are drawn. If you zoom in they look like arrowheads. At normal size they work.

Where Claude surprised me

The animation quality was better than what I would have built myself, full stop. I am not a canvas animation person. I can write a requestAnimationFrame loop and draw rectangles, but the layered approach with separate canvases for world/paths/planes, the smooth parallax interpolation, the pulse train trailing behind each plane, the destination pins that glow when planes arrive or depart: that is a level of polish I would not have reached on my own in a reasonable timeframe.

The engine also handles prefers-reduced-motion by drawing a single static frame instead of running the RAF loop, and uses an IntersectionObserver to skip rendering when the hero scrolls out of view. Those are the accessibility and performance details that I know I should add but often skip when I am prototyping. Claude included them in the first pass.

Where Claude fell short

The split-flap departure board (the concept I did not ship) needed multiple rounds of CSS fixes. The 3D transform math for the flap animation was wrong initially. Claude had to talk itself through the rotation chain step by step, and even then it was not confident the fix was correct until it could visually verify. That kind of spatial reasoning about nested 3D transforms is clearly still hard.

The board also had a responsive layout bug that took two attempts to fix. Claude set the grid breakpoint at 900px, but the board was still too wide at viewports just above that threshold. These are not catastrophic failures, but they are the kind of thing that makes you realize the tool is not a replacement for testing in a browser at multiple widths.

Claude Design also had persistent file loading issues during the session. It created the HTML prototype files correctly, but kept failing to load them for verification. It tried renaming files, inlining scripts, and retrying, but never fully diagnosed the issue. The prototypes worked fine when I opened them manually. This was friction, not a design problem, but it ate time.

The hardest part

Choosing between the two concepts was genuinely the hardest decision. Both were good for different reasons. The world map felt like a homepage. The departure board felt like a product. I went with the map because the site’s brand is more “explore the world” than “check the data,” but I could see the departure board working well as a section on an airline comparison page someday.

Getting the prototype from Claude Design into my actual Astro site was also nontrivial. Claude Design outputs self-contained HTML files. My site uses Astro components, Tailwind, and a specific layout system. Splitting the prototype into HeroFlightAnimation.astro (328 lines of markup) and flight-engine.js (497 lines of vanilla JS) was its own task. Claude Code handled that translation in a separate session.

What I would do differently

First, I would not answer every question with “decide for me.” It worked here because I was genuinely open to anything, but Claude makes better choices when you give it constraints. “Atmospheric, not playful” or “canvas only, no DOM animation” would have saved the departure board detour. Creative freedom sounds good in theory, but constraints produce better first drafts.

Second, I would ask for both concepts up front instead of asking for a second one after seeing the first. Claude Design had to rebuild all the shared scaffolding (hero copy, nav, tweaks panel) for the second prototype. If I had asked for two directions from the start, it could have shared more structure between them.

Third, I would pair Claude Design with Claude Code from the beginning instead of treating them as separate phases. The prototype-to-production translation was a full work session on its own. If the prototype had been built as an Astro component from the start, that step disappears. The tradeoff is that Claude Design’s sandbox is simpler than a real project, which probably helps it iterate faster on the visual side. But for a site where I know the stack, I would rather iterate slower and skip the port.

Related: the live homepage and more devlogs.

Building a Checked Bag Fee Calculator That Computes

cadendeveloper@gmail.com (Travel Vient) — Thu, 23 Apr 2026 00:00:00 GMT

The carry-on size widget was a lookup tool. Pick an airline, see its dimensions. The data was static per airline, the rendering was a fixed card, and the interesting engineering was in the iframe plumbing and data pipeline underneath it. When a reader and a few travel bloggers asked for an embeddable version of our checked bag fee tool, I assumed it would be the same build with different data. It was not.

The checked bag fee widget is a calculator. It takes four inputs (bag count, trip type, weight, linear dimensions), computes a per-airline total from six different fee fields, handles null data without lying about costs, sorts 75+ airlines by computed total, and badges the cheapest and most expensive results. That computation layer is what made this widget genuinely different from the carry-on embed, and it is where most of the interesting problems lived.

What it does

The checked bag fee calculator widget lets a reader on any blog compare checked bag costs across 75+ airlines with their specific trip details. Select 1, 2, or 3 bags. Toggle domestic or international. Enter a weight and linear dimension if you want to catch overweight and oversize surcharges. The widget computes the total for every airline and sorts cheapest first.

Each airline row shows the individual fee breakdown (first bag, second bag, international rate) plus the computed total. Airlines with free checked bags show a green “$0.” Airlines where the bag exceeds the weight limit or oversize threshold get a warning badge. The cheapest airline gets a “Cheapest” badge, the most expensive gets “Most expensive.”

All of this runs inside a single iframe. No framework, no external requests after page load, under 50 KB total. A short HTML snippet to embed.

How I worked with Claude on this one

This was the fastest widget build we have done. The carry-on widget established all the infrastructure: the iframe-to-host postMessage resize handshake, the resize.js listener, the URL parameter validation patterns, the inline-everything-for-zero-dependencies approach, the Astro embed page template, the widget landing page layout with the visual customizer. All of that already existed.

So when I described the checked bag fee widget to Claude via Claude Code, it copied the existing patterns and had a working first version in one session. The carry-on widget was a two-day build. This one was half a day. Most of my time went into the calculator logic and the resize timing, not infrastructure.

The stack

Same as the carry-on widget: Astro 5.x, static output, Cloudflare Pages. The widget is a standalone Astro component at src/components/embed/CheckedBagFeesWidget.astro with all CSS and JavaScript inline. The airline data gets serialized into a <script type="application/json"> tag at build time, so there are no runtime fetches.

The data shape is compressed the same way as the carry-on widget, mapping verbose property names to short keys to keep the payload small across 75+ airlines:

const airlines = allAirlines
  .filter(a => a.checkedBag)
  .map(a => ({
    slug: a.slug,
    name: a.name,
    iata: a.iata,
    region: a.region,
    cat: a.category,
    first: a.checkedBag.firstBagUsd,
    second: a.checkedBag.secondBagUsd,
    intl: a.checkedBag.firstBagIntlUsd,
    over70: a.checkedBag.overweight51to70Usd,
    over100: a.checkedBag.overweight71to100Usd,
    oversize: a.checkedBag.oversize63to80Usd,
    wLim: a.checkedBag.weightLimitLb,
    lv: a.checkedBag.lastVerified ?? a.lastVerified,
  }));

Six fee fields per airline instead of the carry-on widget’s three. That is where the complexity budget went.

The hard part: computing totals with holes in the data

The core of the widget is a computeTotal() function that takes an airline and the current calculator state and returns a total fee plus any warning flags. This sounds simple until you account for all the edge cases.

Third bags do not have a published fee for most airlines. We estimate them at 1.5x the second bag fee, which is close to what most carriers charge. If the second bag fee is null, the third bag estimate is also null. Overweight surcharges apply at two thresholds: 51-70 lb and 71-100 lb. Bags over 100 lb are rejected by most airlines entirely. Oversize kicks in between 63 and 80 linear inches. Over 80, most airlines refuse the bag.

function computeTotal(a) {
  var firstFee = trip === 'international'
    ? (a.intl !== null ? a.intl : a.first)
    : a.first;
  var parts = [];
  var flags = [];

  if (bagCount >= 1) parts.push(firstFee);
  if (bagCount >= 2) parts.push(a.second);
  if (bagCount >= 3) parts.push(
    a.second !== null ? Math.round(a.second * 1.5) : null
  );

  var weight = parseFloat(weightInput.value);
  if (!isNaN(weight) && weight > 0) {
    if (weight > 100) flags.push('Exceeds weight');
    else if (weight > 70) parts.push(a.over100);
    else if (weight > 50) parts.push(a.over70);
    if (a.wLim !== null && weight > a.wLim)
      flags.push('Over limit');
  }

  if (parts.some(function(p) { return p === null; }))
    return { total: null, flags: flags };
  var total = 0;
  for (var i = 0; i < parts.length; i++) total += (parts[i] || 0);
  return { total: total, flags: flags };
}

The critical line is the null check near the bottom. If any parts entry is null, the whole total is null. This was a deliberate design decision. If we do not know the overweight surcharge for an airline and the reader entered 65 lb, showing just the base bag fee would be misleading. It would look like that airline is cheaper than it actually is. Better to show “N/A” and let the reader check the airline’s site.

Claude wrote the first version of this function. I rewrote the null propagation. Claude’s original version defaulted nulls to zero, which would have ranked airlines with missing surcharge data as the cheapest options. That is exactly the kind of subtle data bug that makes a tool untrustworthy.

Where Claude surprised me

The badge assignment logic in the apply() function. After sorting all airlines by computed total (with nulls pushed to the bottom via a 999999 sentinel value), the widget needs to label the cheapest and most expensive results. Claude handled the edge cases I would have missed:

var badge = '';
if (item.flags.length > 0) {
  badge = '<span class="cbf-badge cbf-badge-warn">'
    + item.flags.join(' / ') + '</span>';
} else if (filtered.length > 1 && item.total !== null) {
  if (j === 0) {
    badge = '<span class="cbf-badge cbf-badge-cheap">Cheapest</span>';
  }
  var lastWithTotal = -1;
  for (var k = filtered.length - 1; k > 0; k--) {
    if (filtered[k].total !== null) { lastWithTotal = k; break; }
  }
  if (j === lastWithTotal && j !== 0) {
    badge = '<span class="cbf-badge cbf-badge-expensive">'
      + 'Most expensive</span>';
  }
}

Warning flags take priority over cost badges. The “Most expensive” label skips airlines with null totals by walking backward from the end of the sorted list to find the last airline with a real number. If only one airline has data, neither badge shows. Claude got all of this right on the first pass. I was about to write it myself and realized it was already done.

Where Claude fell short

The resize timing. This is the problem I called out in the interview: getting the iframe height right after the page loads, not just when a user interacts with it.

The carry-on widget had a simpler version of this problem because its content height is mostly stable. Pick an airline, the card renders, send a resize. But the checked bag fee widget renders a scrollable list of 75+ airlines on load, and the list height depends on which filters are active, how many results match, and whether the calculator inputs have changed the sort order.

Claude’s first approach was to fire sendResize() once after apply(). That works if the iframe’s content has finished painting by the time the message sends. It often had not. The iframe would load, apply() would run, the resize message would fire with a stale height, and then the actual content would paint at a different height. The result was clipped content or extra whitespace depending on the timing.

I ended up writing the resize timing myself. The solution is a combination of interval polling and ResizeObserver:

var pollCount = 0;
var pollId = setInterval(function() {
  sendResize();
  if (++pollCount >= 50) clearInterval(pollId);
}, 200);

if (typeof ResizeObserver !== 'undefined') {
  new ResizeObserver(sendResize).observe(root);
}

The polling catches the initial render window: 50 checks at 200ms intervals covers the first 10 seconds, which is enough for any reasonable page load. The ResizeObserver takes over after that for ongoing changes (filter toggles, search narrowing, weight input). Belt and suspenders. It is not elegant, but it works on every host page I have tested.

What went wrong overall

The fee data itself was the hardest non-code problem. Airline baggage fees are surprisingly inconsistent in how they are published. Some airlines list fees per direction, some per round trip. Some publish overweight surcharges on the same page as standard fees, some bury them in a separate “special items” page. A few airlines publish different fees depending on the booking channel (website vs airport vs phone).

I had to make normalization decisions: all fees are one-way, all fees are the website/online booking price, overweight thresholds are standardized to the 51-70 and 71-100 lb brackets even when an airline uses slightly different breakpoints. These are reasonable defaults, but they mean the widget’s numbers are close approximations, not guaranteed quotes. That is why every airline row links to the official source page.

Where it is now

The widget is live at travelvient.com/tools/widgets/checked-bag-fees with the same customization options as the other two widgets: light/dark/auto themes, custom accent colors, adjustable corner radius, compact mode for sidebars, and URL parameters to pre-set the bag count, trip type, weight, and dimensions. It is also embedded in several of our own guides, including the best checked bag fee calculators roundup and the how to add travel widgets tutorial.

What I would do differently

First, I would have written the computeTotal() function test-first. The null propagation, threshold logic, and third-bag estimation have enough edge cases that a simple test harness with a few mock airlines would have caught the zero-default bug Claude introduced before I noticed it in the UI. Writing calculator logic without tests and then debugging it visually was slower than it needed to be.

Second, the resize polling is a hack I should replace. A MutationObserver on the list element, firing only when innerHTML changes, would be more precise than polling 50 times and hoping one of those polls lands after paint. The current approach works, but it sends dozens of unnecessary postMessage calls to the host page during the first 10 seconds of load.

Third, I should have standardized the fee normalization rules in the data layer, not in the widget. Right now, the normalization decisions (one-way fees, online booking price, standardized weight brackets) are baked into the data entry process and documented nowhere except my own notes. If someone else contributes airline data, they would not know which conventions to follow. That is a data pipeline problem, not a widget problem, but the widget is what exposed it.

I Built a Free Embeddable Carry-On Size Widget for Travel Blogs

cadendeveloper@gmail.com (Travel Vient) — Mon, 20 Apr 2026 00:00:00 GMT

Editor’s note (2026-05-17): This post describes the widget’s design as of April 2026. In May 2026 we added anonymous usage analytics (widget loads, key interactions, embedding domain, country, device class) so we can see which widgets earn engagement and where to focus next. The widget still sets no cookies and shares no personal data. See the privacy page for the full disclosure.

A travel blogger emailed me a few weeks ago asking if she could embed our carry-on size checker directly into one of her posts. She was writing a packing guide for budget airlines and wanted her readers to check their specific bag against each airline without leaving the page. I told her no, because the tool was a full-page Astro component with site-wide styles, a navigation bar, and a footer. It was not designed to live inside someone else’s site.

That request stuck with me. I looked around for existing embeddable carry-on checkers that a travel blogger could just drop into a post. The options were bad. Most “widgets” were just affiliate links dressed up as tools. The few real ones had outdated data, tracked visitors, or required a paid account. Nobody was doing the obvious thing: a free, lightweight iframe with verified airline data that auto-updates.

So I built one.

Your browser does not support embedded video. You can download the MP4.

Carry-on size embed widget demo Picking an airline, reading carry-on and personal item dimensions, weight limits, fees, and the gate-check risk rating, all from a single drop-in iframe.

What it does

The carry-on size embed widget is a drop-in carry-on bag size checker for any website. A short HTML snippet. No accounts, no API keys, no cookies.

A reader picks an airline from the dropdown and sees carry-on dimensions (inches and centimeters), personal item limits, weight restrictions, the carry-on fee, and a gate-check risk rating. Every data point links back to the airline’s official baggage policy page with a “last verified” date.

It covers 75+ airlines across North America, Europe, Asia-Pacific, Latin America, and the Middle East. When we update the data, every embedded widget everywhere reflects the change automatically. The site owner does nothing.

Here is the widget itself, running live inside this post. Pick any airline to see exactly what a reader would see on a travel blog that had embedded it:

Live embed. Same iframe, same data, same drop-in install a blogger would use.

The widget supports light, dark, and auto (OS preference) themes. You can set a custom accent color, adjust corner radius, toggle compact mode for sidebars, and lock it to a default airline. A visual customizer on the landing page lets you configure everything and copy the embed code.

How I worked with Claude on this one

This was a pairing build. I described the concept and Claude (via Claude Code) did most of the initial implementation, but a big chunk of the work was not the widget itself. It was the data layer underneath it.

We already had 75+ airlines in a JSON file, but keeping that data fresh is the real problem. Airlines change their baggage policies constantly. A checked bag fee goes up $5, a weight limit changes from 15 kg to 10 kg, a basic economy restriction gets added quietly. So Claude and I spent a significant amount of time building a manifest-driven fact refresh system that verifies data on a rolling 30-day cycle. Every fact gets checked against two independent sources before it is trusted. If the sources disagree, a third source breaks the tie. If an auto-fix happens, any comparison articles referencing that airline get flagged for prose review.

We turned that entire verification system into a Claude Code skill, so I can run /refresh-facts airlines and it will triage the most stale airline records, verify them against official sources and aggregators like The Points Guy and NerdWallet, and auto-fix what it can. That pipeline is what makes the embed widget trustworthy. Without it, this would just be another tool with stale data.

The stack

Astro 5.x, static output, deployed to Cloudflare Pages. The widget is an iframe pointing at /embed/carry-on/, which is a standalone Astro page with zero external dependencies. All CSS is inline and scoped to a .va-embed class prefix to avoid leaking into host pages. All JavaScript is inline too. No framework, no bundler output, no external requests after page load.

The airline data gets serialized into the widget HTML at build time via a <script type="application/json"> tag. This means the widget is a single static HTML file with everything baked in. No runtime data fetches. The total payload is under 50 KB.

Claude suggested compressing the airline data for the widget by mapping verbose property names to short keys:

const airlines = allAirlines.map(a => ({
  slug: a.slug,
  name: a.name,
  ci: a.carryOn.dimensionsIn,
  cc: a.carryOn.dimensionsCm,
  wLb: a.carryOn.weightLimitLb,
  wKg: a.carryOn.weightLimitKg,
  fee: a.carryOn.feeUsd,
  ok: a.carryOn.allowed,
  piI: a.personalItem.dimensionsIn,
  piC: a.personalItem.dimensionsCm,
  risk: a.gateCheckRisk,
  be: a.basicEconomyRestricted,
  lv: a.lastVerified,
  src: a.sourceUrl,
}));

Not revolutionary, but it cut the JSON size meaningfully when you multiply it by 75+ airlines. That was a pattern I would not have bothered with on my own for a v1.

The hard part: iframe auto-resize

Iframes do not auto-expand to fit their content. The widget height varies depending on the airline (some have weight limits, some do not, some do not allow carry-ons at all), the theme, and whether compact mode is on. A fixed height="420" works as a sensible default, but it leaves whitespace or clips content depending on the selection.

The solution is a postMessage handshake between the widget and the host page. The widget measures its own height and tells the parent:

function sendResize() {
  if (window.parent !== window) {
    window.parent.postMessage({
      type: 'va-embed-resize',
      height: document.documentElement.scrollHeight
    }, '*');
  }
}

The host page loads a 14-line script that listens for that message and adjusts the iframe height:

window.addEventListener("message", function (e) {
  var d = e.data;
  if (!d || d.type !== "va-embed-resize" || typeof d.height !== "number")
    return;
  var frames = document.querySelectorAll("iframe");
  for (var i = 0; i < frames.length; i++) {
    if (frames[i].contentWindow === e.source) {
      frames[i].style.height = d.height + "px";
      break;
    }
  }
});

The resize fires on initial load, on airline selection change, and via a ResizeObserver for anything else that shifts the layout. I solved this one myself. Claude’s first approach was to set a generous fixed height and call it done, which would have worked but looked sloppy on most sites.

Where Claude surprised me

The data compression was the standout. When I described the widget concept, Claude immediately suggested compressing the property names for the embedded JSON payload and explained why: the full airlines.json with verbose keys is ~9,500 lines. The widget only needs display fields, so mapping to single-letter keys and dropping unused nested objects (checked bags, special items, basic economy details) keeps the widget fast on mobile connections. It is the kind of optimization I would have deferred to v2 or never done.

Where Claude fell short

The first version Claude built was too basic. It was functional, it showed airline data in a dropdown, but it was not something a real travel blogger would want on their site. No theme options, no custom colors, no border radius control, no compact mode. It worked, but only for one kind of site with one kind of design.

I had to push Claude through several rounds of “make this actually reusable.” Custom accent colors via URL parameters. Light, dark, and auto themes with proper CSS custom properties. A radius slider. A compact mode that scales all spacing proportionally. Each round Claude executed well, but it did not anticipate that an embeddable tool needs to fit into someone else’s design system, not just look good on its own. That product thinking was on me.

What went wrong overall

The URL parameter validation was a subtle security concern. The widget reads theme, color, radius, and airline from query parameters, and those parameters get applied to CSS and DOM attributes. Claude’s initial implementation did not validate the color parameter, which could have been a vector for CSS injection. I caught it and we added a strict hex regex:

var colorParam = params.get('color');
if (colorParam && /^[0-9a-fA-F]{6}$/.test(colorParam)) {
  root.style.setProperty('--accent', '#' + colorParam);
}

The radius gets clamped to 0-24, the theme only accepts 'light' or 'dark', and the airline slug is checked against the data map before use. None of these would have caused a major exploit, but shipping an embeddable widget means your code runs on someone else’s site. The bar is higher.

Where it is now

The widget is live at travelvient.com/tools/widgets/carry-on-size with 75+ airlines, full customization, and a visual configurator that generates the embed code. The data pipeline behind it runs on a 30-day verification cycle. Since launch, two more widgets have shipped: a bag fit checker and a checked bag fee calculator. Browse all widgets at travelvient.com/tools/widgets.

What I would do differently

First, I would have spec’d the customization options before writing any code. Starting with a bare widget and retrofitting theme support, custom colors, and compact mode was more work than doing it upfront. The widget essentially got rebuilt twice.

Second, I would have built the data compression into the widget from the start rather than serializing the full airline objects and trimming later. Starting with a clear “widget data contract” separate from the full airline schema would have been cleaner.

Third, the fact refresh system should have existed before the embed widget, not alongside it. Building an embeddable tool and a data verification pipeline at the same time meant splitting focus. The refresh system was the more important piece, and getting it right first would have made the widget launch feel less rushed.

How to Set Up a Claude Code Statusline (Step-by-Step)

cadendeveloper@gmail.com (Travel Vient) — Fri, 17 Apr 2026 00:00:00 GMT

I’m on Claude Code Max 5x. It’s a generous plan. It is also not infinite.

Three things kept catching me off guard. The 5-hour session window would fill up in the middle of a long chain of edits and suddenly I was on a cooldown I hadn’t seen coming. The 7-day rolling limit was a slower version of the same problem. And the context window would creep toward full during a deep session and I’d only notice when the responses got weirdly slow.

I knew all three numbers existed somewhere. You can already get the rate limits by running /usage in Claude Code, and the context window by running /context. I was running both commands several times an hour, which is exactly the friction I was trying to avoid in the first place.

It turns out Claude Code has a statusline feature that very few people seem to know about. It runs a shell command before every prompt and prints whatever that command returns at the bottom of your terminal. That’s the whole primitive. You get to decide what goes in it. So instead of typing /usage and /context on demand, I put both of them plus my working directory and my 5h reset time in the statusline and never have to ask again.

The good news: you don’t have to write any bash to get this. Claude Code does it for you.

How to set up a Claude Code statusline in 60 seconds

Inside any Claude Code session, type:

/statusline

That fires the built-in statusline-setup agent. Then tell it, in plain English, what you want shown. Here’s roughly what I asked for:

I want my working directory, the model I’m using, the current git branch, my 5-hour usage window, my 7-day usage window, and my context window. Show the meters as severity-colored progress bars: green under 50%, yellow 50 to 80%, red over 80%. Put the reset time next to the 5-hour bar.

That single message is enough. The agent writes the bash, drops the script at ~/.claude/statusline-command.sh, and registers it in ~/.claude/settings.json for you. Restart Claude Code, run a prompt, and the statusline shows up under the input after the first response.

You can ask for whatever fields you want. The JSON the harness pipes to the script includes both rate-limit windows with reset timestamps, the context window, the working directory, and the model name. If you want the git branch, the agent will shell out to git to grab it. Mix and match.

Here’s what mine looks like once it’s running:

Folder, 5h bar with reset time, 7d bar, context bar. The bars shift from green to yellow to red as they fill, so I can scan the line without reading numbers.

If the first pass doesn’t quite land, keep talking. “Move the folder to the front.” “Drop the percent number, the bar is enough.” “Use a shorter label for the 5-hour bar.” Each round is one short message. I went four rounds before I landed mine, and I never touched the bash myself.

That’s the whole setup. The rest of this post is the story of how mine came together, the bits where Claude surprised me, and the full bash script if you’d rather paste it directly than have the agent rebuild it.

What the Claude Code statusline actually is

A statusLine entry in your ~/.claude/settings.json that points at a script. Every time you hit enter on a Claude Code prompt, the harness pipes a JSON blob to that script over stdin and prints whatever your script writes to stdout.

The JSON blob contains useful fields. For my purposes:

cwd, the current working directory
rate_limits.five_hour.used_percentage and resets_at
rate_limits.seven_day.used_percentage
context_window.used_percentage

That is all I needed.

How I worked with Claude on this one

This was the statusline-setup agent end to end. I’d tell the agent what I wanted, it would write the script, I’d look at the output in my terminal, then come back and say “now change this.” Four rounds total:

First pass: show 5h, 7d, context, cwd as percentages.
“Shorter. Show just the folder, not the full path. Can we use bars instead of percentages?”
“Move the folder to the front. Color the bars by severity.”
“Add the reset time for the 5-hour bar.”

I didn’t hand-edit the script at any point. Every change went through the agent. Not because I was trying to be pure about it, just because the iterations were fast enough that writing prose was quicker than diffing bash.

The stack

bash + jq + ANSI escape codes. That’s it.

The script lives at ~/.claude/statusline-command.sh. The settings.json entry points at it:

"statusLine": {
  "type": "command",
  "command": "bash /Users/YOURNAME/.claude/statusline-command.sh"
}

No install step, no build, no dependencies beyond jq (which most dev machines already have).

The bars

I wanted the progress bars to be visually distinct from each other so I could spot trouble at a glance. Claude’s first pass had them all in the same dim color, which was technically working but useless for scanning. That was round three of corrections.

The fix was severity coloring. The filled portion of each bar gets green, yellow, or red depending on how full it is. The empty portion stays dim gray.

bar_color() {
  pct="$1"
  int_pct=$(printf '%.0f' "$pct" 2>/dev/null || echo 0)
  if [ "$int_pct" -ge 81 ] 2>/dev/null; then
    printf '\033[0;31m'   # red
  elif [ "$int_pct" -ge 50 ] 2>/dev/null; then
    printf '\033[0;33m'   # yellow
  else
    printf '\033[0;32m'   # green
  fi
}

Green below 50, yellow 50 to 80, red above 80. So when I glance down and see two greens and a yellow, I’m fine. Two yellows and a red, I wrap up the current task before I lose the session.

Drawing a 10-slot bar in pure shell

The bar itself is 10 Unicode blocks, some filled, some empty. This function computes how many slots to fill, then paints them with ANSI colors:

make_bar() {
  pct="$1"
  filled=$(printf '%.0f' "$(echo "$pct * 10 / 100" | bc -l 2>/dev/null || echo 0)")
  [ "$filled" -gt 10 ] 2>/dev/null && filled=10
  [ "$filled" -lt 0 ] 2>/dev/null && filled=0
  color=$(bar_color "$pct")
  reset='\033[0m'
  dim='\033[2;37m'
  bar=""
  i=0
  while [ "$i" -lt "$filled" ]; do
    bar="${bar}${color}\xe2\x96\x88${reset}"
    i=$((i + 1))
  done
  while [ "$i" -lt 10 ]; do
    bar="${bar}${dim}\xe2\x96\x91${reset}"
    i=$((i + 1))
  done
  printf '['; printf "$bar"; printf ']'
}

\xe2\x96\x88 is the full block character, \xe2\x96\x91 is the light shade. Escape color, character, reset, repeat. The trailing reset on every character matters. If you skip them, a tmux resize or scrollback can bleed color into adjacent text.

The reset timestamp

The nice detail I didn’t realize I wanted until I saw the finished version: the 5-hour bar shows when it resets, not just how full it is.

The JSON gives you resets_at as a Unix timestamp. On macOS, date -r takes a timestamp directly:

five_reset_str=$(date -r "$five_resets" "+%-I:%M%p" 2>/dev/null \
  | tr '[:upper:]' '[:lower:]')
[ -n "$five_reset_str" ] && five_reset_str=" rst:${five_reset_str}"

%-I strips the leading zero so 03:45pm renders as 3:45pm. tr lowercases it so it reads closer to how I’d write the time in a note: 3:45pm rather than 3:45PM.

Now the 5h segment looks like 5h:[████████░░]82% rst:3:45pm. I can see both the cost and the clock.

Where Claude surprised me

The severity coloring was me saying “make the bars not all gray, use any colors that make sense” and the agent came back with the green/yellow/red thresholds on its own. I was expecting I’d have to define the ranges. Not complicated logic, but it picked reasonable cutoffs without me specifying them and I didn’t need to adjust after.

Where Claude fell short

The first version wrote out full paths for the working directory. I told it I wanted just the folder name. That was a one-line basename fix. Easy, but it’s the kind of thing “good default” might have caught without me asking.

The first version also had ASCII bars all in the same dim gray. Functional but not useful. I had to explicitly ask for color differentiation. On re-read, my original prompt did ask for visual bars but didn’t say anything about severity, so that’s fair. Still, “make the bars informative” would have been my one-shot prompt if I were writing it now.

It also wrote the code to extract rate_limits.five_hour.resets_at before confirming the field actually existed in the JSON payload. It was a plausible path, and it happened to be correct, but it was a guess. For a less obvious field I’d have wasted a round on a hallucinated schema.

The full Claude Code statusline bash script

If you’d rather read the bash yourself, save this as ~/.claude/statusline-command.sh:

#!/bin/sh
input=$(cat)

cwd=$(echo "$input" | jq -r '.cwd // .workspace.current_dir // empty')
ctx_used=$(echo "$input" | jq -r '.context_window.used_percentage // empty')
five_pct=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty')
five_resets=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // empty')
week_pct=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty')

bar_color() {
  pct="$1"
  int_pct=$(printf '%.0f' "$pct" 2>/dev/null || echo 0)
  if [ "$int_pct" -ge 81 ] 2>/dev/null; then
    printf '\033[0;31m'
  elif [ "$int_pct" -ge 50 ] 2>/dev/null; then
    printf '\033[0;33m'
  else
    printf '\033[0;32m'
  fi
}

make_bar() {
  pct="$1"
  filled=$(printf '%.0f' "$(echo "$pct * 10 / 100" | bc -l 2>/dev/null || echo 0)")
  [ "$filled" -gt 10 ] 2>/dev/null && filled=10
  [ "$filled" -lt 0 ] 2>/dev/null && filled=0
  color=$(bar_color "$pct")
  reset='\033[0m'
  dim='\033[2;37m'
  bar=""
  i=0
  while [ "$i" -lt "$filled" ]; do
    bar="${bar}${color}\xe2\x96\x88${reset}"
    i=$((i + 1))
  done
  while [ "$i" -lt 10 ]; do
    bar="${bar}${dim}\xe2\x96\x91${reset}"
    i=$((i + 1))
  done
  printf '['; printf "$bar"; printf ']'
}

parts=""

if [ -n "$cwd" ]; then
  folder=$(basename "$cwd")
  parts="${parts}$(printf '\033[0;36m%s\033[0m ' "$folder")"
fi

if [ -n "$five_pct" ]; then
  bar=$(make_bar "$five_pct")
  five_reset_str=""
  if [ -n "$five_resets" ]; then
    five_reset_str=$(date -r "$five_resets" "+%-I:%M%p" 2>/dev/null \
      | tr '[:upper:]' '[:lower:]')
    [ -n "$five_reset_str" ] && five_reset_str=" rst:${five_reset_str}"
  fi
  parts="${parts}$(printf '\033[0;33m5h:\033[0m%s%.0f%%%s ' "$bar" "$five_pct" "$five_reset_str")"
fi

if [ -n "$week_pct" ]; then
  bar=$(make_bar "$week_pct")
  parts="${parts}$(printf '\033[0;33m7d:\033[0m%s%.0f%% ' "$bar" "$week_pct")"
fi

if [ -n "$ctx_used" ]; then
  bar=$(make_bar "$ctx_used")
  parts="${parts}$(printf '\033[0;35mctx:\033[0m%s%.0f%%' "$bar" "$ctx_used")"
fi

printf '%s' "$parts"

Make it executable (chmod +x ~/.claude/statusline-command.sh), then add this to ~/.claude/settings.json:

"statusLine": {
  "type": "command",
  "command": "bash /Users/YOURNAME/.claude/statusline-command.sh"
}

Replace YOURNAME with your actual home directory. Restart Claude Code. Run a prompt. The statusline shows up after the first response, which is when the JSON starts carrying real usage numbers.

Styling tips

A few things I learned by iterating on this:

Label colors matter more than bar colors. I used cyan for the cwd, yellow for 5h and 7d labels, purple for ctx. When I glance down, the label colors are what tell me which segment I’m looking at. The bar colors just tell me severity.

Keep segments narrow. Ten-slot bars are small enough to fit four segments on one line in a typical terminal. I tried 20-slot bars at one point and they wrapped on my laptop screen.

Always reset after every ANSI escape. I’ve been burned by color bleeding into the rest of the terminal after a process crashes mid-write. The ${reset} after every character is paranoid but cheap.

Hide segments when the data isn’t there yet. The rate-limit numbers aren’t populated until Claude Code has made at least one API call in the session. If you print them unconditionally you get an ugly 5h:[░░░░░░░░░░] on a fresh start. The if [ -n ... ] guards handle that.

Where it is now

Running on my machine. I see it every prompt. It has already saved me from one 5h wall I didn’t notice coming. Low stakes, nice feature, took about an hour of back-and-forth to land.

What I’d do differently

Tell Claude the severity thresholds up front. I let the agent pick them and it happened to get it right, but on a different day I might have wanted different cutoffs and wasted a round correcting. Specifying “green under 50, yellow 50-80, red over 80” in the first prompt costs nothing.

Ask the agent to verify fields in the JSON before writing code. The resets_at field happened to exist. For a feature you’re actually shipping, the “does this field exist” check should happen before the “format it as a time” code. A one-line jq against a sample payload would have caught it.

Don’t wait to try it. I almost didn’t build this because it felt like yak-shaving. It took under an hour and changed how I pace work inside Claude Code. If you’ve never opened the statusLine key in your settings.json, that’s where to start.

Related: more devlogs and side projects.

I Built a Dead Simple App Because Claude Code Couldn't Hear Me

cadendeveloper@gmail.com (Travel Vient) — Wed, 15 Apr 2026 00:00:00 GMT

I use Claude Code through Bedrock at work. That version doesn’t give the AI access to your microphone, so the voice input that makes the native Claude desktop client fast just isn’t there. I like speaking to Claude more than typing. Over several months that small friction accumulated into something I actually wanted to fix.

The fix was obvious: an app that listens, transcribes, and puts the text on the clipboard. Switch to whatever terminal or text field you’re using, paste. One step in the middle instead of typing everything out.

What it does

Mic to Clipboard is one screen, one button. Tap the mic, speak, tap again. The transcript lands in your clipboard. You paste it wherever you want.

That’s the whole app. No accounts, no sync, no settings beyond a light/dark mode toggle. It runs on-device: Apple’s speech recognizer does the transcription locally so nothing leaves your phone.

The stack

React Native via Expo, because I wanted to ship to iOS without writing Swift. Two packages do all the real work:

expo-speech-recognition wraps Apple’s SFSpeechRecognizer API
expo-clipboard writes the final transcript to the system clipboard

Expo’s managed workflow meant I could build the whole thing without opening Xcode during development. I only touched Xcode when it was time to configure things for the App Store submission.

Continuous transcription

The interesting part of the core hook is how continuous speech recognition actually works. Apple’s recognizer fires result events repeatedly as it processes audio. Each result is either interim (still processing, may change) or final (committed). But when you speak in long sentences with natural pauses, you get multiple final results in a row, not one big one at the end.

So I keep a ref that accumulates the committed finals:

useSpeechRecognitionEvent("result", (event) => {
  const text = event.results[0]?.transcript ?? "";

  if (event.isFinal) {
    if (text.trim()) {
      accumulatedRef.current = accumulatedRef.current
        ? accumulatedRef.current + " " + text
        : text;
      setState((prev) => ({
        ...prev,
        transcript: accumulatedRef.current,
        interimTranscript: "",
      }));
    }
  } else {
    setState((prev) => ({
      ...prev,
      interimTranscript: text,
    }));
  }
});

The accumulatedRef is a plain ref rather than state because I don’t want re-renders every time it updates mid-sentence. State updates only happen on final results. When the session ends, the accumulated string is what gets written to the clipboard.

The display text that appears on screen combines both pieces: whatever is committed plus the in-flight interim, so you see words appearing as you speak:

return {
  ...state,
  toggle,
  displayText: state.interimTranscript
    ? (accumulatedRef.current
        ? accumulatedRef.current + " " + state.interimTranscript
        : state.interimTranscript)
    : state.transcript,
};

On-device vs. network fallback

Newer iPhones support fully on-device speech recognition. Older ones fall back to Apple’s servers. Rather than just picking one, the app checks at runtime and uses the right config:

const supportsOnDevice =
  await ExpoSpeechRecognitionModule.supportsOnDeviceRecognition();
const config = supportsOnDevice ? SPEECH_CONFIG : SPEECH_CONFIG_NETWORK;

ExpoSpeechRecognitionModule.start(config);

The two configs are identical except for requiresOnDeviceRecognition: true. On-device is preferred because nothing leaves the device, but requiring it on older hardware would just fail silently. The fallback handles it without any user-visible difference.

Silencing the `no-speech` error

If you tap the mic button and then don’t say anything, the recognizer fires an error event with code no-speech. I was initially treating that the same as real errors, which meant the UI would flash an error state every time someone changed their mind or accidentally tapped the button.

useSpeechRecognitionEvent("error", (event) => {
  if (event.error === "no-speech") {
    return;
  }
  // handle actual errors
});

Silence isn’t an error. Filtering it out means the button just returns to idle with no drama.

The hard part: App Store paperwork

The code took a weekend. Getting through App Store review took longer and was more tedious than I expected.

Apple’s privacy manifest system requires a structured XML declaration of which system APIs you use and why. expo-speech-recognition accesses the microphone, and apps using certain APIs need to explain themselves in a format Apple can parse. The permission strings in Info.plist also needed to be specific enough to pass review.

There was also the encryption declaration. Any app that uses HTTPS, even passively (every app does), technically uses encryption and needs to be flagged as non-exempt. It’s a paperwork step, not a security review, but a missing checkbox gets the submission bounced.

Screenshot requirements were the most mechanical part: specific pixel dimensions for iPhone 6.7” and 6.5” layouts, taken from simulators at exactly those resolutions. Three to five screens minimum. It’s a twenty-minute process once you know the sizes. Discovering them for the first time mid-submission is not ideal.

Where it is now

Live on the App Store. Works on iPhone and iPad. Apple automatically makes it available on Apple Silicon Macs via the “Designed for iPad” compatibility layer, which means zero extra work on my end.

I use it every day. I’ll draft a long Claude prompt on the walk to my desk, open the app, say it, and paste it into the terminal. Fast enough that it doesn’t break the flow.

What I’d do differently

Skip Mac Catalyst configuration. The automatic Mac compatibility through “Designed for iPad” covers everything I wanted. I spent time setting up Catalyst entitlements, sandbox configs, and Xcode targets that turned out to be unnecessary.

Take screenshots during development. I treated them as a final step and got stuck mid-submission setting up a simulator at the right resolution. They could have been done any time.

Budget a full day for App Store paperwork. The code was done in two days. Getting the privacy manifest, encryption declaration, permission strings, screenshots, and privacy policy all correct and in place took another full day. It’s not hard, just time-consuming, and you can’t skip it.

Related: Mic Clipboard and more side projects.

Building the Carry-On and Personal Item Size Checkers

cadendeveloper@gmail.com (Travel Vient) — Tue, 14 Apr 2026 00:00:00 GMT

Editor’s note (May 2026): This devlog predates Spirit Airlines’ May 2, 2026 shutdown. The Spirit size-checker page still exists as a historical reference, but Spirit no longer operates.

Last summer I watched a gate agent at Stansted pull a woman’s backpack out of her hand, drop it into a Ryanair sizer, and charge her €55 because it was half an inch tall in one dimension. The bag was “carry-on approved” according to the Amazon listing. She had measured it at home. The problem was that she had measured it against American Airlines limits, which is what every US-facing review compared against, and Ryanair is a different airline with different rules.

I went home and started a spreadsheet. A few weeks later the spreadsheet became a JSON file. A few weeks after that, it became two tools: the Carry-On Size Checker and the Personal Item Size Checker.

What they do

Both tools take the same input (length, width, height, in inches or centimeters) and compare your bag against the published baggage rules for 50 airlines worldwide. You see, at a glance, which airlines will accept the bag as a carry-on or as a personal item and which will send you to the fee counter.

You can filter by region (North America, Europe, Asia, etc.) or by category (Full-service, Low-cost, Ultra-low-cost) since what passes on Delta is not the same as what passes on Spirit. Every airline card also links to a detail page with the full baggage policy: checked bag fees, overweight surcharges, basic economy restrictions, gate-check risk, and the source URL for the data.

The stack

This one is boring on purpose. Static Astro 5 site, Tailwind v4, one big JSON file, a few TypeScript helpers, and vanilla JavaScript in the browser for filtering. No React, no API, no database, no server.

Every page is generated at build time. The bag fit check runs entirely client-side against data attributes baked into each airline card during the build. The whole thing deploys to Cloudflare Pages as static HTML and runs faster than any SaaS version of the same tool I tried.

The data lives in src/data/airlines/airlines.json, which is a 4,000-line structured file compiled from each airline’s official policy page and cross-referenced against secondary travel sources before publishing. Every airline entry includes carry-on dimensions in both inches and centimeters, personal item rules, checked bag fee structure, basic economy restrictions, and a sourceUrl pointing at the airline’s own published policy page. Every entry also has a lastVerified date. When I update a record I update the date. If the date is stale, I know to re-check.

The hard part: bag orientation

This is the detail that almost everyone building a similar tool gets wrong. Airline dimensions are published as length × width × height, but bags are not. A 22×14×9 carry-on measured one way is a 9×22×14 bag measured another way. If you compare them position-by-position you will tell someone their bag does not fit when it does.

The fix is to sort both the bag and the limit largest-to-smallest before comparing:

export function bagFitsPersonalItem(
  bag: Dimensions,
  unit: 'in' | 'cm',
  airline: Airline
): PersonalItemFit {
  const limit = unit === 'in' ? airline.personalItem.dimensionsIn : airline.personalItem.dimensionsCm;
  if (!airline.personalItem.allowed) return 'too-big';
  if (!limit) return 'under-seat-only';
  const b = [bag.length, bag.width, bag.height].sort((a, b) => b - a);
  const l = [limit.length, limit.width, limit.height].sort((a, b) => b - a);
  return b[0] <= l[0] && b[1] <= l[1] && b[2] <= l[2] ? 'fits' : 'too-big';
}

This also runs in the browser for the interactive filter. Same logic, data attributes on each card, no hydration framework needed:

const bagSorted = [bagCheck.l, bagCheck.w, bagCheck.h].sort((a, b) => b - a);
const limSorted = [limL, limW, limH].sort((a, b) => b - a);
const ok =
  bagSorted[0] <= limSorted[0] &&
  bagSorted[1] <= limSorted[1] &&
  bagSorted[2] <= limSorted[2];

It is an embarrassingly small amount of code for how much it matters. But it is the difference between a tool that gives you the right answer and a tool that misses a third of passing bags because the user entered them in a different order.

The “not published” problem

The other thing that bit me is that half of US airlines do not publish personal item dimensions. Delta, American, and United all say something like “must fit under the seat in front of you” and leave it at that. If I treat that as “no limit,” I am lying to users. If I treat it as “does not allow personal items,” I am also lying.

The schema has a three-state return for this reason:

export type PersonalItemFit = 'fits' | 'too-big' | 'under-seat-only';

And the data model lets a personal item be allowed: true with null dimensions:

"personalItem": {
  "allowed": true,
  "dimensionsIn": null,
  "dimensionsCm": null,
  "notes": "Must fit under the seat in front of you. No published dimensions, but purses, small backpacks, and laptop bags are accepted."
}

The UI shows an amber “Under-seat only” badge for these cases and links the user to the airline’s own policy page. It is not a satisfying answer, but it is an honest one, and it is better than pretending the airline has clear rules when it does not.

What went wrong

The original version of the tool supported 20 airlines and had a single dimensions schema. I thought that would be enough. It was not. Within a week of launching I had feedback asking about Wizz Air, TAP Portugal, LATAM, Qantas, and half a dozen Asian carriers. Each one had slightly different rules. TAP uses weight differently. Wizz Air has a “Priority” upgrade that changes the personal item size. Qantas varies by route. The schema grew to cover all of it, but the JSON file tripled in size and every addition meant another trip to the airline’s policy page to re-verify numbers I had already verified two months earlier.

The other thing that went wrong: I underestimated how often airlines change their rules. Delta changed checked bag fees from $35 to $45 halfway through the project. Spirit restructured personal item allowances. The data is only as good as the last verification date, and keeping 50 airlines current is more work than I budgeted for.

Where it is now

The tools have 50 airlines covered, grouped into 5 regions and 3 categories, with full checked bag fee estimation for US airlines. Each tool has its own page, each airline has its own detail page at /tools/carry-on-size/[slug]/, and the whole thing is indexed in the Astro sitemap. Every page ships JSON-LD structured data (FAQPage, CollectionPage, BreadcrumbList, ItemList) so Google and AI search engines can pull answers out of it.

Traffic has been better than expected. The personal item checker in particular gets picked up by “will my bag fit on Ryanair” and “Spirit personal item size” searches, which turn out to be very high-intent queries. People who are about to pay a $75 bag fee are motivated to click.

If you want to see the per-airline detail pages in action, the big US carriers are a good sample: JetBlue carry-on size, Delta carry-on size, United carry-on size, American Airlines carry-on size, and Southwest carry-on size. The budget carriers tell a more interesting story: Frontier, Ryanair, and Wizz Air all publish tighter limits and charge more when you miss them, which is exactly the scenario the tool was built to prevent. Spirit was the strictest US example until it shut down in May 2026; its page is kept for reference.

What I would do differently

First, I would start with the full schema. The rewrite from a 3-field dimension object to a 20-field airline spec was avoidable. If I had spent an extra hour at the start looking at five airline policies side by side, I would have seen the variance and designed for it.

Second, I would build the verification workflow before the data file got big. Right now updating an airline means finding it in 4,000 lines of JSON, editing, updating lastVerified, and committing. A simple CLI that prompts me through the fields for one airline, validates against a schema, and writes the JSON would have saved hours. It is on the list.

Third, I would not have built two separate tools at first. Carry-on and personal item share almost all their logic. The split made sense for SEO because people search for them as distinct things, but the shared code is now duplicated across two index pages and two detail templates. A single generic “bag fit” tool with two SEO landing pages pointing at it would have been cleaner.

Still, both tools work, both are free, and nobody has emailed me to say I gave them wrong dimensions. For a side project built from a grudge at a Ryanair gate, I will take it.

I Built a Media Kit Generator Because a Creator Asked Me To

cadendeveloper@gmail.com (Travel Vient) — Mon, 13 Apr 2026 00:00:00 GMT

Update (May 2026): CreatorKit has been shelved. Analytics showed almost no usage, and the tool drifts pretty far from the travel focus of the rest of the site. The build story below is left up as a devlog. The hosted app may or may not still be running.

A creator I know needed a media kit to send to brands. The kind of one-pager with your stats, your audience, your collab rates. Every tool she found either wanted $15/month or required signing up and handing over her social accounts.

I said I could probably build one over a weekend. That turned out to be half true.

What CreatorKit actually does

You fill out a six-step form: basic info, platform stats, audience demographics, content highlights, collaboration types, and template/color preferences. Then you hit download and get an A4 PDF that looks like something a designer made.

No signup. No account. No monthly fee. You get five downloads per day and that’s it.

The YouTube integration is the one clever bit. Paste your @handle and it auto-fetches your subscriber count, total views, and video count through the YouTube Data API. Everything else is manual entry, which honestly is fine for something you update once a quarter.

The stack

Next.js 16 on Cloudflare Workers via OpenNext. I went with Next because the Travel Vient ecosystem already runs on it, and Cloudflare because KV namespaces give me rate limiting and YouTube API caching for free (well, pennies).

jsPDF for client-side PDF generation. This was the big decision. I could have used Puppeteer on a server to render HTML to PDF, but that means spinning up a headless browser per request. Client-side means zero server cost for the actual PDF rendering. The user’s browser does all the work.

Tailwind v4 for styling, Zod for validation schemas (more on that later), and Cloudflare KV for rate limiting with daily resets.

The hard part: drawing a PDF by hand

jsPDF gives you a blank canvas and a coordinate system measured in millimeters. That’s it. No flexbox. No grid. No text-align: center that actually works how you’d expect. You’re calling doc.text() with exact x/y coordinates and hoping things line up.

Every element on the page needs a helper function that returns the Y position after it renders, so the next element knows where to start:

export function drawText(
  doc: jsPDF,
  text: string,
  x: number,
  y: number,
  options: DrawTextOptions = {}
): number {
  const { fontSize = 10, fontStyle = "normal", color = "#000000", align = "left", maxWidth } = options;

  const [r, g, b] = hexToRgb(color);
  doc.setTextColor(r, g, b);
  doc.setFontSize(fontSize);
  doc.setFont("helvetica", fontStyle);

  if (maxWidth) {
    const lines = doc.splitTextToSize(text, maxWidth);
    doc.text(lines, x, y, { align });
    return y + lines.length * fontSize * 0.4;
  }

  doc.text(text, x, y, { align });
  return y + fontSize * 0.4;
}

That fontSize * 0.4 magic number? That’s the approximate line height in millimeters. I arrived at it through trial and error, printing PDFs and holding them up to a ruler. There is no getLineHeight() in jsPDF. You just guess until it looks right.

The platform stats section was especially painful because it needs to handle 1 to 6+ platforms in a responsive grid:

const colCount = Math.min(data.platforms.length, 3);
const colWidth = CONTENT_WIDTH / colCount;
const boxHeight = 28;

data.platforms.forEach((platform, i) => {
  const col = i % colCount;
  const row = Math.floor(i / colCount);
  const bx = MARGIN + col * colWidth + 1;
  const by = y + row * (boxHeight + 3);
  // ... draw each stat box
});

Three columns max, overflow to new rows. It’s the kind of layout that CSS grid handles in one line. In jsPDF, you’re computing column offsets and row indices by hand.

Images had their own problems

Every image the user uploads gets resized client-side before it touches the PDF. I used OffscreenCanvas to keep the main thread clear, then compress to JPEG at 85% quality:

export async function processImageFile(file: File): Promise<ImageProcessResult> {
  const bitmap = await createImageBitmap(file);
  const { width, height } = getScaledDimensions(bitmap.width, bitmap.height, MAX_DIMENSION);

  const canvas = new OffscreenCanvas(width, height);
  const ctx = canvas.getContext("2d");
  if (!ctx) throw new Error("Failed to get canvas context");

  ctx.drawImage(bitmap, 0, 0, width, height);
  bitmap.close();

  const blob = await canvas.convertToBlob({ type: "image/jpeg", quality: 0.85 });
  const base64 = await blobToBase64(blob);
  return { base64, width, height };
}

Without this step, a 4MB profile photo would bloat the PDF to unusable sizes. Capping at 400x400 and 85% JPEG keeps the final PDF under a megabyte in most cases.

What went wrong

I planned three templates: minimal, bold, and pastel. I finished one.

The minimal template is about 290 lines of coordinate math. Every section (header, bio, stats, audience, highlights, collaboration types, partners, contact footer) needs its own layout logic. And every template needs to reimplement all of that with different spacing, colors, backgrounds, and typography.

The bold template has a dark background, which means every text color needs to flip. The pastel template uses rounded containers everywhere, which means more coordinate math for border radii. I got about 60% through bold before I realized I was going to spend more time on templates than I had on the entire rest of the app.

So right now, only minimal is unlocked. Bold and pastel are visible in the template picker but greyed out.

The other thing that went sideways: I built full Zod validation schemas for the form data and then never wired them into the UI. The schemas exist in validation.ts, fully typed, fully correct, completely unused. The form just dispatches raw field updates through a reducer. It works fine, but there’s zero client-side validation beyond “is this field empty.”

Where it is now

Live at travelvient.com/tools/media-kit. The YouTube auto-fetch works well. The minimal template produces a genuinely nice-looking PDF. Rate limiting keeps costs near zero, since the YouTube API calls get cached in KV for 24 hours and each IP gets 10 lookups per day.

The live preview panel updates in real-time as you fill out the form, scaled to 47% of A4 size. It’s built with React components that mirror the PDF layout, which is its own maintenance headache since any PDF change needs a matching preview change.

What I’d do differently

Talk to more creators first. I built this because one person asked for it. I should have talked to ten more before writing a line of code. Does the six-step form collect too much? Too little? Are the collaboration type categories even right? I don’t actually know if this tool solves a real pain point at scale, or just for one person.

Use HTML-to-PDF instead of jsPDF. Something like Puppeteer or Playwright rendering a styled HTML page would let me write templates in CSS instead of coordinate math. Yes, it needs a server. But the developer experience of drawText(doc, text, 43.5, 127, { fontSize: 7 }) is genuinely bad, and it would have saved days on the template work.

Ship one template and move on faster. I spent time building the template picker UI, the color customization, the locked template states, all before I had even one template fully working. Should have shipped minimal alone, without the template system, and added the abstraction only when template #2 was actually ready.

Related: see CreatorKit.

I Built an API Cost Tracker and Then Couldn't Ship It

cadendeveloper@gmail.com (Travel Vient) — Sun, 12 Apr 2026 00:00:00 GMT

I opened my Anthropic dashboard one morning and genuinely flinched. I’d been building with Claude Code pretty heavily that week and my bill was way higher than expected. Not catastrophic, but enough to make me think: why am I always surprised by this number?

The problem got worse when I started using OpenAI’s APIs too. Now I had two dashboards, two billing pages, two sets of numbers I needed to mentally combine to understand what I was actually spending. So I did what any developer does when mildly annoyed. I built something.

What BurnRate Does

BurnRate is a unified API cost dashboard. You paste in your Anthropic and OpenAI admin keys, and it gives you one view of everything: daily spend trends, per-model breakdowns (how much went to Opus vs. Sonnet, GPT-4o vs. o3), projected monthly costs based on your actual burn rate, and budget warnings when you’re getting close to a limit you set.

The whole thing runs on Next.js 16 with Cloudflare Workers, and the core design principle was “zero persistence.” No database, no accounts, no server-side key storage. Keys live in your browser and get sent to edge functions only when fetching data.

The Provider Pattern

The most satisfying part of the architecture was the provider abstraction. Anthropic and OpenAI have completely different billing APIs, different pagination schemes, different data shapes. I needed a clean way to normalize all of that.

export interface UsageProvider {
  id: "anthropic" | "openai";
  name: string;
  keyPrefix: string;
  validateKey(key: string): Promise<{ valid: boolean; error?: string }>;
  fetchUsage(key: string, startDate: Date, endDate: Date): Promise<ProviderUsage>;
}

Each provider implements this interface, and the rest of the app doesn’t care which one it’s talking to. Adding a new provider (Google AI, Mistral, whatever) would just mean creating a new file and registering it. The dashboard code stays untouched.

Dealing with Two Very Different APIs

Anthropic uses cursor-based pagination with a next_page token. OpenAI uses page numbers. Their cost data comes back in different formats, different field names, different granularities. I wrote a generic pagination helper to smooth this over:

async function fetchAllPages<T>(
  baseUrl: string,
  params: URLSearchParams,
  headers: HeadersInit,
  extractData: (json: { data: T[]; has_more: boolean; next_page: string | null }) => T[]
): Promise<T[]> {
  const allData: T[] = [];
  let page: string | null = null;

  do {
    const urlParams = new URLSearchParams(params);
    if (page) urlParams.set("page", page);

    const res = await fetch(`${baseUrl}?${urlParams.toString()}`, { headers });
    if (!res.ok) throw new Error(`API error (${res.status}): ${await res.text()}`);

    const json = await res.json();
    allData.push(...extractData(json));
    page = json.has_more ? json.next_page : null;
  } while (page);

  return allData;
}

Then both providers fetch their cost and usage reports in parallel with Promise.all, which cuts the latency roughly in half since we’re hitting two endpoints per provider.

The Key Security Problem

This is where the whole thing fell apart. And honestly, it’s not a bug or a technical limitation. It’s a fundamental design problem.

Both Anthropic and OpenAI require admin-level API keys to access billing and usage data. These aren’t read-only keys. They’re the same keys that can create API requests, manage organization settings, and do basically anything on your account.

I designed BurnRate to be “zero trust” from the start. Keys stored in sessionStorage by default, cleared when you close the tab. Optional localStorage if you check “Remember me.” Keys never persisted server-side.

const saveKeys = useCallback(
  (newKeys: ProviderKeys, shouldRemember: boolean) => {
    // Clear from both storages first
    localStorage.removeItem(STORAGE_KEY);
    sessionStorage.removeItem(STORAGE_KEY);

    // Save to the appropriate storage
    const storage = shouldRemember ? localStorage : sessionStorage;
    storage.setItem(STORAGE_KEY, JSON.stringify(newKeys));
    localStorage.setItem(REMEMBER_KEY, shouldRemember.toString());
  },
  []
);

But here’s the thing. Even with all that care, the keys still have to travel through my edge function to reach the provider APIs. That means they pass through infrastructure I control. And even though I’d never log them or store them, users have no way to verify that. I’m asking people to trust me with keys that have full admin access to their AI accounts.

I couldn’t ship that in good conscience.

What the APIs Didn’t Give Me

Beyond the key problem, the provider APIs had their own limitations. Neither Anthropic nor OpenAI gives you everything you’d want for a proper cost dashboard out of the box. Some data is bucketed in ways that make fine-grained analysis tricky. Token counts and cost amounts come from separate endpoints, so you have to merge them yourself and hope the model names match up:

export function mergeDashboardData(providers: ProviderUsage[]): DashboardData {
  const totalCost = providers.reduce((sum, p) => sum + p.totalCost, 0);

  const dailyMap = new Map<string, number>();
  for (const provider of providers) {
    for (const dc of provider.dailyCosts) {
      dailyMap.set(dc.date, (dailyMap.get(dc.date) || 0) + dc.cost);
    }
  }

  // Burn rate only counts days with actual usage
  const daysWithData = dailyCosts.filter((d) => d.cost > 0).length;
  const burnRate = daysWithData > 0 ? totalCost / daysWithData : 0;
  const projectedMonthlyCost = burnRate * 30;

  return { providers, totalCost, dailyCosts, burnRate, projectedMonthlyCost, modelBreakdown };
}

The burn rate calculation was a small decision that mattered. If you only use the API on weekdays, averaging across all 30 days would undercount your actual daily spend. So I only count days where there’s real usage, then project from there. It’s a small thing, but it’s the difference between a number you trust and one you don’t.

Graceful Degradation

One pattern I’m glad I built in: partial failure handling. If your Anthropic key works but your OpenAI key is expired, you still see your Anthropic data. The dashboard renders what it can and shows a warning for what failed.

const results = await Promise.allSettled(fetches);

results.forEach((result, index) => {
  if (result.status === "fulfilled") {
    providers.push(result.value);
  } else {
    errors.push({
      provider: providerName,
      error: result.reason?.message || "Unknown error",
    });
  }
});

Promise.allSettled instead of Promise.all was the key choice here. One bad key shouldn’t nuke the whole dashboard.

Where It Stands Now

BurnRate is on the back burner. The code works. The dashboard looks good. The architecture is clean. But I can’t ask people to hand over admin keys to a web app, and the providers don’t offer read-only billing scopes that would make this safe.

If Anthropic or OpenAI ever ship scoped API keys with read-only billing access, I’ll dust this off in a heartbeat. The provider pattern means I could add that support in an afternoon.

What I’d Do Differently

The honest answer is that I’d build a real backend with proper encrypted key storage, server-side sessions, and all the infrastructure that comes with handling sensitive credentials. I avoided that because I wanted to keep things simple and minimize risk. No database, no encryption keys to manage, no breach surface.

But it turns out that’s the only real way to accomplish what BurnRate is trying to do. You can’t build a tool that needs admin API keys and also avoid the responsibility of securing them. The “keys stay in your browser” approach felt clever, but the keys still transit through server infrastructure on every request. The risk doesn’t disappear just because you don’t persist it to disk.

For now, I don’t want to take on that responsibility for other people’s keys. Maybe that changes. Maybe the providers give us better scoping. Either way, BurnRate taught me that sometimes the hardest part of shipping isn’t the code. It’s deciding whether you should.

Related: side projects and more devlogs.

I Built an SEO Scanner That Actually Checks if AI Can Find You

cadendeveloper@gmail.com (Travel Vient) — Sat, 11 Apr 2026 00:00:00 GMT

I kept running Lighthouse on my sites and getting green scores across the board. Great. But then I’d ask ChatGPT about one of my projects and get nothing. Perplexity didn’t know it existed. My SEO was fine. My AEO was invisible.

Lighthouse is a great tool, but it was built for a world where Google was the only game in town. It doesn’t check if your robots.txt blocks GPTBot. It doesn’t care about llms.txt. It has no concept of whether your content is structured for answer engines to extract and cite.

So I built ShipReady, a scanner that audits your site across seven categories, scores them with letter grades, and generates a “fix all” prompt you can paste directly into Claude or Cursor.

What It Does

You give it a URL. It fetches the page, follows redirects, grabs robots.txt and sitemap.xml and llms.txt in parallel, then runs 35+ checks across seven weighted categories:

Meta & Head (23%) - title, description, charset, viewport, canonical
Discoverability (19%) - HTTPS, robots.txt, sitemap, noindex detection
On-Page Structure (19%) - heading hierarchy, alt text, internal links
Social Sharing (14%) - Open Graph, Twitter Cards
Performance (9%) - render-blocking scripts, compression, modern image formats
Structured Data (8%) - JSON-LD validation, schema type suggestions
Answer Engine Optimization (8%) - AI crawler access, llms.txt, question headings, speakable schema

The weighting is opinionated. Meta and head matter more than performance for discoverability. AEO is weighted lower because it’s newer, but it’s the category most tools completely ignore.

The killer feature is the fix prompt. Every failed check generates a code snippet, and ShipReady combines them into a single markdown prompt with critical issues, warnings, and guidelines. You copy it, paste it into your AI coding tool, and the fixes get applied.

The Stack

Astro 5 with a Cloudflare Workers adapter. The whole thing runs on the edge. No origin server, no cold starts worth worrying about, and the rate limiting uses Cloudflare KV with a one-hour TTL.

The interesting architectural choice was going fully server-side for the scanning. The API endpoint receives a URL, does all the fetching and parsing on the Worker, and returns a scored JSON result. The frontend is just a form and a renderer.

const [mainResponse, externalData] = await Promise.all([
  fetchFollowingRedirects(targetUrl),
  fetchExternalResources(validation.url),
]);

const parsedData = await parseHTML(mainResponse, finalUrl);
let categories = runAllChecks(parsedData, externalData);
categories = scoreCategories(categories);

Everything that can run in parallel does. The main page fetch and external resource fetch (robots.txt, sitemap, llms.txt) happen concurrently. The external resources use Promise.allSettled so a missing sitemap doesn’t tank the whole scan.

The Hard Part: Parsing HTML Without a DOM

Cloudflare Workers have tight memory constraints. I couldn’t pull in jsdom or cheerio. So the entire HTML parser is regex-based. Every meta tag, heading, image, script, and anchor gets extracted with handwritten regex patterns.

function getAttr(tag: string, attr: string): string | null {
  const re = new RegExp(`${attr}\\s*=\\s*(?:"([^"]*)"|'([^']*)'|([^\\s>]+))`, 'i');
  const m = tag.match(re);
  if (!m) return null;
  return decodeHtmlEntities(m[1] ?? m[2] ?? m[3]);
}

This little function handles double-quoted, single-quoted, and unquoted attribute values, then decodes HTML entities. It’s called hundreds of times per scan. Every tag type gets its own regex loop over the HTML string, and the parser splits head from body so script detection can tell whether a <script> tag is render-blocking or not.

It works. It’s fast. But writing regex to parse HTML is one of those things where you know you’re technically doing it wrong and you do it anyway because the constraints demand it.

The False Positives

The first version flagged basically every Cloudflare-hosted site for missing text compression. That was fun.

The problem: Cloudflare Workers auto-decompress fetch responses. When ShipReady fetched a page, the content-encoding header was already stripped. The server was compressing, but the scanner couldn’t see it.

const contentEncoding = data.responseHeaders['content-encoding'];
const vary = data.responseHeaders['vary'] || '';
const hasCompression =
  (contentEncoding && (contentEncoding.includes('gzip') || contentEncoding.includes('br'))) ||
  vary.toLowerCase().includes('accept-encoding');

The fix was checking the Vary: Accept-Encoding header as a secondary signal. If the server varies its response based on encoding, it’s compressing. Not perfect, but it eliminated the false positives.

There was another one with type="module" scripts. The original code flagged any script in the <head> without async or defer as render-blocking. But ES modules are deferred by spec. Every modern Astro and Vite site ships module scripts, so every modern site was getting dinged for something that isn’t actually a problem.

The AEO Category

This is the part I’m most interested in. Traditional SEO tools don’t touch this. The AEO checks look at eight things:

Whether your robots.txt blocks AI crawlers (GPTBot, ClaudeBot, PerplexityBot, etc.)
Whether you have an llms.txt file
Whether your meta description uses generic filler language
Whether your H1 is descriptive or just “Home”
Whether you have FAQ/HowTo schema markup
Whether your H2/H3 headings are phrased as questions
Whether you have enough content depth for citation
Whether you have speakable schema for voice assistants

The AI crawler detection parses robots.txt line by line, tracking user-agent blocks and matching against a list of known crawlers:

const AI_CRAWLERS = [
  'GPTBot', 'ChatGPT-User', 'ClaudeBot', 'Claude-Web',
  'PerplexityBot', 'Bytespider', 'Google-Extended', 'Applebot-Extended',
];

It’s surprising how many sites block all of these by default. Some hosting platforms and CMS plugins add blanket AI crawler blocks without telling you. Your content is invisible to answer engines and you don’t even know it.

Where It Is Now

ShipReady is live at travelvient.com/tools/seo-check. It’s free, rate-limited to 10 scans per hour per IP, and the source is on GitHub.

The scoring uses a weighted system where each check has a weight of 1-3, warnings count for half their weight, and categories are weighted by importance. An A is 90+, F is below 60.

What I’d Do Differently

Lean harder into AEO. Right now it’s 8% of the overall score. That felt right when I was trying to balance against established SEO fundamentals, but honestly, the SEO checks are table stakes at this point. Everyone has a meta description. Not everyone has an llms.txt or question-style headings. The AEO category is the unique value here and it should probably carry more weight.

Get more people using it. I built this for my own sites, but the false positive bugs proved I need a wider range of test cases. Different hosting platforms, different frameworks, different CMS setups. The Cloudflare compression bug only showed up because I was scanning Cloudflare-hosted sites. There are probably similar platform-specific quirks I haven’t hit yet.

More actionable fix prompts. The current prompts are good but generic. If I could detect the framework (Astro vs Next vs plain HTML) and tailor the fix snippets to that framework’s conventions, the copy-paste experience would be much better.

I Built an AI Trading Bot That Watches Trump's Truth Social Posts

cadendeveloper@gmail.com (Travel Vient) — Sun, 05 Apr 2026 00:00:00 GMT

It started the way these things always do. I was watching the market one afternoon and saw a stock move right after a Truth Social post. Not a subtle drift, either. A real move. And I thought: what if I could catch that automatically?

Not in a “get rich quick” way. More like a genuine curiosity question. Could an AI read a social media post, figure out which sectors it might affect, and place a trade before the market fully priced it in? I wanted to test the idea. So I built a bot to find out.

What it does

The bot monitors Trump’s Truth Social posts via an RSS feed, sends each post to Claude for sentiment analysis, runs the result through a 9-layer risk management system, and if everything checks out, executes trades through Alpaca’s API. The whole pipeline runs in a loop, polling every 30 seconds.

Claude reads the post and returns a structured analysis: is this market-relevant? What’s the sentiment? Which sectors are affected? Should we buy, sell, or hold? The response maps to specific ETFs across 19 sectors, from technology (XLK) to defense (ITA) to crypto (BITO). The full source is on GitHub if you want to poke around.

If the market is closed when a post comes in, the analysis gets queued and the trades execute when the market opens.

The stack

Python was the obvious choice here. The trading ecosystem in Python is mature, and Alpaca’s SDK (alpaca-py) made the brokerage integration straightforward. Anthropic’s SDK handles the Claude calls. SQLite stores the audit trail because I wanted every decision logged without needing to spin up a database server.

The whole thing runs in Docker. One container, one docker-compose up -d, and it’s watching.

I used Pydantic for config management and data validation. Every environment variable, every risk parameter, every API response gets validated before anything touches real money. Structlog handles logging with enough context to trace any trade back to the original post that triggered it.

The prompt that drives the whole thing

Getting Claude to return consistent, actionable analysis was the core challenge. The system prompt has to be specific enough to produce structured JSON every time, but flexible enough to handle the unpredictable nature of political social media posts.

SYSTEM_PROMPT = f"""You are a financial analyst AI. Your job is to analyze social media posts
from the President of the United States and determine their potential impact on financial markets.

You must evaluate each post and return a structured analysis. Be conservative in your assessments.
Only mark posts as relevant if they clearly relate to economic policy, trade, specific industries,
regulations, international relations affecting markets, or similar market-moving topics.

Posts about personal matters, birthdays, endorsements of non-market candidates, or general
political commentary without clear economic implications should be marked as NOT relevant.
...
Be specific about which sectors are affected. If the impact is broad/unclear, use "broad_market".
Only suggest "buy" or "sell" when you have reasonable confidence. Default to "hold" when uncertain."""

That “default to hold when uncertain” line does a lot of heavy lifting. Without it, Claude tends to find market relevance in everything.

Nine ways to say no

The risk management system was something I was genuinely proud of. Before any trade executes, it has to pass through nine sequential checks. Fail any one of them and the trade gets rejected.

def evaluate(self, analysis, post_id, portfolio_value, current_positions):
    if analysis.confidence < settings.confidence_threshold:
        return []
    if not analysis.is_relevant:
        return []
    if analysis.direction == "hold":
        return []
    if self.last_trade_time:
        elapsed = (datetime.now() - self.last_trade_time).total_seconds()
        if elapsed < settings.trade_cooldown_seconds:
            return []
    if current_positions >= settings.max_open_positions:
        return []
    trades_today = self.db.get_trades_today()
    if self._daily_loss_exceeded(trades_today, portfolio_value):
        return []

Confidence threshold, relevance check, direction check, cooldown timer, position limits, daily loss limit, equity floor, buying power buffer, and short exposure cap. Short positions get extra scrutiny: 3% of portfolio max per position versus 5% for longs, tighter stop losses (2% vs 3%), and a 15% cap on total short exposure.

Every rejection gets logged with the specific reason. I wanted to be able to look back and understand exactly why a trade didn’t happen.

Gap protection

One thing that kept me up at night was gap risk. What happens when a post drops at 8pm, the bot queues a trade, and by the time the market opens, the price has already gapped way past where the stop loss should have been?

def check_gap_positions(self, db):
    positions = self.client.get_all_positions()
    closed = []
    multiplier = settings.gap_protection_multiplier

    for position in positions:
        entry_price = float(position.avg_entry_price)
        current_price = float(position.current_price)
        gap_threshold = stop_pct * multiplier

        if is_long and current_price <= entry_price * (1 - gap_threshold):
            self.client.close_position(symbol_or_asset_id=symbol)
            closed.append(symbol)
    return closed

The gap protection runs every tick during market hours. If a position has moved 1.5x past its stop loss percentage, it force-closes the position immediately. It’s a safety net for the scenario where Alpaca’s bracket order stops haven’t triggered because the price jumped right past them.

What went wrong

Paper trading worked beautifully. Claude’s analysis was often right. The sector mapping made sense. The risk system caught bad trades. On paper, the strategy was profitable.

Then I turned on real money and learned a painful lesson about latency.

The problem is the pipeline. The RSS feed updates every 30 seconds or so. Then Claude needs a few seconds to analyze the post. Then the trade needs to submit and fill. By the time all of that happens, the market has already moved. The people who profit from these posts are the ones who see them in real time, not 30-45 seconds later.

Paper trading doesn’t punish you for this. Paper fills happen at the price you request. Real markets don’t work that way. The slippage between what I expected to pay and what I actually paid ate into every trade. A move that looked like a 2% gain on paper turned into a 0.5% gain or even a loss in practice.

The analysis was often correct. Claude would correctly identify that a post about tariffs was bearish for emerging markets, and EEM would indeed drop. But by the time my order filled, the easy money was already gone.

Where it is now

The bot still runs on paper trading. It’s a genuinely interesting system for studying how social media sentiment translates to market movements. The SQLite database has become a decent dataset for analyzing which types of posts actually move markets and which ones are noise.

As a real trading system, it needs a faster data source to be viable. The strategy itself isn’t broken. The execution speed is.

What I’d do differently

Ditch the RSS feed entirely. RSS was convenient but it’s fundamentally too slow for this use case. Some kind of direct web scraping or websocket connection to Truth Social would cut the detection time from 30+ seconds to near-instant. That alone might make the difference between profitable and not.

Pre-build analysis patterns. Claude is smart, but it’s also slow relative to market speed. If I could build a pattern library from historical posts (tariff mentions = short EEM, deregulation mentions = long XLF), I could skip the API call entirely for common post types and only use Claude for genuinely novel content.

Start with limit orders instead of market orders. Market orders during volatile moments guarantee bad fills. Limit orders might mean some trades don’t execute, but the ones that do would be at prices that actually make the strategy work.

The core idea, using AI to parse social media for market signals, isn’t wrong. The execution just needs to be measured in milliseconds, not seconds. And that’s a fundamentally different engineering problem than the one I solved.

Related: more dev experiments and more devlogs.

Building PackSmart: An AI Packing List With Weather

cadendeveloper@gmail.com (Travel Vient) — Sat, 04 Apr 2026 00:00:00 GMT

After launching Roamly, I wanted to build out more travel tools under the Travel Vient umbrella. Not everything needs to be a full SaaS product with auth and billing. Sometimes you just need a simple, useful thing that solves one problem well. PackSmart came from that mindset: a free packing list generator that uses AI and real weather data to tell you exactly what to bring on your trip.

What it does

You punch in your destination, travel dates, trip type, luggage size, and planned activities. PackSmart geocodes the destination, pulls weather data for those exact dates, then feeds everything to Claude Haiku to generate a personalized packing list. The list is categorized, quantity-adjusted for your trip length, and comes with destination-specific travel tips.

You can check items off as you pack, and it saves your progress to localStorage so you can come back later. No account needed, no data stored on a server. Try it out at PackSmart.

The stack

Next.js 16 with App Router, deployed to Cloudflare Workers via OpenNext.js. React 19, Tailwind v4, shadcn/ui components. Claude Haiku 4.5 for the AI generation. Open-Meteo for weather data (free, no API key required). Cloudflare KV for distributed rate limiting.

I went with the same Next.js-on-Workers setup as Roamly because I already had the deployment pipeline figured out. For a tool like this, the edge deployment actually matters. The generate endpoint calls three APIs in sequence (geocoding, weather, Claude), so being physically closer to the user shaves real time off the round trip.

Open-Meteo was a great find. Free, no auth, solid data. The catch is that their forecast API only goes 16 days out.

The weather problem

Most packing list generators ignore weather entirely or ask you to describe it yourself. I wanted real data. But Open-Meteo’s forecast horizon is 16 days. If someone’s planning a trip three months from now, I can’t get a forecast.

The solution: a hybrid approach that blends real forecasts with historical data from the same dates last year.

export async function getWeather(
  lat: number, lng: number,
  startDate: string, endDate: string
): Promise<WeatherData> {
  const today = new Date();
  const start = new Date(startDate);
  const daysUntilStart = differenceInDays(start, today);

  if (daysUntilStart <= FORECAST_HORIZON_DAYS) {
    const forecastEnd = new Date(today);
    forecastEnd.setDate(forecastEnd.getDate() + FORECAST_HORIZON_DAYS);
    const end = new Date(endDate);

    if (end <= forecastEnd) {
      const data = await fetchForecast(lat, lng, startDate, endDate);
      return { ...parseResponse(data), isHistorical: false };
    }

    // Trip spans past forecast horizon, blend both sources
    const forecastEndStr = format(forecastEnd, "yyyy-MM-dd");
    const [forecastData, historicalData] = await Promise.all([
      fetchForecast(lat, lng, startDate, forecastEndStr),
      fetchHistorical(lat, lng, forecastEndStr, endDate),
    ]);

    const forecast = parseResponse(forecastData);
    const historical = parseResponse(historicalData);

    return {
      temperatureMin: [...forecast.temperatureMin, ...historical.temperatureMin],
      temperatureMax: [...forecast.temperatureMax, ...historical.temperatureMax],
      precipitationProbability: [
        ...forecast.precipitationProbability,
        ...historical.precipitationProbability,
      ],
      weatherCode: [...forecast.weatherCode, ...historical.weatherCode],
      isHistorical: true,
    };
  }

  // Beyond forecast range, use last year's data
  const data = await fetchHistorical(lat, lng, startDate, endDate);
  return { ...parseResponse(data), isHistorical: true };
}

Three paths: if the trip is within 16 days, use the real forecast. If the trip starts soon but extends past the horizon, blend forecast and historical data in parallel. If the trip is months away, pull last year’s weather for the same dates. The UI flags when historical data is being used so people know it’s an estimate.

The hard part: making Claude return clean JSON

This is where most of my time went. Claude Haiku is fast and cheap, which makes it great for a free tool. But getting consistent, parseable JSON out of any LLM is a battle.

The system prompt is explicit about output format. No markdown, no explanation, just JSON matching a specific schema. And yet.

// Strip markdown code fences if the model wraps the JSON
let jsonText = textBlock.text.trim();
if (jsonText.startsWith("```")) {
  jsonText = jsonText
    .replace(/^```(?:json)?\s*\n?/, "")
    .replace(/\n?```\s*$/, "");
}

// Fix common JSON issues from LLMs: trailing commas before } or ]
jsonText = jsonText.replace(/,\s*([}\]])/g, "$1");

Even with clear instructions, models will occasionally wrap their output in markdown code fences or drop trailing commas into arrays. These two lines handle the most common failures. After that, the response goes through Zod validation to make sure the structure matches what the frontend expects.

I also sanitize user inputs before they hit the prompt. Destination names are user-provided text that gets interpolated into the prompt, so stripping special characters is a basic defense against prompt injection:

function sanitizeInput(text: string): string {
  return text.replace(/[{}<>|\\`]/g, "").trim();
}

What happens when the AI fails

Sometimes the API is slow, sometimes it returns garbage, sometimes it’s just down. I didn’t want users staring at an error screen, so there’s a deterministic fallback generator that builds a reasonable packing list from templates:

const fallbackList = generateFallbackList(
  data.tripType,
  data.luggageType,
  data.activities,
  data.travelers
);

// Use real weather summary if we have weather data
if (weather.temperatureMax.length > 0) {
  const { formatWeatherSummary } = await import("@/lib/weather");
  fallbackList.weatherSummary = formatWeatherSummary(weather);
}

return NextResponse.json({
  ...fallbackList,
  fallback: true,
});

The fallback doesn’t count against the rate limit (3 lists per day per IP). If Claude fails, that’s not the user’s fault. The fallback also still uses real weather data if geocoding succeeded, so even the backup list is somewhat personalized.

Rate limiting on the edge

Since this is a free tool hitting a paid API, rate limiting is essential. Cloudflare KV makes this surprisingly clean for a serverless setup:

export async function incrementRateLimit(
  ip: string, kv: KVNamespace
): Promise<void> {
  const key = `rate:${ip}`;
  const entry = await kv.get<RateLimitEntry>(key, "json");
  const now = new Date();

  if (!entry || new Date(entry.resetAt) < now) {
    const resetAt = new Date(now);
    resetAt.setUTCHours(24, 0, 0, 0);
    await kv.put(
      key,
      JSON.stringify({ count: 1, resetAt: resetAt.toISOString() }),
      { expirationTtl: 86400 }
    );
  } else {
    await kv.put(
      key,
      JSON.stringify({ count: entry.count + 1, resetAt: entry.resetAt }),
      { expirationTtl: 86400 }
    );
  }
}

The expirationTtl on each KV entry means old rate limit records clean themselves up. No cron jobs, no database maintenance. Resets happen at UTC midnight so the behavior is consistent globally.

Where it is now

PackSmart is live and working. It generates solid packing lists, the weather integration adds real value over generic generators, and the fallback system means it never leaves users empty-handed. It’s doing what I built it for: being a useful free tool in the Travel Vient ecosystem.

What I’d do differently

Spend more time on prompt engineering upfront. I went through a lot of iterations on the system prompt, fixing issues as they came up in production. Things like quantity calculations (7-day trip = 7 pairs of socks), shared vs. personal items, and keeping item names short. Most of those rules in the prompt were added reactively after seeing bad output. A more systematic approach to prompt design from the start would have saved time.

Use structured outputs from the beginning. The JSON sanitization code works, but it’s a band-aid. Anthropic’s API supports structured output modes that would eliminate the markdown-fence and trailing-comma problems entirely. I should have started there instead of adding post-processing hacks.

Test with more edge cases early. Trips to places with unusual weather patterns, very long trips, destinations with non-English names. The tool handles these now, but each one was a surprise in production rather than something I caught in testing.

Related: see PackSmart.

Building SumTrails: A Daily Number-Path Puzzle Game

cadendeveloper@gmail.com (Travel Vient) — Sun, 29 Mar 2026 00:00:00 GMT

I just wanted a daily puzzle

I’ve been hooked on the Wordle-style daily puzzle format for a while. One game a day, everyone gets the same one, compare with friends. There’s something about the constraint that makes it satisfying. You can’t binge. You just get your one shot and move on.

I wanted something in that space but more spatial. Draw paths through a grid of numbers where each path sums to exactly 18. Use every cell. Minimum three cells per line. No diagonal moves. Simple rules, but the grid forces you to think several moves ahead because a greedy line now can strand cells later.

I couldn’t find a game that scratched that exact itch. So I built SumTrails. The full source is on GitHub.

What the game does

You get a 7x7 grid filled with numbers 1 through 9. Your job is to draw connected paths (up, down, left, right) where each path’s numbers add up to 18. Every cell on the grid needs to be part of a completed line. Three cells minimum per line.

There’s a daily puzzle that resets at 8am Eastern, and a practice mode for when you’ve already finished today’s. The daily puzzle is seeded, so everyone worldwide plays the same grid.

The stack

React Native + Expo SDK 54 for cross-platform from one codebase. iOS, Android, and web. I’d already built a few Expo apps and knew the workflow.

TypeScript in strict mode. For a game with this much state (grid, paths, undo stacks, hints, solution validation), types caught real bugs during development.

Zustand for state management. Lightweight and lets me keep the game logic as pure functions separate from React.

React Native Reanimated for gesture handling. Drawing paths needs to feel instant. More on that below.

seedrandom for deterministic puzzle generation. This is how everyone gets the same daily puzzle.

The hard part: generating puzzles that are actually fun

The gameplay was straightforward to build. The puzzle generator nearly broke me.

My first approach was random: fill the grid with numbers, then verify that a valid solution exists. This sounds reasonable until you realize that checking solvability on a 7x7 grid is a combinatorial explosion. Most random grids aren’t solvable at all, and the ones that are tend to be boring, with long straight lines running across the whole board.

So I flipped it. Instead of generating a grid and hoping it’s solvable, I generate the solution first and derive the grid from it. The algorithm starts from the center of the grid with a seed shape (L, S, Z, spiral, staircase) and tiles outward with random walks. Then it assigns values to each path so they sum to exactly 18:

function assignValuesToPath(
  pathLength: number,
  targetSum: number,
  valueRange: { min: number; max: number },
  rng: () => number
): number[] | null {
  const { min, max } = valueRange;

  const minPossible = pathLength * min;
  const maxPossible = pathLength * max;

  if (targetSum < minPossible || targetSum > maxPossible) {
    return null;
  }

  const values: number[] = [];
  let remaining = targetSum;

  for (let i = 0; i < pathLength - 1; i++) {
    const cellsLeft = pathLength - i;
    const minVal = Math.max(min, remaining - (cellsLeft - 1) * max);
    const maxVal = Math.min(max, remaining - (cellsLeft - 1) * min);

    if (minVal > maxVal) {
      return null;
    }

    const value = Math.floor(rng() * (maxVal - minVal + 1)) + minVal;
    values.push(value);
    remaining -= value;
  }

  values.push(remaining);
  return shuffleArray(values, rng);
}

Each cell’s value is constrained so the remaining cells can still hit the target. The last cell gets the exact remainder. Shuffle at the end so values don’t cluster predictably.

But that alone produced boring puzzles. Paths were too straight. The secret sauce was direction-aware scoring during path generation. The algorithm tracks how many horizontal vs. vertical steps it’s taken globally and biases new paths toward the underrepresented direction. It also scores turns higher than straight runs:

const scoredNeighbors = neighbors.map(pos => {
  let score = futureNeighbors.length * 0.8;

  if (lastDirection) {
    const isTurn = !(
      direction.row === lastDirection.row &&
      direction.col === lastDirection.col
    );

    if (isTurn) score += 2.0;
    if (consecutiveStraight >= 2 && isTurn) score += 1.5;
    if (consecutiveStraight >= 2 && !isTurn) score -= 0.5;
  }

  // Boost the underrepresented direction globally
  if (isHorizontalStep && bias < 0) {
    score += Math.abs(bias) * 2.0;
  } else if (isVerticalStep && bias > 0) {
    score += Math.abs(bias) * 2.0;
  }

  return { pos, score };
});

This produces paths that wind and turn, which makes them harder to spot and more satisfying to find.

The daily puzzle seed

Every player gets the same daily puzzle because the generation is deterministic. The puzzle ID is a date string, and it becomes the seed for a pseudo-random number generator:

export function generateDailyPuzzle(date: Date = new Date()): GameState {
  const puzzleId = getDailyPuzzleId(date);
  const seed = `sumtrails-${puzzleId}`;
  return generatePuzzleWithSeed(seed, puzzleId, 'daily');
}

The reset happens at 8am Eastern, not midnight. This was deliberate: I didn’t want the puzzle changing while people are still up playing. The timezone math handles DST manually by calculating the 2nd Sunday of March and 1st Sunday of November. If it’s before 8am Eastern, you get yesterday’s puzzle.

What went wrong

Early puzzle generation was bad. Not “slightly off” bad. Fundamentally broken.

The first few versions would produce puzzles where hints would lead you into dead ends. The hint system found a valid line (cells that sum to 18), suggested it, and the player would complete it only to discover the remaining cells couldn’t form any more valid lines. The puzzle was now unsolvable despite the hint being technically correct.

The fix was to never suggest a line unless the remaining board passes a solvability check:

for (let i = 0; i < maxLinesToCheck; i++) {
  const line = validLines[i];
  const newGrid = markCellsAsSpent(grid, line);
  const remainingCells = countAvailableCells(newGrid);

  if (remainingCells === 0) {
    return line;
  }

  if (hasReasonableSolvability(newGrid, targetSum, minLineLength)) {
    return line;
  }
}

// IMPORTANT: Do NOT fall back to validLines[0] - that was the bug!
return null;

That comment in the code is there for a reason. I removed the unsafe fallback three separate times before I stopped re-adding it. The temptation to “just return something” when no safe hint exists was strong. But returning an unsafe hint is worse than returning nothing, because it actively misleads the player.

Where it is now

SumTrails is live on the web, iOS, and Android. The daily puzzle works. The generator produces interesting grids consistently. The hint system no longer lies to you.

It’s a small game. I built it because I wanted a daily puzzle to solve, and now I have one. Some days the 7x7 grid takes me two minutes, some days it takes ten. That variance is what keeps it interesting.

What I’d do differently

Write tests for the generator from day one. I wrote the core game logic tests early, but I treated the puzzle generator as a “get it working and move on” thing. That was a mistake. The hint solvability bug would have been caught immediately by a test that plays through a hint sequence and verifies the board stays solvable. Instead it was a bug report from real usage.

Invest in puzzle quality metrics sooner. I eventually built scoring that tracks direction balance, path variety, and difficulty. But for the first couple weeks, “does it produce a valid grid” was my only bar. Valid and fun are very different things.

Separate the generator into its own package. The puzzle generation code is pure TypeScript with zero React dependencies. It could be its own library, tested and iterated independently. Keeping it in the app repo meant I’d sometimes skip generator improvements because I was focused on UI work.

Related: more side projects and more devlogs.

Moving a Client Site Off an AI Builder, Rebuilt From Scratch

cadendeveloper@gmail.com (Travel Vient) — Sat, 28 Mar 2026 00:00:00 GMT

A few weeks ago I wrote about shipping Griffin Renovation’s website using LandingSite AI. The turnaround was fast, the client was happy, and the site looked good. That should have been the end of the story.

It wasn’t.

The site was ranking poorly. Griffin Renovation serves Cache Valley, Utah, and for local search queries they were barely showing up. I started digging into why, and the answer was straightforward: I didn’t have enough control over the SEO. Meta tags, structured data, canonical URLs, sitemap configuration. LandingSite handles all of that for you, which is great until you need to change something specific and can’t.

On top of that, the monthly hosting fee was adding up for what amounted to a static three-page site. The client was paying a recurring cost for infrastructure I could replace with a free Netlify deploy. Between the SEO ceiling and the ongoing cost, it made sense to rebuild.

The hardest part wasn’t the code

Rebuilding a three-page site in HTML and Tailwind is not complicated. The hardest part was actually getting the domain moved. LandingSite has the hosting locked down, so the only way to transfer is by contacting their support and going back and forth. It’s not a one-click DNS change. That process took longer than writing the entire site.

Once I had the domain sorted, the actual build was fast. No framework, no build step, no npm. Just HTML files, a CSS file, and two JavaScript files. Deployed to Netlify with a _headers file for caching and security.

Taking control of SEO

The whole point of the migration was better SEO, so I went deep on structured data. LandingSite gave me basic meta tags but nothing like proper JSON-LD for a local business. Here’s what I added to the homepage:

{
  "@context": "https://schema.org",
  "@type": "HomeAndConstructionBusiness",
  "name": "Griffin Renovation",
  "telephone": "+1-435-881-7791",
  "areaServed": [
    { "@type": "City", "name": "Logan", "containedInPlace": { "@type": "State", "name": "Utah" } },
    { "@type": "City", "name": "Smithfield", "containedInPlace": { "@type": "State", "name": "Utah" } },
    { "@type": "City", "name": "Hyrum", "containedInPlace": { "@type": "State", "name": "Utah" } },
    { "@type": "City", "name": "North Logan", "containedInPlace": { "@type": "State", "name": "Utah" } }
  ],
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Renovation Services",
    "itemListElement": [
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Home Remodels" } },
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Drywall Installation & Repair" } }
    ]
  }
}

That’s a trimmed version. The full schema includes all eight cities in Cache Valley, all five service types, opening hours, aggregate ratings with individual reviews, and social links. The HomeAndConstructionBusiness schema type is exactly what Google expects for a local contractor. LandingSite had none of this.

I also added proper canonical URLs, Open Graph tags, and Twitter Card meta on every page. Plus a real sitemap with priorities and change frequencies instead of whatever LandingSite was generating behind the scenes.

Reusable components without a framework

With only three pages, I didn’t need React or Astro. But I also didn’t want to copy-paste the header and footer into each HTML file. So I went with a simple JavaScript injection pattern:

document.addEventListener('DOMContentLoaded', () => {
  injectHeader();
  injectFooter();
  initMobileMenu();
  document.body.classList.add('loaded');
});

The header and footer are functions that write HTML into placeholder <div> elements. Active nav states are determined from window.location.pathname. It’s not fancy, but it means updating the navigation is a single-file change instead of editing three HTML files.

The tradeoff is that search engine crawlers running without JavaScript won’t see the nav. I added a <noscript> fallback on every page with a plain HTML nav so crawlers and accessibility tools still get the full link structure.

Preventing the flash of unstyled content

Since I’m using Tailwind CSS v4 via the browser CDN (no build step), there’s a moment before Tailwind processes the styles where the page looks broken. A small CSS trick handles it:

body {
  opacity: 0;
  transition: opacity 0.15s ease-in;
}

body.loaded {
  opacity: 1;
}

The loaded class gets added by JavaScript after the components inject. The page fades in smoothly instead of flashing raw HTML for a split second.

The contact form

LandingSite’s built-in contact form was one of its best features. Replacing it meant finding a solution that didn’t require a backend. I went with EmailJS, which sends emails directly from the browser using their API:

form.addEventListener('submit', async (e) => {
  e.preventDefault();

  const name = form.querySelector('#full-name').value.trim();
  const email = form.querySelector('#email').value.trim();
  const message = form.querySelector('#message').value.trim();

  if (!name || !email || !message) {
    statusMsg.textContent = 'Please fill in all required fields.';
    statusMsg.className = 'text-red-500 text-sm mt-4';
    return;
  }

  submitBtn.disabled = true;
  submitBtn.textContent = 'Sending...';

  try {
    await emailjs.send(EMAILJS_SERVICE_ID, EMAILJS_TEMPLATE_ID, {
      from_name: name, from_email: email, phone, message
    });
    statusMsg.textContent = "Message sent successfully! We'll be in touch soon.";
    form.reset();
  } catch (error) {
    statusMsg.textContent = 'Something went wrong. Please call us directly at (435) 881-7791.';
  }
});

The error fallback displays the phone number directly. For a renovation company, if the form breaks, the client still needs a way to reach them. That matters more than a retry button.

Where it is now

The site is live at griffinrenovation.com. Three pages, no build process, deployed free on Netlify. Images are served through Cloudflare’s image delivery CDN for automatic compression and WebP conversion. Security headers and aggressive caching are handled by a _headers file. The client stopped paying a monthly fee and got better SEO in the process.

What I’d do differently

Skip the AI builder entirely. I wrote about LandingSite positively in the first post, and I stand by that for certain use cases. But for a client where SEO matters and you know you’ll want full control eventually, the AI builder is just an extra step. The time I saved on the initial build, I spent on the migration. If I’d written the HTML from the start, the total hours would have been about the same, and I wouldn’t have had to deal with the domain transfer.

Start with structured data from day one. The JSON-LD schema was the single biggest SEO improvement. I should have had that on the LandingSite version too, even if it meant injecting it through their advanced editor. Local business schema with area served, services, and reviews is table stakes for a contractor competing in local search.

Use a static site generator for anything beyond three pages. Plain HTML worked here because the site is tiny. If Griffin Renovation wanted a blog, a project portfolio, or more service pages, I’d reach for Astro. The JavaScript component injection pattern is fine for three pages but wouldn’t scale well.

Building a Website for a 40-Year-Old Hair Salon

cadendeveloper@gmail.com (Travel Vient) — Sat, 21 Mar 2026 00:00:00 GMT

A local hair salon in Smithfield, Utah reached out and needed a website. Total E’Clips has been cutting hair for over 40 years, serving families across Cache Valley. Three stylists, a loyal client base, and not a single page on the internet. No Google Business profile to speak of, no social media presence beyond a Facebook page, nothing. They wanted something simple that told people who they are, what they offer, and how to book.

The catch: there was almost nothing to work with. No existing branding, no professional photos, no written copy. Just a business name, a phone number, and 40 years of word-of-mouth reputation.

What the site needed to do

This isn’t a SaaS product or a portfolio piece. It’s a small-town salon. The site needed to:

Show what services they offer (cuts, color, nails, waxing)
Make it dead simple to call and book
Look professional enough to build trust with new customers searching online
Work perfectly on phones, because that’s how most people will find it

I went with plain HTML, CSS, and vanilla JavaScript. No frameworks, no build tools, no npm install. For a single-page site like this, shipping three files is the right call. It loads instantly, there’s nothing to break, and anyone can open the code and understand it.

The design system

I wanted the site to feel warm and premium without looking like a generic template. The color palette centers on a warm tan/gold accent against charcoal backgrounds. All defined as CSS custom properties so the entire theme can be updated by changing a few values:

:root {
  --color-dark: #2C2C2C;
  --color-light: #FAF8F5;
  --color-accent: #C4A882;
  --color-accent-hover: #A8896A;
  --color-body: #4A4A4A;
  --color-text-light: #F5F0EB;
  --font-heading: 'Bebas Neue', sans-serif;
  --font-body: 'Raleway', sans-serif;
}

Bebas Neue for headings gives it that bold, modern salon feel. Raleway at weight 300 for body text keeps everything light and readable. Two fonts, one accent color, and the whole site feels cohesive.

Scroll animations without a library

I wanted elements to fade in as you scroll down the page. Most people reach for a library for this. You don’t need one. The IntersectionObserver API does exactly this in about 12 lines of JavaScript:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('is-visible');
      observer.unobserve(entry.target);
    }
  });
}, { threshold: 0.1 });

document.querySelectorAll('.animate-on-scroll').forEach(el => {
  observer.observe(el);
});

The CSS side is just as simple. Elements start translated down and invisible, then transition into place:

.animate-on-scroll {
  opacity: 0;
  transform: translateY(30px);
  transition: opacity 0.6s ease, transform 0.6s ease;
}

.animate-on-scroll.is-visible {
  opacity: 1;
  transform: translateY(0);
}

The key detail: observer.unobserve(entry.target) after the animation fires. Each element animates once and then the observer stops watching it. No wasted cycles on elements that already appeared.

Staggered card animations

The service cards cascade in one by one instead of all appearing at once. This is pure CSS, no JavaScript timing needed. Each card gets a slightly longer transition delay:

.service-card:nth-child(2) { transition-delay: 0.1s; }
.service-card:nth-child(3) { transition-delay: 0.2s; }
.service-card:nth-child(4) { transition-delay: 0.3s; }
.service-card:nth-child(5) { transition-delay: 0.4s; }
.service-card:nth-child(6) { transition-delay: 0.5s; }

When the IntersectionObserver triggers is-visible on each card, the delays mean they appear in sequence. It’s a small touch that makes the page feel alive instead of static.

The hero section

The hero uses a CSS gradient background with an SVG pattern overlay for texture. No images needed, so it loads instantly and scales to any screen:

.hero {
  position: relative;
  height: 100vh;
  min-height: 600px;
  display: flex;
  align-items: center;
  justify-content: center;
  background: linear-gradient(135deg, #2C2C2C 0%, #5C4A3A 40%, #C4A882 100%);
  overflow: hidden;
}

A subtle cross pattern is layered on top at 3% opacity using an inline SVG data URI in the ::before pseudo-element. You barely notice it, but it adds depth that a flat gradient alone doesn’t have.

The hard part wasn’t code

The code came together fast. The actual challenge was content. When a business has had zero internet presence for 40 years, there’s nothing to reference. No existing copy to refine, no “About Us” page to rewrite, no photos to pull from.

I had to piece together the story from conversations. Who are the stylists? How long have they been there? What’s the vibe of the place? The copy needed to sound like a real neighborhood salon, not a marketing template. Lines like “Your neighborhood salon for over 40 years” worked because they’re true and specific. Generic phrases like “providing excellent service” would have said nothing.

Getting the testimonials right took multiple rounds too. Real words from real clients, not AI-generated filler.

What I’d do differently

Use a static site generator. Vanilla HTML was fine for this scope, but if the salon ever wants a second page or a blog, editing raw HTML gets tedious fast. Astro would have been a natural fit. Still static output, still fast, but with components and templating that make updates easier.

Get all the details upfront. I went back and forth more than I should have on service descriptions, the “About” section copy, and contact details. Next time I’d send a structured questionnaire before writing a single line of code. Business hours, services with descriptions, team bios, payment methods, accessibility info. Collect it all in one pass.

Push harder on photography. The images/ folder is empty. The site works without photos, the gradient hero and SVG icons carry the visual weight. But a few real photos of the salon interior and the stylists at work would add a level of authenticity that design alone can’t replicate.

Where it stands

The site is live and does what it needs to do. It gives Total E’Clips a real online presence for the first time in their 40-year history. Customers can find them, see what they offer, and call to book, all from their phone. The entire thing is three files: one HTML, one CSS, one JS. No dependencies, no build step, nothing to maintain.

Sometimes the right tool for the job is the simplest one.

Related: Total Eclips and more side projects.

Building Roamly: AI-Powered Group Travel Planning

cadendeveloper@gmail.com (Travel Vient) — Sun, 15 Mar 2026 00:00:00 GMT

Every time my friend group tries to plan a trip, it falls apart the same way. Someone throws out a city, someone else says it’s too expensive, a third person can’t make those dates, and a fourth person has already been there and doesn’t want to go back. Three weeks of back-and-forth in a group chat later, we either settle on somewhere nobody’s that excited about or give up entirely.

I’ve been on both sides of this. I’ve been the one with strong opinions that kill momentum. I’ve been the one who just wants something on the calendar and agrees to whatever. Neither feels great. So I built Roamly.

What it does

Roamly is a group travel planner. You create a group, invite your friends, and everyone privately fills out their preferences: where they want to go, where they don’t, what their budget is, what dates work for them, how adventurous they’re feeling. When everyone’s ready, the group planner triggers an AI search. Claude reads all those preferences, does some web research, and generates a set of destination recommendations with full day-by-day itineraries tailored to the group.

The key word is privately. Nobody sees what anyone else submitted until after the AI runs. That keeps people honest instead of anchoring to whoever spoke first.

You can try it at roamly.travelvient.com. Check out the Roamly project page for a full feature overview.

The stack

Next.js 15 (App Router) deployed to Cloudflare Workers via OpenNext
Supabase for auth, database, and real-time subscriptions
Anthropic Claude for itinerary generation, with streaming responses
Stripe for subscription billing
Tailwind v4 and shadcn-style components for the UI

The real-time piece is important. When members fill out their preferences, every other person in the group sees their status update live. No polling, no refreshing. Supabase’s Postgres change subscriptions handle it cleanly:

const channel = supabase
  .channel(`group-prefs-${groupId}`)
  .on(
    "postgres_changes",
    {
      event: "*",
      schema: "public",
      table: "member_preferences",
      filter: `group_id=eq.${groupId}`,
    },
    (payload) => {
      if (payload.eventType === "UPDATE") {
        setPreferences((prev) =>
          prev.map((p) =>
            p.user_id === (payload.new as MemberPreferences).user_id
              ? (payload.new as MemberPreferences)
              : p
          )
        );
      }
    }
  )
  .subscribe();

One subscription, three event types handled, no full refetch. It just works.

The hard part: getting the AI to behave

The core feature is the AI search, and it was the hardest thing to get right. The goal is simple: take a group’s mixed preferences and produce a useful, structured itinerary JSON. The reality is that language models are not naturally reliable at this.

Early outputs were all over the place. Destinations that blew someone’s budget. Missing fields that caused the UI to crash. Hallucinated dates. Responses that ignored explicit exclusions like “no beach destinations.”

The fix was iterative and unglamorous: better constraints in the system prompt, explicit hard rules around budget and exclusions, and treating the JSON schema as a contract that the model had to follow. I also built in a credit refund system for cases where the model hits token limits or refuses a request. Users shouldn’t lose a search credit because Claude decided to truncate at 8,000 tokens.

The model selection is tiered by subscription level. Three Claude models mapped to three tiers:

export const AVAILABLE_MODELS: ModelConfig[] = [
  {
    id: "claude-haiku-4-5-20251001",
    label: "AI Basic",
    tier: "budget",
    description: "Quick results, good for exploration",
  },
  {
    id: "claude-sonnet-4-5",
    label: "AI+",
    tier: "standard",
    description: "Great quality and detail",
  },
  {
    id: "claude-opus-4-5",
    label: "AI Pro+",
    tier: "premium",
    description: "Most thorough itineraries",
  },
];

Haiku is fast and free. Opus takes longer but produces noticeably richer itineraries. Most people will land on Sonnet.

Streaming and recovery

AI responses take time. For a complex group itinerary, Claude can run for 15-30 seconds. Showing a blank screen that long is not acceptable, so I stream the response directly to the client as it generates. The UI shows the tail of the stream in real time so users know something is happening.

The trickier problem is what happens when the stream gets interrupted. User closes the tab, network drops, phone locks. I track active searches in localStorage with a 120-second TTL:

export function getActiveSearch(
  groupId: string,
  userId: string
): ActiveSearch | null {
  try {
    const raw = localStorage.getItem(STORAGE_KEY);
    if (!raw) return null;
    const entry: ActiveSearch = JSON.parse(raw);
    if (entry.groupId !== groupId || entry.triggeredBy !== userId) return null;
    const age = Date.now() - new Date(entry.startedAt).getTime();
    if (age > 120_000) {
      localStorage.removeItem(STORAGE_KEY);
      return null;
    }
    return entry;
  } catch {
    return null;
  }
}

When a user lands back on the search page and a recent search marker exists, the app polls the database every 3 seconds for up to 30 attempts looking for a saved result. If it finds one, it loads it. If not, it shows a failure state. The user doesn’t lose their credit either way on a connection error.

What went wrong: Cloudflare

Deploying Next.js to Cloudflare was rougher than I expected. The first assumption I made was wrong: Next.js cannot be deployed as a Cloudflare Pages project the normal way. It has to run as a Worker, using OpenNext as the adapter. The config itself ends up being trivially simple:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";
export default defineCloudflareConfig();

But getting there involved a lot of failing builds and confusing error messages.

The other headache was secrets. Environment variables that work fine in Vercel don’t automatically show up at runtime in Cloudflare Workers. You have to use wrangler secret put to push them, and the compatibility flags in wrangler.toml matter for Node.js APIs to work at all:

compatibility_flags = ["nodejs_compat", "nodejs_compat_populate_process_env"]

That second flag, nodejs_compat_populate_process_env, is the one that actually makes process.env work. Without it, all your secrets are undefined at runtime and you get a wall of cryptic auth errors. I spent more time than I’d like to admit figuring that out.

Where it is now

Roamly is live and free to use. There’s a paid tier that unlocks more monthly searches and access to better models. It’s early. The user base is small. But the core loop works, and I’ve actually used it with my own friends to plan a trip, which was the original goal.

What I’d do differently

If I started over, I’d use plain React instead of Next.js. Not because Next.js is bad, but because Cloudflare Workers is where I wanted to deploy from the start, and the Next.js-on-Workers story involves the OpenNext adapter as a middle layer. That layer works, but it’s an extra thing to maintain and debug. A Vite-based React app with a separate API layer would have been faster to ship and easier to reason about on the edge.

The second thing I’d change is how I approached the AI prompting. I iterated my way to something that works, but it took longer than it needed to because I didn’t think clearly enough about the output contract upfront. Starting with the JSON schema and working backwards to the prompt would have saved a few frustrating weeks.

The group travel problem is real. Roamly doesn’t solve all of it, but it solves the part where nobody can agree on where to go. That’s a start.

Related: see Roamly.

I Built a Pipeline to Generate YouTube Shorts Programmatically

cadendeveloper@gmail.com (Travel Vient) — Sat, 14 Mar 2026 00:00:00 GMT

I got bored one weekend and started wondering: how hard would it actually be to generate a YouTube Short entirely from code? Not screen-record something, not stitch clips manually, but write a script in a text file and have a program hand you back a finished .mp4.

Turns out: not that hard. Also not free. Here’s what I built, how it works, and what I’d do differently.

You can find the full code on GitHub: github.com/caden311/content-generator

Here’s an example of one of the Shorts it generated: youtube.com/shorts/pbITB7jEUzc

What it actually does

The pipeline takes a plain text script as input and runs it through five stages:

Scene breakdown, Claude reads your script and returns a JSON breakdown with one scene per segment. Each scene gets an image prompt, a video prompt, narration text, and a target duration in seconds.
Asset generation, For every scene, the pipeline fires off image generation (Fal FLUX), video generation (Fal Kling), and text-to-speech (ElevenLabs) in parallel.
Subtitle generation, Each audio file gets transcribed by Whisper to get word-level timestamps, which are converted to an ASS subtitle file.
Assembly, FFmpeg concatenates the clips, merges the voiceover, and burns in the subtitles.
YouTube metadata, Claude generates a title, description, and tags, saved to upload.json next to the video.

The whole thing runs from one command:

npm run generate -- my-script.txt --format shorts

The stack

Claude handles the script-to-scenes breakdown. I gave it a system prompt that asks for strict JSON output with image prompts, video prompts, and narration split per scene. Using a structured prompt instead of freeform prose made parsing predictable.

Fal.ai runs both FLUX (images) and Kling (video generation). Fal uses an async queue model: you submit a job, get back a status_url and response_url, then poll until it finishes. This is fine for a CLI but means each video clip can take a few minutes.

ElevenLabs handles the narration voice. The default voice is Rachel (21m00Tcm4TlvDq8ikWAM) from their multilingual v2 model. You can swap it with the --voice flag.

OpenAI Whisper transcribes the generated audio back to word-level timestamps, which power the subtitles. Yes, you generate speech and then transcribe it. The timestamps are accurate enough that it works.

FFmpeg does the final assembly. If a video clip failed to generate, it falls back to a still image with a Ken Burns zoom effect so the video doesn’t look dead.

The adapters are all behind interfaces, so swapping one provider for another means writing one new class. Three tiers are built in: budget, standard, and premium, each mapping to a different adapter set.

Getting everything talking to Claude

The trickiest design decision was the scene breakdown prompt. I needed Claude to return consistent JSON every time, with scenes that summed to under 60 seconds for Shorts format.

The fix was simple: inject a {{MAX_DURATION_INSTRUCTION}} placeholder into the system prompt that only gets filled in when you’re targeting 9:16 format.

// src/adapters/llm/claude.ts
const SYSTEM_PROMPT = `You are a video production assistant...
{{MAX_DURATION_INSTRUCTION}}`;

async breakdownScript(script: string, maxDurationSeconds?: number) {
  const maxDurationInstruction = maxDurationSeconds !== undefined
    ? `- IMPORTANT: Total duration MUST NOT exceed ${maxDurationSeconds} seconds`
    : "";
  const systemPrompt = SYSTEM_PROMPT.replace(
    "{{MAX_DURATION_INSTRUCTION}}",
    maxDurationInstruction
  );
  // ...
}

Claude also occasionally wraps the JSON in a markdown code block. The response parser strips that before calling JSON.parse:

const jsonMatch = jsonStr.match(/```(?:json)?\s*([\s\S]*?)```/);
if (jsonMatch?.[1]) {
  jsonStr = jsonMatch[1];
}

Small thing, but it would silently break without it.

The hard part: timing

Getting audio, video, and subtitles to sync up correctly was messier than I expected.

Each scene has a durationSeconds from Claude’s breakdown. But the actual generated audio is rarely exactly that long. ElevenLabs paces speech differently depending on the narration content, and Kling generates clips in fixed 5 or 10 second chunks regardless of what you asked for.

The subtitle system handles this by measuring the real audio duration. Whisper returns actual word timestamps, and the subtitle generator tracks a running offset that accumulates across scenes based on the durationSeconds field, not the real audio length. That mismatch meant subtitles could drift by a second or two on longer videos.

Here’s how the offset calculation works in the orchestrator:

// src/pipeline/orchestrator.ts
let offset = 0;
const sceneAudioInfos = [];

for (const asset of sortedAssets) {
  const scene = project.breakdown.scenes[asset.sceneIndex];
  if (asset.audioPath) {
    sceneAudioInfos.push({
      narration: scene.narration,
      audioPath: asset.audioPath,
      offsetSeconds: offset,        // cumulative offset passed to Whisper
    });
  }
  offset += scene.durationSeconds;  // uses target duration, not real duration
}

The fix would be to measure actual audio duration with ffprobe and use that for the offset instead. I didn’t get around to it.

The final assembly step trims the output to Math.min(videoDuration, audioDuration) to avoid a silent tail if the audio runs shorter than the video. That part at least works cleanly.

What went wrong: subtitles

The subtitle burn-in was the most frustrating part of the whole project.

FFmpeg can burn ASS subtitles using a libass filter. The command looks like:

ffmpeg -vf "ass=filename=subtitles.ass" ...

But libass is not included in the default Homebrew FFmpeg build on macOS. You get a cryptic “No such filter” error at runtime. The workaround is:

brew install libass
brew reinstall ffmpeg

The pipeline now catches the specific error string and logs a helpful message instead of crashing:

// src/assembly/ffmpeg.ts
} catch (err: any) {
  if (err?.stderr?.includes("No such filter")) {
    logger.warn(
      "ffmpeg built without libass, subtitles skipped. " +
      "Fix: brew install libass && brew reinstall ffmpeg"
    );
  } else {
    throw err;
  }
}

If subtitle burning fails, the video still gets assembled, just without the text overlay. For Shorts this matters a lot since most people watch without sound.

How to try it yourself

Prerequisites:

Node.js 22+
FFmpeg with libass: brew install libass && brew install ffmpeg
API keys for Anthropic, OpenAI, Fal.ai, and ElevenLabs

Setup:

git clone https://github.com/caden311/content-generator
cd content-generator
npm install

Create a .env file:

ANTHROPIC_API_KEY=your_key
OPENAI_API_KEY=your_key
FAL_KEY=your_key
ELEVENLABS_API_KEY=your_key

Write a script. Plain text, narration style, a few paragraphs. The shorter the better for Shorts. Save it as script.txt.

Generate:

# YouTube Short (9:16, 60s max)
npm run generate -- script.txt --format shorts

# Standard YouTube video (16:9)
npm run generate -- script.txt

# Dry run (no API calls, generates placeholder media)
npm run generate -- script.txt --dry-run

Output lands in ./output/001_your-video-title/output.mp4 alongside a breakdown.json, upload.json with YouTube metadata, and all the intermediate assets.

Model tiers:

Tier	Images	TTS
`budget`	FLUX Schnell	OpenAI TTS
`standard`	FLUX Schnell	ElevenLabs
`premium`	DALL-E 3	ElevenLabs

All tiers use Kling for video generation. You can switch with --tier premium.

Cost estimate: A standard 4-scene Short runs roughly $0.30-0.60 depending on the tier. Most of that is Kling. Image and TTS costs are small.

Where it is now

It works. The output quality is… fine. Kling generates reasonably coherent motion clips. The ElevenLabs voice sounds natural. The visuals are a little random since there’s no style consistency between scenes, but for a weekend experiment it’s genuinely impressive that it works at all.

The project is not something I’m actively maintaining. It was a curiosity project that answered its question: yes, you can generate short-form video content from a text file in an afternoon. Whether the content is actually good is a separate problem.

What I’d do differently

Add background music. The biggest thing missing from the generated Shorts is audio atmosphere. The narration sits on dead silence, which feels unpolished. Adding a royalty-free background track and ducking it under the voiceover would make a meaningful difference to the final feel.

Measure real audio duration for subtitle offsets. As mentioned above, using the target durationSeconds from Claude instead of the actual audio file length causes subtitle drift. A single ffprobe call per scene at assembly time would fix it.

Add a visual style constraint to image prompts. Right now each scene generates an image independently, so the visual style can jump around. Injecting a consistent style prefix into every image prompt (something like “cinematic, warm color grading, consistent lighting”) would make multi-scene videos look less like a random slideshow.

The underlying approach is solid. The pipeline architecture, the parallel asset generation, the adapter pattern for swapping providers: all of that held up. The rough edges are mostly surface-level quality problems that more prompt engineering and one or two extra processing steps would fix.

Related: more devlogs and side projects.

I Built a WoW Addon to Automate My Portal Business

cadendeveloper@gmail.com (Travel Vient) — Sat, 07 Mar 2026 00:00:00 GMT

If you’ve played World of Warcraft Classic, you know mages are the taxi service of Azeroth. Stand in a capital city, spam “/yell WTS ports to all cities”, wait for people to type “WTB port org” in chat, invite them, cast the portal, collect gold. Repeat indefinitely.

I was doing this. And I kept missing requests. Someone would yell “WTB port” and by the time I noticed and typed their name into the invite dialog, they’d already moved on or found another mage. So I did what any programmer would do: I spent several hours building a tool to automate a task that costs maybe 5 seconds per attempt.

But honestly it was more than just efficiency. I also wanted to learn WoW addon development. And I genuinely wanted a tool like this to exist. So: all three motivations, all at once.

The result is mage-portals: a WoW Classic addon that watches chat for portal requests and auto-invites the buyer. No more missed sales.

What it does

The addon listens to /say, /yell, and General (/1) by default. When it sees a message containing trigger words (“WTB” or “LF”) combined with portal words (“port”, “ports”, “portal”, “portals”), it fires an invite to that player automatically.

It also tries to detect which portal they want. If someone says “WTB port to uc”, the addon can log that it’s Undercity and optionally whisper them a confirmation. There’s a throttle so the same player doesn’t get spammed with repeat invites. It checks whether you’re in a raid (and whether you’re the leader or assistant), because only certain roles can invite.

There’s a minimap button with a portal icon. Right-click opens the config. Left-click toggles the addon on and off.

The stack

Lua. That’s it. WoW addons are Lua all the way down. There’s no package manager, no build step, no bundler. You write .lua files, reference them in a .toc manifest, drop the folder into Interface/AddOns/, and the game loads it.

Persistence works through SavedVariables. You declare a table name in the .toc file and the game automatically serializes it to disk when you log out. It’s a simple system that mostly stays out of your way.

The Classic Anniversary realm targets interface version 11500. A lot of the API is different from Retail and even slightly different across Classic versions, which turned out to matter when it came to actually sending the invite.

The pattern matching problem

The first version used a simple string.find(msg, "port") check. This works until someone types “I imported that mount from the auction house” in General chat. So it needed real word boundaries.

Lua’s pattern language doesn’t have \b. It has %f[%a], the “frontier pattern,” which matches a position where the previous character is not in the set and the next one is. It’s how you do word boundaries in Lua:

local function MsgHasPortalRequest(msg)
  if type(msg) ~= "string" then return false end
  local s = msg:lower()

  local hasWTB = s:find("%f[%a]wtb%f[%A]") ~= nil
  local hasLF  = s:find("%f[%a]lf%f[%A]")  ~= nil

  local hasPort =
    (s:find("%f[%a]ports?%f[%A]")   ~= nil) or
    (s:find("%f[%a]portals?%f[%A]") ~= nil)

  return (hasWTB or hasLF) and hasPort
end

%f[%a] before a word means “position where the previous char is not a letter.” %f[%A] after means “position where the next char is not a letter.” Combined, they give you real word boundaries. “airport” doesn’t match because %f[%a]port requires a non-letter before “port,” and there’s an “r” there.

The invite logic also checks whether you can actually invite before doing anything. You can’t invite someone if you’re not the raid leader, if the party is full, or if the addon is disabled:

local function CanSendInvite()
  if IsInRaid and IsInRaid() then
    if UnitIsGroupLeader and UnitIsGroupLeader("player") then return true end
    if UnitIsGroupAssistant and UnitIsGroupAssistant("player") then return true end
    return false, "not raid leader/assistant"
  end

  if IsInGroup and IsInGroup() then
    if UnitIsGroupLeader and UnitIsGroupLeader("player") then
      if GetNumGroupMembers and GetNumGroupMembers() >= 5 then
        return false, "party full"
      end
      return true
    end
    return false, "not party leader"
  end

  return true
end

The API compatibility shim for actually sending the invite was also necessary. Classic exposes InviteUnit as a global; some versions only have C_PartyInfo.InviteUnit. The addon tries both:

local function SendInviteByName(name)
  if type(InviteUnit) == "function" then
    InviteUnit(name)
    return true, "InviteUnit"
  end
  if C_PartyInfo and type(C_PartyInfo.InviteUnit) == "function" then
    C_PartyInfo.InviteUnit(name)
    return true, "C_PartyInfo.InviteUnit"
  end
  return false, "no invite API"
end

Trade chat was a disaster

The addon originally had Trade (/2) listening enabled by default. This lasted about ten minutes before it became clear that was a mistake.

Trade chat is not General chat. People post long trade offers with multiple city names in them: “WTB port or any TBC mats, currently in TB need to get to UC for raid.” The basic portal detector would happily fire an invite on that. The person isn’t buying a portal from you; they’re trading mats, they mentioned a city in passing, and now they have an unexpected group invite from a stranger.

The fix was a separate, stricter filter for Trade channel only. It rejects messages where someone specifies a source city that isn’t Orgrimmar (because if you’re already in Orgrimmar, you need a portal out; if you’re in Thunder Bluff, you need something else entirely). It also catches implicit city pairs: “tb to uc” reads as “I’m in Thunder Bluff going to Undercity,” which means I can’t help.

-- Reject "from <other city>" patterns in Trade.
local fromOtherCity =
  fromHas("%f[%a]uc%f[%A]") or fromHas("%f[%a]undercity%f[%A]") or
  fromHas("%f[%a]tb%f[%A]") or fromHas("%f[%a]thunderbluff%f[%A]") or
  fromHas("%f[%a]shat%f[%A]") or fromHas("%f[%a]shattrath%f[%A]")

if fromOtherCity and not fromOrg then
  return false
end

-- Also reject implicit "tb to uc" patterns.
local srcOtherCityTo =
  srcBeforeToHas("%f[%a]tb%f[%A]") or srcBeforeToHas("%f[%a]undercity%f[%A]")
  -- ... etc.

if srcOtherCityTo then return false end

Trade listening is still there, but it defaults to off. Most mages selling portals are standing in Orgrimmar anyway, and General chat is noisy enough to catch real buyers.

The minimap button

This was the hardest part. Not conceptually hard, just fiddly in a way that took longer than expected.

WoW addons build UI by creating frames and attaching textures to them. A minimap button sounds simple: create a button, parent it to the Minimap frame, place it on the edge. In practice, there are four separate textures (background fill, icon, border ring, hover highlight), each needs to be independently sized and offset, and the whole thing needs to stay draggable while remaining clamped to the screen edge.

The button position is stored as an angle in SavedVariables so it persists between sessions. On load it converts the angle back to x/y coordinates relative to the minimap center:

local rad    = angle * math.pi / 180
local radius = math.min(mmw, mmh) / 2 + 10  -- just outside the minimap edge
local x = math.cos(rad) * radius
local y = math.sin(rad) * radius
minimapButton:SetPoint("CENTER", Minimap, "CENTER", x, y)

Getting the offsets right so the icon, background, and border ring all looked centered took several iterations. Each texture has its own pixel offset because the WoW border texture isn’t square and doesn’t align with the button frame the way you’d expect.

Where it is now

It works. I use it when I’m farming portals on my mage. I open the game, turn on the addon, stand in Orgrimmar, and let it run. If someone asks for a port in General or Yell, I get an invite attempt automatically with a chat message telling me who and why.

The code is on GitHub. It’s not on CurseForge yet. It’s a single Lua file; if you play a mage on Classic Anniversary you can drop it in your AddOns folder and it should just work.

What I’d do differently

Design the config schema first. The SavedVariables table grew as I added features: channel toggles, throttle duration, minimap position, whisper behavior, water invites. Each one made sense when I added it, but the result is a flat table with a dozen unrelated keys. A more intentional structure upfront would have been cleaner to maintain.

Write tests before patterns. The pattern matching functions are the most important logic in the addon and the most fragile. I tested them manually by typing strings into the chat box. That worked, but a standalone test file with a table of expected matches and non-matches would have caught regressions much faster and made the Trade channel filter much less painful to get right.

Publish it. The whole point of automation is that other people have the same problem. Other mages are also missing portal requests. The friction to put this on CurseForge is low; I just haven’t done it yet.

Related: more side projects and more devlogs.

I Built a Chrome Extension That Tells Jokes (4,600 People Use It)

cadendeveloper@gmail.com (Travel Vient) — Sun, 01 Mar 2026 00:00:00 GMT

I wanted a Chrome extension that would tell me a joke when I opened a new tab or clicked the icon. Something clean, fast, and actually funny. I looked around. The ones I found were slow, ugly, or pulling from joke APIs with no content filtering. So I built my own.

That was the whole origin story. No grand vision. No market research. I wanted a thing, the existing things weren’t good, so I made the thing.

What it does

Joke of the Day is a Chrome extension (Manifest V3) that serves you one joke per day. Click the icon, you get a joke: a setup and a punchline. Free users get a new joke every 12 hours, plus one free skip per cycle if the joke isn’t landing. Premium users ($3.99, one-time) get unlimited skips.

It has 4.6k installs and a 4.6 rating on the Chrome Web Store. I did zero marketing. It just… grew.

The stack

The first version was plain JavaScript with a build script held together with string. It worked but was annoying to extend. When I wanted to add the premium tier and a proper joke engine, I rewrote it as a learning exercise: TypeScript 5.x, Vite with the CRXJS plugin, strict mode on.

CRXJS is worth calling out specifically. It handles the annoying parts of Chrome extension development: hot module reload during development, manifest validation, bundling the service worker and popup as separate entry points. Without it, MV3 development involves a lot of manual reloading and guessing why the service worker died.

For payments I used ExtensionPay. No Stripe integration to maintain, no webhook server, no subscription management UI. The SDK is a single import. Under MV3 you have to call startBackground() in the service worker as well as the popup, because the service worker can be killed at any time and needs to reinitialize payment state when it wakes up:

// service-worker.ts
chrome.runtime.onInstalled.addListener(async () => {
  if (EXTENSIONPAY_ID) {
    ExtPay(EXTENSIONPAY_ID).startBackground();
  }
  chrome.alarms.create(ALARM_NAME, { periodInMinutes: 30 });
  await storage.getUserState();
});

// Also runs on every service worker startup, not just install.
if (EXTENSIONPAY_ID) {
  ExtPay(EXTENSIONPAY_ID).startBackground();
}

That second startBackground() call outside the listener is not a bug. Service workers under MV3 are ephemeral: they start, do their job, and shut down. The onInstalled handler only fires once. Every other time the worker wakes up, you need that top-level call.

The joke engine

This is the part I spent the most time on, and the part I’m most happy with.

The extension has three tiers of jokes, served in alternating order. First it works through 500 curated monthly jokes (seasonal, tied to the current month). Then it alternates with a general pool. When both curated pools are exhausted, it falls through to an infinite generator.

The alternating logic sits in getCurrentJoke():

private getCurrentJoke(): Joke {
  const totalSeen = this.state.currentMonthJoke + this.state.currentJoke;
  const preferMonthly = totalSeen % 2 === 0;

  const hasMonthly = this.state.currentMonthJoke < monthlyJokes.length;
  const hasGeneral  = this.state.currentJoke     < generalJokes.length;

  if (preferMonthly) {
    if (hasMonthly) return monthlyJokes[this.state.currentMonthJoke];
    if (hasGeneral)  return generalJokes[this.state.currentJoke];
  } else {
    if (hasGeneral)  return generalJokes[this.state.currentJoke];
    if (hasMonthly)  return monthlyJokes[this.state.currentMonthJoke];
  }

  // Both curated pools exhausted, use the generator.
  return this.getGeneratedJoke();
}

Even if someone used the extension every single day for years, they’d never hit a wall. The fallthrough to the generator is seamless.

The generator itself is template-based. It has a set of joke structures (templates with named slots) and word pools keyed by slot name. Each month has overrides that weight the pools toward seasonal vocabulary:

const MONTH_OVERRIDES: Record<number, Partial<Pools>> = {
  9: { // October
    holidayThing: ["a ghost", "a witch", "a pumpkin"],
    seasonThing:  ["pumpkins", "costumes", "candy", "spooky sounds"],
    punNoun:      ["broommates", "a boo-tiful idea", "a fright delight"],
    punchline:    ["was having a spook-tacular time", "didn't want to be a scaredy-cat"],
  },
  // ... one entry per month
};

The mergePools function combines base and override by prepending seasonal words, so they appear more often than their base counterparts without completely replacing them. And the fill() function slots words into templates using a regex replace:

function fill(str: string, pools: Pools) {
  return str.replace(/\{(\w+)\}/g, (_, key: keyof Pools) => pick(pools[key]));
}

One line. Takes "Why did the {thing} {verb}?" and turns it into "Why did the snowman start a band?". The deduplication uses a normalized key so near-identical jokes don’t slip through on different runs:

function normalizeKey(j: Joke) {
  return `${j.month ?? "x"}|${j.question.trim().toLowerCase()}|${j.answer.trim().toLowerCase()}`;
}

The badge problem

MV3 killed persistent background pages. That was fine for most of what I needed, but it created a specific problem: I wanted to show a “NEW” badge on the extension icon when a joke became available. Under MV2, you’d just have a background page listening to a timer. Under MV3, the service worker is gone the moment it goes idle.

The fix is Chrome’s Alarms API. You register an alarm, and Chrome will wake your service worker on a schedule even if it’s been shut down:

chrome.alarms.create(ALARM_NAME, { periodInMinutes: 30 });

chrome.alarms.onAlarm.addListener(async (alarm) => {
  if (alarm.name === ALARM_NAME) {
    await checkAndNotifyNewJoke();
  }
});

Every 30 minutes Chrome wakes the worker, it checks if a new joke is available, and either sets the badge or clears it. The worker then shuts down again. The key insight: you’re not keeping the worker alive. You’re scheduling wake-ups.

What surprised me

4,600 installs with no marketing. No Product Hunt launch, no Reddit post, no Twitter thread. Just the Chrome Web Store listing and an SEO-friendly title.

I don’t fully understand it. My best guess: the search term “joke of the day extension” has low competition and the listing copy is specific enough to rank. Whatever the reason, it’s the most passive thing I’ve ever shipped.

The 4.6 rating is actually what I’m most proud of. Extensions are hard to rate well because users install them, forget about them, and only bother to review when something goes wrong. A 4.6 on ~50 reviews means people actively liked it enough to say so.

Where it is now

It’s live at the Chrome Web Store. The premium tier is $3.99 one-time, which is probably too cheap, but it converts and I don’t want to think about billing support.

The codebase is TypeScript throughout, which was the whole point of the rewrite. Strict mode caught several bugs that would have shipped silently in the original JS version.

What I’d do differently

Start with TypeScript. The rewrite wasn’t painful but it was unnecessary. Strict TypeScript from the start would have caught the same bugs earlier.

Pick a more defensible content niche. “Jokes” is broad. A version scoped to a specific style (dry humor, dad jokes only, one-liners) would be easier to market and would attract more loyal users.

Add telemetry earlier. I have no idea which jokes users see most, which ones get skipped, or how many people actually exhaust the curated pool. The storage layer exists; adding basic anonymous analytics would have taken a day and would have made the joke generator much easier to tune.

If you’re thinking about building a Chrome extension, the tooling has gotten genuinely good. TypeScript + Vite + CRXJS is a fast setup and MV3’s constraints are manageable once you internalize the service worker lifecycle. Start small. Something you’d use yourself is the right place to begin.

Related: Joke of the Day and more side projects.

I Shipped a Client Site in an Afternoon Using an AI Builder

cadendeveloper@gmail.com (Travel Vient) — Sun, 22 Feb 2026 00:00:00 GMT

A referral came in: a renovation company needed a website up as soon as possible. No existing site, no branding assets beyond a business name, and a client who wanted something live before their next job started. The kind of timeline where you don’t have time to spin up a custom Astro build, write copy from scratch, and figure out a contact form.

So I tried something I hadn’t used before. LandingSite.ai is an AI website builder that generates a complete site from a business description. You type a few sentences about the company, it produces a full multi-section site with copy, a logo, layout, and hosted infrastructure in about five minutes.

I was skeptical. I’ve seen too many AI tools that produce something impressive in the demo and underwhelming in practice. This one surprised me.

What the site needed to do

Griffin Renovation is a renovation company with 32 years of experience. They do drywall, painting, framing, trim work, and full project management. The site needed to:

Communicate credibility fast (the 32 years matters)
Show past work (gallery with before/after photos)
Make it easy to reach them (phone, email, contact form)
Work on mobile without me hand-tuning a single media query

Nothing technically exotic. But “nothing technically exotic” still takes days to build well from scratch if you’re writing the code yourself and also writing the copy and also sourcing photos.

How LandingSite actually works

You describe the business in plain language. The AI generates a full website: hero section, about section, services, gallery, testimonials, contact form, and a logo. It hosts it, handles SSL, and gives you a subdomain immediately. You can connect a custom domain later.

The generated site uses Tailwind CSS and produces clean semantic markup. The content structure was genuinely solid for a trade services company. It pulled together the right sections in the right order without me specifying anything beyond the business type.

The piece I didn’t expect to work as well: the contact form. It was functional out of the box, routed to the client’s email, and handled spam filtering without any configuration on my end.

What needed fixing

The copy it generated was the main problem. The AI gave Griffin Renovation a voice that felt like a generic contractor, heavy on phrases like “transforming your living spaces” and “tailored experiences.” Those aren’t wrong, but they weren’t specific enough to stand out. The 32 years of experience was there but buried.

I went through every section and rewrote the copy to be more direct and specific: leading with what the company actually does, using the client’s language, making the experience claim prominent rather than parenthetical. The AI had good structure; it just needed a human voice.

The layout also needed work. The default spacing was conservative in a way that made the site feel cramped on desktop. LandingSite has an “advanced edit” mode that gives you access to the CSS directly. I used it to adjust padding on several sections, fix the gallery grid proportions, and get the hero section to breathe properly. It’s a real CSS editor, not a drag-and-drop toy, which meant I could make the specific changes I needed without fighting an abstraction layer.

The part I’d skip next time

The spacing issues were all fixable in the CSS editor, but a few layout problems took longer than they should have because I was working within the AI-generated structure rather than just writing the HTML myself. There’s a specific kind of frustration that comes from trying to override a layout you didn’t design: you fix one thing, something else shifts, you fix that.

For a quick client site, LandingSite was the right call. But anything with specific layout requirements would be faster to build from scratch. The AI builder saves you time on boilerplate and copy scaffolding. It costs you time when the generated structure doesn’t match what you actually need.

Where it is now

The site is live at griffinrenovation.com. It has the gallery, the contact form, the testimonials, the full services breakdown. The client was happy with the turnaround.

LandingSite charges a monthly fee for hosting and the continued AI editing. For a small business site that doesn’t change often, that’s a reasonable tradeoff against the cost of self-hosting and maintaining your own infrastructure. The client isn’t going to be pushing code; they need to be able to ask the AI to update their phone number or add a new photo.

What I’d do differently

Get a content brief before generating anything. The AI copy problems came from vague input. If I’d collected the client’s actual service descriptions, their differentiators, and the exact phrases they use with customers before starting, the first pass would have been much closer to the final version.

Start with custom code for anything layout-sensitive. The gallery and hero section were the two places that needed the most CSS work. Both are common enough components that I could have written them in a few hours, and I’d have had full control. The AI builder earns its time savings on forms, copy scaffolding, and the parts that are genuinely tedious to build. The layout stuff it generates is fine for a standard site but fragile when requirements are specific.

Set expectations about the AI editing model early. The client will probably want to make changes eventually. The LandingSite chat interface is intuitive, but “tell the AI what you want” is a different mental model from a traditional CMS. Walking the client through that before handing off would prevent confusion later.

The overall verdict: for a client who needs something live quickly and doesn’t have strong opinions about layout, LandingSite is a legitimate option. It’s not a replacement for a real build, but “real build” isn’t always the right tool for the job.

I Built Smoke or Fire: A React Native Card Game

cadendeveloper@gmail.com (Travel Vient) — Thu, 20 Mar 2025 00:00:00 GMT

It started at a party

Someone pulled out a deck of cards and announced we were playing Smoke or Fire. You probably know it. You guess whether the next card is red or black (smoke or fire), then higher or lower, then inside or outside your first two cards, then the suit. Get it right and someone drinks. Get it wrong and you drink. There’s a pyramid at the end where everyone’s cards come back to haunt them. Simple, chaotic, and genuinely fun.

The problem: you always need a physical deck of cards. Someone has to shuffle, someone has to deal, someone has to remember whose turn it is. Half the time the game falls apart before the pyramid because nobody can keep track.

I had been wanting to learn React Native for a while. Not just read about it, actually build something real with it. Smoke or Fire seemed perfect. It’s a game I knew well enough that I wasn’t figuring out the rules and the code at the same time, and the UI is essentially just cards and buttons. It felt scoped.

So I built it. The full source is on GitHub.

What the game does

The app has two phases.

The first is four sequential rounds. Every player takes a turn guessing before their card is flipped. Round one: red or black. Round two: higher or lower than your previous card. Round three: inside or outside your first two cards. Round four: name the suit. Correct means you give out drinks. Wrong means you take them.

After all four rounds, the pyramid. Nine cards in a diamond pattern, revealed one at a time. Each revealed card matches against every card every player drew across rounds one through four. Match a card in row one and you give a drink. Row two and you take one. The drink amounts scale toward the center. By the last card, things get chaotic.

Two ways to play: pass-and-play for couch sessions on a single phone, or real-time multiplayer where everyone joins with a four-letter room code. The room codes exclude the letters I and O so nobody types a zero when they mean an O:

function generateRoomCode(): string {
  const letters = "ABCDEFGHJKLMNPQRSTUVWXYZ"; // Exclude I and O to avoid confusion
  let code = "";
  for (let i = 0; i < 4; i++) {
    code += letters.charAt(Math.floor(Math.random() * letters.length));
  }
  return code;
}

Small thing. Noticed it during testing when someone kept entering the wrong code.

The stack

React Native 0.81 + Expo SDK 54 because cross-platform was the goal from day one. iOS, Android, and web from one codebase, with Expo handling the native configuration that used to eat entire weekends.

TypeScript with strict mode throughout. For a multiplayer game with this much state, the type safety paid for itself within the first few days.

Firebase Realtime Database for multiplayer sync. More on why this caused problems in a minute.

react-native-reanimated v4 for the card flip animation. The 3D perspective flip on every card reveal is the single most satisfying part of the app. Reanimated’s worklet system runs on the native thread, which means the animation stays smooth even when Firebase is doing something slow in the background. The full hook is about 40 lines:

export function useCardAnimation() {
  const rotation = useSharedValue(0);
  const isFlipped = useSharedValue(false);

  const flip = useCallback(() => {
    rotation.value = withTiming(180, {
      duration: 600,
      easing: Easing.inOut(Easing.ease),
    });
    isFlipped.value = true;
  }, [rotation, isFlipped]);

  const frontAnimatedStyle = useAnimatedStyle(() => ({
    transform: [{ perspective: 1000 }, { rotateY: `${rotation.value + 180}deg` }],
    backfaceVisibility: "hidden",
    position: "absolute",
  }));

  const backAnimatedStyle = useAnimatedStyle(() => ({
    transform: [{ perspective: 1000 }, { rotateY: `${rotation.value}deg` }],
    backfaceVisibility: "hidden",
    position: "absolute",
  }));

  return { flip, reset, frontAnimatedStyle, backAnimatedStyle };
}

For state management: Context and useReducer, no Redux or Zustand. The game logic lives in a single gameReducer function with typed actions. Making that reducer pure and stateless was the right call. The same function drives both local games and Firebase-synced multiplayer, which meant I only had to get the game logic right once.

Google Mobile Ads for monetization. EAS (Expo Application Services) for building and distributing.

The hard part: Firebase multiplayer sync

Multiplayer was harder than I expected.

The architecture works like this: one player is the host. When the host takes an action, the reducer runs locally and the result gets written to Firebase. When a non-host player takes an action, they write to a pendingAction path instead. The host sees that, runs the reducer, and writes the result back. Everyone subscribes to the same game state and re-renders when it changes.

Simple in theory. Firebase had other ideas.

Firebase Realtime Database will silently mangle your data. Empty arrays become undefined. Arrays with items come back as objects with numeric keys ({ 0: card, 1: card }). Fields that were never set come back as null. After the first multiplayer bug, where player cards were disappearing between rounds, I added a normalizeGameState() function that runs on every single read from Firebase:

function normalizeGameState(state: GameState | null): GameState | null {
  if (!state) return null;

  const toArray = <T>(val: T[] | Record<string, T> | null | undefined): T[] => {
    if (!val) return [];
    if (Array.isArray(val)) return val;
    // Firebase turned your array into { 0: item, 1: item }
    return Object.values(val);
  };

  // Ensure we have one playerCards array per player, even if Firebase
  // deleted empty arrays for players who haven't drawn yet
  const players = toArray(state.players);
  const rawPlayerCards = toArray(state.playerCards);
  const normalizedPlayerCards = players.map((_, index) =>
    toArray(rawPlayerCards[index])
  );

  return {
    ...state,
    currentCard: state.currentCard ?? null,
    currentGuess: state.currentGuess ?? null,
    players: toArray(state.players),
    deck: toArray(state.deck),
    playerCards: normalizedPlayerCards,
    pyramidCards: toArray(state.pyramidCards),
    pyramidRevealed: toArray(state.pyramidRevealed),
    pendingDrinkAssignments: toArray(state.pendingDrinkAssignments),
    pyramidPendingAssigners: toArray(state.pyramidPendingAssigners),
  };
}

This fixed the disappearing cards. It also introduced a related pattern in the reducer itself: using loose equality (!=) to guard against both null and undefined from Firebase, since you can’t always control which one you get:

case "MAKE_GUESS": {
  // Use != (loose) to catch both null AND undefined from Firebase
  if (state.phase !== "playing" || state.currentCard != null) {
    return state;
  }
  // ... process the guess
}

The other piece that took real time was the pending action pattern. The host needs to process actions from non-host players in order and exactly once. I ended up timestamping each pending action and tracking the last processed timestamp in a ref to prevent double-processing. Overkill for a card game, but multiplayer drink assignments cannot afford to double-count.

The App Store saga

Submitted. Rejected. Guideline 1.4.3: apps that encourage or enable excessive consumption of alcohol.

Fair. I updated the metadata. Removed the word “drinking.” Resubmitted.

Rejected again.

Reframed the entire listing as a “party card game.” Positioned the drink mechanic as optional social scoring. Resubmitted.

Rejected again.

Removed all references to alcohol from screenshots and description. The listing described it as a card guessing game where correct answers mean you give points to other players. Nothing about drinking anywhere.

Rejected again.

Apple’s position seems to be: if the game mechanic is drinking, it qualifies under 1.4.3 regardless of how the metadata describes it. The game is the game.

At some point I had to decide whether to keep fighting over a free app. I didn’t. I moved on.

Where it lives now

smokeorfire.travelvient.com

Expo Web support meant the app already ran in a browser. The card flip animations work in Chrome. Multiplayer works. No install required. You text someone the link and you’re playing.

It’s slightly bittersweet that it never made it into the App Store, but the web version is genuinely fine. More than fine, actually. Anyone with a browser can play it, which is more people than would ever find it in the App Store anyway.

Source code is on GitHub if you want to dig into the multiplayer architecture or use the Firebase normalization pattern.

What I’d do differently

Start with web as the primary target if there’s any chance the App Store might reject your app. I built a full React Native app and discovered the main distribution channel was closed to me. The web fallback worked, but it was a fallback, not a plan.

Use Firestore instead of Realtime Database. Firebase Realtime Database works, but the normalization overhead was significant. Firestore returns data in a format that doesn’t mangle your arrays, and the query model is better for structured game state.

Write tests for the reducer. The game state logic got complex, especially the pyramid drink assignment across multiple players in real time. I tested it manually as I built it, which worked until it didn’t. A test suite for gameReducer would have caught several multiplayer bugs before they reached production.

The game is out there. People play it. That part worked.

Related: Smoke or Fire and more side projects.