DEV Community: Vientapps

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

Vientapps — Sat, 25 Apr 2026 14:02:39 +0000

Lighthouse doesn't check if ChatGPT can crawl your site. So I built ShipReady, an SEO and AEO scanner that audits your site for the age of answer engines.

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 vientapps.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 Let Claude Design My Homepage Hero and Shipped What It Built

Vientapps — Fri, 24 Apr 2026 17:25:31 +0000

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.

Two Lines of HTML Give Any Travel Blog or Website a Live Carry-On Size Checker for 75 Airlines

Vientapps — Tue, 21 Apr 2026 16:03:08 +0000

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.

What it does

The carry-on size embed widget is a drop-in carry-on bag size checker for any website. Two lines of HTML. No accounts, no API keys, no tracking.

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:

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 https://vientapps.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. Three more embeddable widgets are planned: cruise cabin size checker, checked bag fee calculator, and an airline comparison table.

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.

Building the Carry-On and Personal Item Size Checkers

Vientapps — Sat, 18 Apr 2026 20:31:55 +0000

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 hand-verified file. 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/airlines/[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: Spirit, 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.

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 Replaced /usage and /context in Claude Code With a Single Statusline

Vientapps — Fri, 17 Apr 2026 18:27:24 +0000

You already run /usage and /context all day. This bash statusline puts both, plus your 5h reset time and working directory, at the bottom of every Claude Code prompt as colored progress bars. Exact script inside.

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.

I asked Claude to build mine. It took four rounds of back-and-forth to land it where I wanted. Here's what I ended up with and why.

What the 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 fastest way to get this setup

If you want the exact statusline I have without hand-editing bash, paste this into any Claude Code session and let it do the work:

Set up my Claude Code statusline to show my working directory folder name, my 5-hour usage as a severity-colored progress bar with the reset time next to it, my 7-day usage as a severity-colored progress bar, and my context window as a severity-colored progress bar. Green under 50%, yellow 50 to 80%, red above 80%. Write a bash script at ~/.claude/statusline-command.sh and register it in ~/.claude/settings.json.

Claude Code ships with a statusline-setup agent that's purpose-built for this. That prompt will trigger it and you'll have the same setup in a minute or two. If it picks defaults you don't like, say "now change this" and iterate.

The whole script, if you want mine

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.

The output looks like this on my machine:

Folder first, then 5h with its reset time, then 7d, then context. The bars shift from green to yellow to red as the meters fill up, so I can scan the line without reading 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.

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

Vientapps — Wed, 15 Apr 2026 22:19:16 +0000

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.

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

Vientapps — Mon, 13 Apr 2026 20:56:48 +0000

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.

Building Roamly: AI-Powered Group Travel Planning

Vientapps — Thu, 09 Apr 2026 16:12:03 +0000

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.vientapps.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.

DEV Community: Vientapps

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

What It Does

The Stack

The Hard Part: Parsing HTML Without a DOM

The False Positives

The AEO Category

Where It Is Now

What I'd Do Differently

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

The "decide for me" conversation

Two concepts, not one

What I shipped

Where Claude surprised me

Where Claude fell short

The hardest part

What I would do differently

Two Lines of HTML Give Any Travel Blog or Website a Live Carry-On Size Checker for 75 Airlines

What it does

How I worked with Claude on this one

The stack

The hard part: iframe auto-resize

Where Claude surprised me

Where Claude fell short

What went wrong overall

Where it is now

What I would do differently

Building the Carry-On and Personal Item Size Checkers

What they do

The stack

The hard part: bag orientation

The "not published" problem

What went wrong

Where it is now

What I would do differently

I Replaced /usage and /context in Claude Code With a Single Statusline

What the statusline actually is

How I worked with Claude on this one

The stack

The bars

Drawing a 10-slot bar in pure shell

The reset timestamp

Where Claude surprised me

Where Claude fell short

The fastest way to get this setup

The whole script, if you want mine

Styling tips

Where it is now

What I'd do differently

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

What it does

The stack

Continuous transcription

On-device vs. network fallback

Silencing the no-speech error

The hard part: App Store paperwork

Where it is now

What I'd do differently

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

What it does

The stack

The prompt that drives the whole thing

Nine ways to say no

Gap protection

What went wrong

Where it is now

What I'd do differently

Building Roamly: AI-Powered Group Travel Planning

What it does

The stack

The hard part: getting the AI to behave

Streaming and recovery

What went wrong: Cloudflare

Where it is now

What I'd do differently

Silencing the `no-speech` error