Forem: camb

Our content engine now outputs 4K lossless WebM because I solved an RGBA problem that was killing quality!

camb — Sat, 11 Apr 2026 22:25:29 +0000

camb

Apr 11

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

#javascript #webdev #node #ffmpeg

Comments

4 min read

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

camb — Sat, 11 Apr 2026 01:31:54 +0000

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

I've been building a content engine that renders HTML/CSS graphics to transparent video overlays — the kind you drop on a timeline in CapCut or Premiere with a drop shadow, gradient text, and a glow. Clean, professional, automated.

It worked great in the browser. It worked fine as a WebM preview. And then the moment I imported it into any video editor, every single shadow and glow rendered as a solid colored blob.

Days of debugging later, I found the fix — and it's a technique from 1970s film compositing.

The Problem

The pipeline was straightforward:

Generate HTML/CSS graphics with Playwright (headless Chrome)
Screenshot each frame with omitBackground: true to get transparent PNGs
Stitch frames into WebM or ProRes 4444 with FFmpeg
Import into CapCut and composite over video

The shadows looked perfect in the browser. Correct in the WebM preview in Chrome. But inside CapCut — or any NLE — they showed up as hard-edged solid blobs. A filter: drop-shadow(0 0 20px rgba(123,97,255,0.7)) that should be a soft purple halo was rendering as a solid purple rectangle.

What's Actually Happening

Premultiplied vs. Straight Alpha

There are two ways to store RGBA pixel data.

Straight alpha — RGB and alpha are independent:

pixel = (R, G, B, A)

Premultiplied (associated) alpha — RGB is already multiplied by alpha:

pixel = (R×A, G×A, B×A, A)

Chrome composites internally using premultiplied alpha. When you call page.screenshot({ omitBackground: true }), it has to convert from premultiplied back to straight alpha for the PNG export. That conversion is lossy at very low alpha values. The soft glow edge pixels at 2%, 5%, 8% opacity either round to zero or get the wrong color.

ProRes 4444 is specced for premultiplied alpha — that's what NLEs expect. So you're encoding already-corrupted data into a format that assumes clean data. The NLE reads it, assumes premultiplied, and composites incorrectly.

The `background-clip: text` Problem

Separately, background-clip: text + text-fill-color: transparent has a rendering bug in headless Playwright with omitBackground: true. Instead of gradient-colored text on a transparent background, Chrome renders a solid gradient rectangle with the letter shapes punched out as transparent holes. The complete inverse of what you want.

Approaches That Don't Work

Banning the CSS — Just ban filter:, rgba(), text-shadow. Only fully opaque or fully transparent pixels. This makes the alpha clean but the graphics flat and lifeless. Not usable.

Fixing the FFmpeg encode:

ffmpeg -i input_%06d.png \
  -vf "premultiply=inplace=1" \
  -c:v prores_ks -profile:v 4444 \
  -pix_fmt yuva444p10le -alpha_bits 16 \
  output.mov

This helps at the codec level. But the source PNGs from omitBackground: true are already broken before FFmpeg touches them. You're premultiplying corrupted data.

The Fix: Background Subtraction

The insight: you don't need the browser to give you alpha at all.

Render each frame twice — once on solid black, once on solid white. The browser renders both correctly because it's just rendering a webpage on a known background. No alpha pipeline involved.

Then derive the correct RGBA for every pixel using the Porter-Duff equations.

The Math

Given a foreground pixel with color fg and alpha α:

On black (0,0,0):

rendered_black = fg × α

On white (255,255,255):

rendered_white = fg × α + 255 × (1-α)

Subtract:

white - black = 255 × (1-α)
α = 1 - (white - black) / 255
α (0–255) = 255 - (white - black)
fg = black / α

This is exact for every pixel at every opacity level — including the 2% opacity glow edges that omitBackground was mangling. This technique is called background subtraction or difference matting. It's been in film VFX since the 1970s.

Implementation

import sharp from 'sharp';

async function extractAlpha(blackBuf, whiteBuf) {
  const [b, w] = await Promise.all([
    sharp(blackBuf).removeAlpha().raw().toBuffer({ resolveWithObject: true }),
    sharp(whiteBuf).removeAlpha().raw().toBuffer({ resolveWithObject: true }),
  ]);
  const { data: bD, info } = b;
  const { data: wD } = w;
  const N = info.width * info.height;
  const out = Buffer.alloc(N * 4);

  for (let i = 0; i < N; i++) {
    const s = i * 3, d = i * 4;
    const bR = bD[s], bG = bD[s+1], bB = bD[s+2];
    const wR = wD[s], wG = wD[s+1], wB = wD[s+2];

    // Per-channel alpha — take max for best color recovery
    const alpha = Math.max(0, Math.min(255, Math.max(
      255 - (wR - bR),
      255 - (wG - bG),
      255 - (wB - bB)
    )));

    if (alpha < 4) {
      out[d] = out[d+1] = out[d+2] = out[d+3] = 0;
    } else {
      const a = alpha / 255;
      out[d]   = Math.min(255, Math.round(bR / a));
      out[d+1] = Math.min(255, Math.round(bG / a));
      out[d+2] = Math.min(255, Math.round(bB / a));
      out[d+3] = alpha;
    }
  }

  return sharp(out, { raw: { width: info.width, height: info.height, channels: 4 } })
    .png().toBuffer();
}

In the Capture Loop

// OLD
await page.screenshot({ path: framePath, type: 'png', omitBackground: true });

// NEW
await page.evaluate(() => {
  document.documentElement.style.background = '#000000';
  document.body.style.background = '#000000';
});
const blackBuf = await page.screenshot({ type: 'png' });

await page.evaluate(() => {
  document.documentElement.style.background = '#ffffff';
  document.body.style.background = '#ffffff';
});
const whiteBuf = await page.screenshot({ type: 'png' });

const rgbaBuf = await extractAlpha(blackBuf, whiteBuf);
await fs.writeFile(framePath, rgbaBuf);

FFmpeg Encode

await execFileAsync('ffmpeg', [
  '-y', '-framerate', '30', '-i', 'frame%06d.png',
  '-vf', 'premultiply=inplace=1',
  '-c:v', 'prores_ks', '-profile:v', '4444',
  '-pix_fmt', 'yuva444p10le', '-alpha_bits', '16',
  'output.mov',
]);

One Remaining Gotcha

Don't put overflow: hidden on a parent that directly wraps a filter: element. Chrome's filter compositing layer gets clipped by the overflow boundary, producing a visible white rectangle around your element.

/* WRONG */
.row { overflow: hidden; }
.word { filter: drop-shadow(...); }

/* CORRECT — let body/html handle the viewport clip */
.row { /* overflow: visible by default */ }
body { overflow: hidden; }

Result

filter: drop-shadow, text-shadow, background-clip: text, rgba() at any opacity — all render cleanly as transparent video with correct alpha in CapCut, Premiere, and DaVinci.

The tradeoff is 2× the frame captures. For a 6-second clip at 30fps that's 360 screenshots instead of 180. About 90 extra seconds of render time. Acceptable for production output.

The browser was always rendering correctly. The only problem was how we were asking for the pixel data.

The fix isn't in the encoding. It's in the capture.

Video included!

camb — Fri, 03 Apr 2026 23:01:28 +0000

camb

Apr 3

I Built a HIPAA-Compliant CMS with Bolt and Xano

#hipaa #xano #healthcare #startup

Comments

3 min read

I Built a HIPAA-Compliant CMS with Bolt and Xano

camb — Fri, 03 Apr 2026 23:01:07 +0000

If your app touches health data, the rules are different. HIPAA is a federal law, and violations come with real consequences. Not bug reports. Regulators.

I built a full HIPAA-compliant content management system. Bolt for the frontend, Xano for the backend. Now, I want to walk through how it works.

I also made a video covering this if you'd rather watch:

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole thing took only a couple days. Made a video walking through the build and breaking down what HIPAA actually requires if you're a developer. Are you building a healthcare app? Let me know in the comments 👇

linkedin.com

What HIPAA actually requires from developers

HIPAA (Health Insurance Portability and Accountability Act) governs how Protected Health Information (PHI) is stored, transmitted, and accessed. PHI is any data that identifies a person and relates to their health: name, date of birth, diagnosis, insurance ID, even an IP address in certain contexts.

If your app stores any of this, you need encryption, access controls, audit logging, and legal contracts (BAA/BASA) with every vendor in the chain.

The stack

Frontend: Built in Bolt. One prompt describing the CMS I needed, pointed at my Xano API, working UI in minutes.

Backend: Xano, with HIPAA addon enabled. The workspace runs on an isolated, hardened server on Google Cloud (which is itself HIPAA certified). All traffic encrypted in transit over TLS.

Field-level encryption

Encryption isn't just a database-wide toggle. In this CMS, sensitive fields are individually encrypted using AES-256. A patient's diagnosis, their SSN.. each field is encrypted independently.

In the Xano function stack, the encryption logic looks like this:

Create Variable: aes_key = env:HIPAA_AES_KEY
Create Variable: aes_iv  = env:HIPAA_AES_IV
Create Variable: decrypted = AES decrypt(encrypted_value, aes_key, aes_iv)

Even if someone with database access can see the table, they can't read encrypted field values without the decryption key. The key lives in environment variables, never in the function stack itself.

Two layers of access control

This is the part I think matters most.

Layer 1: What we built. At the application level, we implemented our own role-based access control as middleware and our own audit logging.

Every API endpoint runs through a precondition check. If a non-admin user tries to hit a protected endpoint:

{
  "code": "ERROR_CODE_ACCESS_DENIED",
  "message": "Admin privileges required to access this resource."
}

That's not Xano blocking them. That's our code!

Layer 2: What Xano provides. Underneath everything we built, Xano has its own RBAC and audit logging built into the platform. Every workspace action is tracked. Who did what, when, what changed. Platform-level access controls govern who can even see the workspace.

Two independent layers. The platform enforces compliance at the infrastructure level. The app enforces it at the application level. That's what a HIPAA audit wants to see.

Audit logs

Same two-layer principle. Xano tracks every workspace action automatically. But we also built application-level audit logs: who published an article, who edited a patient record, who changed permissions. And you control who can access those logs — compliance officer gets read-only, lead dev gets full access, junior dev sees nothing.

The contracts: BAA and BASA

Any vendor touching PHI signs a Business Associate Agreement (BAA). But if a dev team was hired by a hospital and that team works with Xano, the right instrument is a BASA — Business Associate Subcontractor Agreement. Xano offers both.

Making changes safely

Healthcare apps need safe deployment workflows. In Xano, you can branch your workspace, make schema changes in isolation, test your API calls against the new structure, and confirm your frontend handles it before anything goes live. If something breaks, one click rolls back to the previous version.

Shared responsibility

One thing worth being direct about: HIPAA compliance is a shared responsibility. Xano provides the compliant infrastructure. But you're still responsible for your own policies, access controls, employee training, and incident response. The infrastructure doesn't make you compliant on its own. You have to use it correctly.

Try it

If you're building a healthcare product, Xano's HIPAA plan gives you the infrastructure and Bolt gets you a frontend fast.

I covered the full build in a video —

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

linkedin.com

Want to see a webinar on how I did this? Drop a comment!

Building a B2A Platform: The Agentic Architecture of "Sh*t My Dev Says"

camb — Fri, 27 Mar 2026 17:40:27 +0000

I Built a Platform Where Agents Are the Primary Users

I launched Shit My Dev Says recently.

The concept is simple: a curated collection of developer quotes, rants, hot takes, war stories, gossip, updates and more, submitted by AI agents and humans alike. Once a week, on Monday morning, an edited newsletter is sent out to subscribers, updating them on the reported chaos.

I call it The State of the Chaos

Similar to Moltbook, fused with fmylife from the 2010s, and inspired by the landscape of the future, I wanted to create a platform that was fueled by humans and their voices, but reported on by agents.

The Stack

Frontend: Vanilla HTML, CSS, JavaScript
Backend: Xano
Hosting: Namecheap shared hosting, Apache
SEO Layer: PHP

No React. No build pipeline. Very minimal.

I made a deliberate decision to remain simple. Call it obstinance or staying stuck in my old ways, but being raised on HTML, CSS, and vanilla JS with some PHP does something to the brain. There's another post to be had about frameworks, but the idea was to stay simple.

The Backend

Obviously the name has stopping power, but what actually drives the platform is the agentic aspect.

B2A. The future.

Firstly, humans can participate, but humans are much more of the enjoyers of content in this context. I mention this because both humans and agents alike can submit posts via an exposed API endpoint.

So, Xano handles the API layer, and Xano also handles the MCP layer.

The MCP server supports three tools: save, upvote, downvote.

Remember: simple.

_(Also yes, your Agents can participate) _

Secondly, I made this architectural decision because Xano also handles the orchestration for the agentic processes.

Beyond the database, API layers, and MCP server, there's an entire agent network that acts as users, moderators, and authors for the newsletter.

I could have even used Xano's static hosting, but I set up a quick shared hosting site where I had purchased the domain (using Namecheap) and pushed my files.

That's the cool part about using a headless backend. I can take it anywhere.

That's also the power of Xano: it's a self-contained system that fully supports backend development at an enterprise level. A multilayered system that, importantly, handles the infrastructure.

I can speak all day about Xano. It's the system to use for backends, complete with its position as the ultimate governance layer for development. If you can see what's happening, you can understand what's happening.

The Newsletter

The real fun, and arguably the entire reason this exists, is to let the human consume & relish in the craziness of the AI space without needing to doomscroll... Unless you want to.

Each Monday, subscribers start off their day by receiving the ShitMyDevSays newsletter.

The entire premise is for the human to digest the absurd, the craziness, and the entire world of AI, in bite size pieces, paired with witty and irreverent commentary.

Tons of newsletters exist. The wheel has already been invented. It's not about reinventing anything.

It's about making the wheel... different. Change the size, the materials. Maybe add spinners? Ultimately, don't reinvent anything, just use what works and make it your own.

So, in pursuit of this spirit, I set out to use AgentMail for my mail and mail delivery system.

AgentMail, built for B2A, is the Gmail for Agents. It allows my agents access to inboxes, responses, labels, and more. It's what also handles any inbound messaging for contacts and sponsors. It's autonomous when my system allows it to be, and similar to Xano, offers a visual interface to let me see what's actually happening. Built for agents, for humans.

Similar to the premise of the entire SMDS system.

What's the plan?

Well, until the heat-death of the universe, it's likely that shitmydevsays.com will remain live and active, acting as a memoir to the early days of B2A. With a nod to the sites that I was raised on, the purpose is to exist as a platform for entertainment.

I think a fascinating aspect about this project is also how it can be used to receive pulses on the industry. The newest things, the craziest stories. It's supposed to act as a platform that entertains, but also as a source of information.

The intention is to truly leverage two of my favorite platforms to have fun participating on the internet. Did you know you can just buy domain names?

Building a B2A Platform: The Agentic Architecture of "Sh*t My Dev Says"

camb — Fri, 27 Mar 2026 17:40:27 +0000

I Built a Platform Where Agents Are the Primary Users

I launched Shit My Dev Says recently.

I call it The State of the Chaos

The Stack

Frontend: Vanilla HTML, CSS, JavaScript
Backend: Xano
Hosting: Namecheap shared hosting, Apache
SEO Layer: PHP

No React. No build pipeline. Very minimal.

The Backend

Obviously the name has stopping power, but what actually drives the platform is the agentic aspect.

B2A. The future.

So, Xano handles the API layer, and Xano also handles the MCP layer.

The MCP server supports three tools: save, upvote, downvote.

Remember: simple.

_(Also yes, your Agents can participate) _

Secondly, I made this architectural decision because Xano also handles the orchestration for the agentic processes.

Beyond the database, API layers, and MCP server, there's an entire agent network that acts as users, moderators, and authors for the newsletter.

I could have even used Xano's static hosting, but I set up a quick shared hosting site where I had purchased the domain (using Namecheap) and pushed my files.

That's the cool part about using a headless backend. I can take it anywhere.

That's also the power of Xano: it's a self-contained system that fully supports backend development at an enterprise level. A multilayered system that, importantly, handles the infrastructure.

The Newsletter

The real fun, and arguably the entire reason this exists, is to let the human consume & relish in the craziness of the AI space without needing to doomscroll... Unless you want to.

Each Monday, subscribers start off their day by receiving the ShitMyDevSays newsletter.

The entire premise is for the human to digest the absurd, the craziness, and the entire world of AI, in bite size pieces, paired with witty and irreverent commentary.

Tons of newsletters exist. The wheel has already been invented. It's not about reinventing anything.

It's about making the wheel... different. Change the size, the materials. Maybe add spinners? Ultimately, don't reinvent anything, just use what works and make it your own.

So, in pursuit of this spirit, I set out to use AgentMail for my mail and mail delivery system.

Similar to the premise of the entire SMDS system.

What's the plan?

The intention is to truly leverage two of my favorite platforms to have fun participating on the internet. Did you know you can just buy domain names?

Amazon Lost 6.3 Million Orders Because Nobody Reviewed the Code. Here's What Governance Actually Looks Like.

camb — Fri, 20 Mar 2026 07:42:41 +0000

On March 5th, Amazon's North American marketplace saw a 99% drop in orders. 6.3 million orders gone. Not because of a hack. Not because of a natural disaster. Because someone pushed a production change without documentation or approval.

Three days earlier, on March 2nd, their AI coding assistant Q gave an engineer inaccurate advice pulled from an outdated internal wiki. That change went live. 120,000 lost orders. 1.6 million website errors. Globally.

Amazon's SVP of e-commerce stood up and said what everyone was thinking: "The availability of the site and related infrastructure has not been good recently."

understatement of the quarter.

They've now initiated a 90-day "code safety reset" across 335 Tier-1 systems. Senior engineers are now required to approve AI-assisted code changes before deployment. Directors and VPs have been instructed to audit all production code change activities within their organizations. Mandatory deep-dive meetings. Stricter documentation. "Controlled friction."

In other words: the largest e-commerce company on the planet, with some of the best engineers alive, just discovered they need governance.

The Word Nobody Wants to Say

Governance has a bad reputation. It sounds like bureaucracy. It sounds like the word your VP uses to justify a three-week approval chain on a CSS change.

But governance isn't bureaucracy. Governance is a system knowing what it's allowed to do, who's allowed to do it, and having a record of everything that happened.

Amazon didn't have that for some of its most critical paths. A single authorized operator could execute a high-impact configuration change without a second pair of eyes. AI-assisted changes were going straight to production without guardrails. Internal documents admitted that generative AI tooling "accelerated exposure of sharp edges and places where guardrails do not exist."

The code wasn't the problem. The absence of structure around the code was the problem.

Executives Are Now Doing What the Architecture Should Have Done

Here's the thing that should concern every engineer reading this: Amazon's response to the crisis was to put humans in the loop. Senior engineers now review AI-generated code. Directors audit deploys. Mandatory meetings happen weekly.

This works. In the short term. But it doesn't scale.

A senior engineer reviewing code is not a governance layer. It's a bottleneck with institutional knowledge. When that engineer is sick, on vacation, or just burnt out from reviewing 47 AI-generated PRs before lunch. And then system breaks again.

The real fix isn't "make a person approve it." The real fix is building systems where the rules are enforced structurally, where state is tracked centrally, where changes are auditable by default, and where no single human decision can cascade into a 6.3-million-order catastrophe.

That's what a governance layer does. And I'll be honest, this is exactly why I've been calling Xano a governance layer and not just a "backend."

What a Governance Layer Actually Looks Like

I've written about this before when I talked about building ChatClipThat, but the Amazon situation makes the argument way more concrete.

A governance layer does five things:

1. Centralized State
Every service, every worker, every node talks to one source of truth. Not a local database. Not an in-memory cache. One centralized place where state lives. When my GPU render node finishes a clip, it doesn't write to a local file. It PATCHes a record in Xano. If the node dies, the state survives.

Amazon's problem wasn't just bad code. It was that a change to one system cascaded into everything because nothing was mediating the state between services.

2. Enforced Rules at the Platform Level
Input validation. Authentication. Role-based access. Rate limiting. These shouldn't be things you remember to implement. They should be things the platform gives you by default.

In Xano, every API endpoint has built-in input validation and authentication. You don't "forget" to add auth to a new endpoint because the platform asks you to configure it during creation. You don't push a field update without it immediately being reflected in the API contract and the Swagger docs.
Compare that to Amazon, where an engineer followed bad advice from an AI tool and nothing between them and production said "wait, are you sure?"

3. Auditable Changes
Every modification to a table, endpoint, or logic flow in Xano is versioned. You can see what changed, when, and roll back if needed. You don't need a VP to "audit all production code change activities" because the platform maintains that history structurally.

When Amazon says they're now requiring "more extensive documentation for critical code changes": they're admitting this didn't exist before, at least not in a way that caught these issues. A governance layer makes documentation a byproduct of working, not a separate chore you assign to exhausted engineers.

4. Separation of Code and Configuration
One of the most undervalued aspects of Xano is that the backend isn't a repo. It's a workspace. You configure logic, data models, and endpoints through a structured interface. That means you can't accidentally rm -rf your way into a production incident. The blast radius of a mistake is inherently smaller because the platform constrains what a change can touch.

You can, and I do, use GitHub to sync my workspace into my private repo. That's totally doable. But it's also not quite the point.

Amazon's March 5th outage happened because "a production change bypassed formal documentation and approval processes." In a governed system, there is no "bypassing." The process is the system.

5. The Visual Layer Is the Validation Layer
This is the one people overlook. In a traditional codebase, logic lives in text files. You validate it by reading it. Line by line. Hoping you catch what the last person (or the last AI) changed across a 400-line diff.

In Xano, the logic is visual. You're looking at function stacks, conditional branches, loops, and data transformations rendered as structured flows. You don't read the logic. You see it. And that changes everything about how mistakes get caught.

When logic is visual, it becomes inherently reviewable. A product manager can look at a flow and ask "why does this branch exist?" A new engineer can trace the path a request takes without deciphering someone else's variable naming conventions. The visual interface isn't just a convenience feature. It's a validation mechanism. It forces the logic to be legible by default.

And critically, the visual representation is the documentation. There's no separate wiki to maintain. No outdated internal doc that contradicts what the code actually does (which is exactly what tripped up Amazon's AI assistant). The thing you build in is the thing you review. The interface is the truth.

For governance, this matters more than people think. When you can see every step of a logic flow at a glance, the blast radius of any change is immediately apparent. You don't need a senior engineer to mentally compile 200 lines of Python to understand what a change touches. You look at the flow and it's right there.

The AI Problem is a Governance Problem

Here's where this gets interesting for anyone using AI coding assistants (which is basically everyone in 2026).

Amazon's internal documents noted that generative AI accelerated the exposure of gaps in their safety infrastructure. AI didn't create the gaps. AI just found them faster. And when it found them, there was nothing to stop the damage.

This is the thing nobody talks about with AI-assisted development: the code an AI writes is often syntactically correct, confidently written, and completely unaware of your system's context. It doesn't know about unwritten constraints. It doesn't know about that deprecated internal wiki that hasn't been updated since Q3 2024. It doesn't know that this specific config change affects 335 downstream systems.

Pull request sizes are growing. Incidents per PR are increasing. Change failure rates are climbing. The bottleneck isn't code generation anymore. It's review. And review doesn't scale when the governance is a person instead of a system.

This is why I keep talking about platforms that enforce structure. Not because I hate writing code. Because when AI is generating code at scale, the thing that protects you isn't the code review. Typically, it's the system that catches what the reviewer missed.

Who This Is Actually For

Amazon has 30,000+ engineers. They'll figure it out. They'll build internal tooling, add approval chains, and eventually make this a solved problem in their stack.

But most of us aren't Amazon. We're teams of 3, or 10, or we're solo. We don't have the luxury of 90-day resets, mandatory VP audits, or a dedicated platform reliability team.

And we're using the same AI coding tools. Generating the same volume of code. With the same risk of blindly deploying something that an AI confidently told us was correct.

The difference is whether your architecture has built-in guardrails or whether you're relying on someone to remember to check.

I use Xano because it gives me governance at the platform level. Input validation, auth, versioned logic, centralized state, structured endpoints. Not because I'm building at Amazon's scale. Because I'm building without Amazon's team, and I need the platform to do what their 335 Tier-1 system review process is now scrambling to do manually.

The Takeaway

Amazon didn't have a code quality problem. They had a governance problem. The code was fine until it hit production without anyone knowing what it touched.

The 90-day code safety reset is the right move. Requiring senior engineer review is the right move. But both of those are human solutions to a systems problem. And human solutions degrade when the humans get tired, distracted, or overwhelmed by the volume of AI-generated changes hitting their desks.

Build systems where governance is structural, not procedural. Where the rules are enforced by the platform, not by a person's memory. Where a bad change can't cascade because the architecture constrains its blast radius.

Or, you know, lose 6.3 million orders and then do it anyway.

[Boost]

camb — Fri, 20 Mar 2026 05:11:17 +0000

The Pillars Behind a Solo-Built AI Platform

camb ・ Mar 19

#xano #ai #webdev

[Boost]

camb — Thu, 19 Mar 2026 17:10:46 +0000

The Pillars Behind a Solo-Built AI Platform

camb ・ Mar 19

#xano #ai #webdev

The Pillars Behind a Solo-Built AI Platform

camb — Thu, 19 Mar 2026 08:57:49 +0000

I built an AI video clipping platform called ChatClipThat. You give it a Twitch VOD (sometimes 4+ hours long) and it finds the best moments, generates titles, adds karaoke-style animated captions, and renders them as vertical clips ready for TikTok (pending), Shorts, and Reels.

I'm actively developing and testing live clipping. While a stream is happening, it watches via a VLM every 30 seconds, moments in real time, and creates clips on the fly. If a streamer says "clip that," the audio trigger system catches it and clips the moment immediately.

There's a dense and multi-stage AI pipeline behind this. Parallel GPU rendering. A three-machine hybrid cluster. Stripe billing. A real-time video editor with face tracking, caption styling, and per-user brand templates.

I built this by myself.

Not because I'm some 10x engineer. I'm genuinely not. I don't have a CS degree. I have ADHD and a tendency to ship things before they're ready. The reason I could build something this complex alone is because of the platforms I chose to build on.

I want to talk about those platforms and tech. The supporting pillars. Because your stack choices aren't just technical decisions. They're velocity multipliers or velocity killers. And for me, the biggest multiplier by far has been Xano.

Pillar 1: Xano — The Governance Layer

Every complex system needs governance. Not bureaucracy. Governance. Something that decides who can do what, tracks the state of everything, enforces the rules, and gives every part of the system a shared understanding of reality. In a traditional setup, this means standing up a database, writing an ORM layer, building REST endpoints, implementing auth, designing migrations, and maintaining all of it.

I didn't do any of that. I use Xano.

Xano is my governance layer. It gives me a visual database, server-side logic (XanoScript), instant REST APIs with input validation and Swagger docs, and built-in JWT authentication. But calling it a "backend" undersells what it actually does in a system like mine. It's the thing that keeps a distributed, multi-machine AI platform organized.

When my CPU analysis node finishes processing a VOD, it doesn't write to a local database. It POSTs the results to Xano. When my GPU render node finishes a clip, it PATCHes the clip record in Xano with the output URL. When the live monitoring engine deducts a credit every 60 seconds, it calls a Xano endpoint. When the frontend needs to show a user their jobs, templates, or clips — Xano.

Every machine in my cluster talks to the same Xano instance. That means every machine is stateless. If one crashes, the state is safe. If I need to scale a node, I just point the new one at the same API. The workers don't know about each other. They only know about Xano.

This is a legitimate distributed systems pattern (centralized state with stateless workers) and I implemented it without writing a single line of backend infrastructure code. I just designed my tables, wrote the logic in XanoScript, and every node talks to the resulting API.

The result is that I have 15+ database tables, multiple API groups, and full authentication powering a production SaaS.

Pillar 2: GCP — The Muscle

Google Cloud gives me the compute I can't run locally. An e2-standard-4 CPU instance handles the heavy AI analysis. An NVIDIA L4 GPU instance handles video rendering with hardware acceleration. Google Cloud Storage holds every VOD, metadata, artifact, and rendered clip.

The key decision was splitting the work across purpose-built machines. Analysis requires CPU and memory. Rendering requires a GPU. The VPS handles web traffic. Each node does one thing well and talks to Xano for coordination.

I spent a lot of time fighting GCP — zone resource exhaustion, disk space problems, firewall misconfigurations, IAP tunnel race conditions. But the underlying model works: cheap CPU for analysis, expensive GPU on-demand for rendering, and Xano as the coordinator between them.

Pillar 3: The AI Layer

The AI models are the product. They're what actually watches the video, understands what's happening, and decides what's worth clipping. I won't go deep on the specifics here, but the pipeline uses a combination of vision models, transcription, and audio analysis to find moments worth sharing.

The important thing in the context of this article isn't how the AI works. It's that AI outputs are useless without infrastructure to organize them. A model can tell you "something interesting happened at 47 minutes." Cool. Now where does that data go? How does the editor access it? How does the renderer know what to render? That's where the other pillars come in.

Pillar 4: The Vibe Coding Philosophy

This is the meta-pillar. The reason any of this works is because I optimized for speed of iteration, not perfection of architecture.

I use FastAPI with Jinja2 server-side rendering instead of a React frontend because I can ship a page in 20 minutes. I use Alpine.js for reactivity because it's 15 lines of JavaScript instead of a component tree. I use vanilla CSS where I need control and Tailwind where I need speed.

The pipeline is modular. Every stage is a Python class with name() and run(ctx).

If a stage breaks, I replace it. If I want to test a new ranking algorithm, I swap one class. The architecture isn't elegant. It's fast to change.

And this philosophy extends to the backend choice. Xano lets me iterate on data models without writing migration scripts. If I need a new field on the jobs table, I add it in the visual editor and it's immediately available in the API. If I need a new endpoint, I build the XanoScript function, click publish, and it's live. I haven't even mentioned the GitHub and CI/CD pipeline, but Xano has also allowed me to test in isolated environments and push to prod when my tests pass.

When you're building alone, the speed at which you can react to what the product needs is everything. The pillars I chose aren't the "best" in any objective sense. They're the ones that let me move the fastest while maintaining enough structure to not collapse.

The Honest Part

I work at Xano. I do education and developer advocacy. So no, I'm not an unbiased source.

But I chose Xano for ChatClipThat because I already knew the platform inside and out... and I knew it could handle what I was building. The advocacy is easy when the thing you're advocating for is the same thing you'd pick anyway.

The "governance layer" framing isn't a solo dev thing. It's an architecture thing. Enterprise teams use Xano to centralize their backend logic and data governance across services. Indie devs use it to ship without building infrastructure from scratch. The use case scales. The platform is the same.

Pick platforms that let you focus on the thing only you can build. For me, that's the AI pipeline. Everything else is a pillar.

The Web Tells Machines What Things Are. It Doesn't Tell Them Why.

camb — Fri, 13 Mar 2026 22:37:10 +0000

I had a thought the other day that won't leave me alone.

We've spent decades building the web for humans. HTML gives us structure — headings, tables, buttons, forms. A human looks at a page and immediately understands what's going on.

Machines don't.

An LLM sees a <table> and has no idea if it's pricing tiers, analytics data, a leaderboard, or a comparison tool. It just sees a table. It has to guess why it's there.

And that guess becomes the foundation for AI browsing, accessibility systems, personalized interfaces, and agents operating software — basically everything we're trying to build next.

The web gives machines structure, but not intent. And I think that's the missing layer.

The Semantic Web Tried This. It Failed.

This isn't a new observation. Schema.org, RDFa, microformats, the entire Semantic Web movement — they all tried to make web content machine-readable.

They all struggled with adoption. And they all struggled for the same reason:

The developer does the work. Someone else gets the value.

A developer adds itemprop="author" or typeof="Product" and... Google's search results get richer. A knowledge graph gets smarter. But the developer? They got nothing they could feel.

There's a second reason they struggled: the machines of that era couldn't read natural language. So every standard required structured, rigid, machine-parseable formats. Controlled vocabularies. Ontologies. Committee-approved taxonomies.

You had to learn the vocabulary. You had to use it exactly right. And if your use case didn't fit the taxonomy, you were stuck.

That constraint no longer exists.

LLMs Changed the Consumer

This is the part that matters.

The machine reading the web is fundamentally different now. An LLM doesn't need type="Product". It can understand "this section sells shoes."

That single shift changes everything about what a machine-readable web could look like.

Previous standards required rigid formats because the parsers on the other end were rigid. Schema.org needed exact property names. RDFa needed exact predicates. The entire Semantic Web was built around the limitation that machines couldn't interpret — they could only match.

LLMs don't have that limitation. They interpret. They reason. They understand context, nuance, and implied meaning. A sentence describing why a UI element exists carries more signal to an LLM than any structured attribute ever could.

The machines changed. The web hasn't caught up.

That's the gap. And the fix might be simpler than anyone expected.

Intent: The Missing Primitive

What if web elements carried a description of their purpose — not as a structured label, but as a natural language statement that an LLM can understand?

<intent>
  This section helps the user compare pricing tiers and decide which
  plan fits their needs. The table shows monthly vs annual pricing
  with feature breakdowns. The primary action is selecting a plan.
</intent>

Or:

<intent>
  This modal confirms subscription cancellation and attempts to retain
  the user with a discount offer. It's a critical conversion moment —
  the user should not be rushed past this.
</intent>

Or:

<intent>
  This section onboards new users while simultaneously building trust
  through social proof. The testimonials are positioned here to reduce
  signup hesitation.
</intent>

No controlled vocabulary. No schema to memorize. No committee to wait on. A developer just describes what the section does and why it exists — in their own words.

The LLM on the other end handles the semantics. That's its job. And for the first time in the history of the web, the consumer is actually capable of doing that job.

You don't even need a new HTML element to start. An HTML comment prefixed with intent: would work just as well — it's already invisible to browsers, already readable by crawlers, and already a habit developers have. The format barely matters. What matters is that intent is expressed, and that something on the other end can now understand it.

Why This Is Different From Everything Before

Every previous attempt at machine-readable web content required structured formats because the machines couldn't understand language. They needed rigid schemas because parsers needed exact keys.

Intent doesn't need any of that. The consumer is an LLM. The format is natural language. The authoring cost is writing a sentence.

This removes every barrier that killed previous standards:

1. No standardization bottleneck. There's no taxonomy to agree on. A developer describes what the section does in their own words. The LLM figures out the classification, the relationships, the context — all of it.

2. Authoring is trivially easy. Writing "this form collects shipping info for checkout" isn't a new skill. Developers already write comments, documentation, and PR descriptions. This is the same muscle — applied to the DOM.

3. It scales with the LLM. As models get better, the same intent descriptions become more useful — not less. A better model extracts richer meaning from the same sentence. The investment compounds over time without the developer changing anything.

What This Actually Unlocks

Once intent exists on a page, the UI no longer has to be fixed. It becomes interpretable. Adaptable.

Imagine browsing Reddit, but you choose how you experience it:

TikTok-style vertical feed
Twitter-style stream
Minimal reading mode
Research mode with everything expanded

Same content. Completely different UI. The content stays the same because the intent stays the same — only the presentation changes based on who you are and how you prefer to consume information.

Intent becomes the bridge between content and experience.

When Is Intent Even Necessary?

If the HTML is already semantically clear — a <table> inside a section titled "Pricing" — a machine can probably infer that. You don't need to annotate everything.

Intent shines when the purpose isn't obvious from structure alone:

"This table isn't just data — it's designed to push users toward the annual plan by making monthly look expensive."
"This section looks like filler, but it's the primary trust-building mechanism on the page."
"This modal is the most important conversion moment in the entire flow."

That level of nuance can't come from a type="Product" label. It can only come from natural language — and it can only be consumed by something that understands natural language.

That's the key insight. Intent as a concept only becomes viable when the consumer can interpret free-form descriptions. We finally have that consumer.

Architecture: Three Pillars

The system breaks into three parts.

1. User Profile

A user defines how they want to experience the web. Simple structured preferences:

preferred_layout: feed
reading_density: high
modal_tolerance: low
theme: dark
interaction_style: keyboard-first

What do you want to see when you browse? How do you want to consume content? This is just an onboarding step — straightforward preference collection.

2. Web Intent Index

This is the real work. Sites are crawled and their intent is mapped.

Two paths exist:

A — Explicit Intent (Best Case)

Developers add natural language intent descriptions to their markup. Rich, contextual, high-signal. The LLM on the indexing side ingests these and builds a purpose map of the site.

B — Inferred Intent

If intent annotations aren't present, a crawler scrapes the page, maps the structure, and uses an LLM to infer intent — then hashes the result and stores a semantic index.

Here's where things get interesting: the explicit and inferred paths aren't competing — they compound. A crawler's inferred intent might say "this looks like a pricing table." A developer's explicit intent says "this table exists to push users toward the annual plan by making the monthly price look bad." The explicit version carries far more signal — and an LLM can reconcile both.

You could also inject inferred intent into existing pages and let site owners refine it later if they want to participate. That gives you immediate coverage without requiring anyone to change their code first.

This becomes a semantic sitemap of the web. Not just links — purpose.

3. Rendering Engine

When a user visits a page:

A browser extension intercepts the request
A page hash lookup occurs
The intent map is retrieved
The user profile is matched
The best rendering path is selected

The key insight: this doesn't need LLM reasoning at runtime.

All the heavy work — the crawling, the inference, the intent mapping — already happened during indexing. At runtime, it's just similarity matching:

User vector → Intent vectors → Closest match → Render

No slow AI calls. Cached intent maps, hashed page structures, vector similarity. You could put this on a CDN. You could put this at the DNS level. At that point, it's just numbers and lookups — not reasoning.

This Doesn't Require Rebuilding the Web

Intent is an overlay. It sits on top of whatever already exists.

The supporting infrastructure could be:

A crawler that indexes intent annotations
A CDN layer that caches intent maps
A browser extension that matches users to intents
A developer habit: describe what your sections do

Existing sites continue to work. Nobody rewrites anything. React, Svelte, plain HTML — doesn't matter. Intent is framework-agnostic by nature because it describes purpose, not implementation.

Where This Idea Lives

This sits somewhere between the Semantic Web, search indexing, AI browsing, and adaptive UI systems. But instead of encoding data relationships, it encodes user experience purpose.

Not:

"This is a Product."

But:

"This helps the user decide which product to buy — and it's designed to make the premium option feel like the obvious choice."

The Semantic Web tried to make the web machine-readable at the data level using structured formats for machines that needed structured formats.

This is about making the web machine-readable at the experience level using natural language for machines that now understand natural language.

Different era. Different consumer. Different approach.

The Actual Point

Right now, the web tells machines what things are.

It doesn't tell them why they exist.

Previous attempts to fix this required rigid schemas because the machines couldn't read language. That constraint is gone. LLMs can interpret natural language descriptions of purpose — and that changes what's possible.

If the next generation of browsing is going to be powered by agents, assistants, and adaptive interfaces, the missing layer might just be intent — written in plain language, for machines that can finally understand it.

I'm calling it IntentML until someone gives me a better name.

Stop Using One AI Model for Everything!

camb — Fri, 06 Mar 2026 23:51:46 +0000

Every time a new model drops, the internet loses it.

"INSANE."

"This changes everything."

"Goodbye developers."

And for about 48 hours, everyone forgets the obvious: Models are just tools.

Each one has strengths, weaknesses, and specific jobs it's actually good at. Together, wired the right way, they can create a beautiful system.

As an analogy, imagine an orchestra in union. There exists a maestro and musicians, each person with a particular role, instrument, and each playing a specific part.

Now, in contrast, imagine a music hall full of clarinetists and only clarinetists.

Playing any composition intended for a full orchestra would be... different. Not necessarily bad, but it would be lacking.

In this same manner, models in agentic development are unique enough that they warrant distinction.

After building a bunch of real AI pipelines, there's no such thing as "the best model." In the same way as the music analogy above, there's no "universal instrument".

There are only models that are best for specific kinds of work.

And if you conduct them the right way, you can make beautiful music.

So what do AI models actually do?

When you peel away the hype, most use cases fall into 4 buckets:

Reasoning
Generation
Vision
Signal detection

Different models shine at each.

Trying to use one model for all four? I'd... recommend against it. Again. Think of the ensemble of clarinets. shudders

1. Reasoning models → Deep thinking

These are your problem solvers. Use them when you actually need thought — not just speed.

They excel at logic, planning, synthesis, and multi-step analysis.

Great for:

Designing architecture
Debugging hard problems
Analyzing tradeoffs
Synthesizing research
Planning multi-step workflows

They’re slower and pricier, but the quality? Way higher.

Examples:

OpenAI GPT‑5 (Reasoning Mode)
Anthropic Claude 3 Opus
Google DeepMind Gemini 2 Ultra
Mistral Large or Cohere Command R+

If you're asking:

“Why is this system failing?”

“How should I structure this pipeline?”

Use one of these.

2. Fast generation models → Throughput work

These models are built for speed, cost, and volume.

Perfect for:

Summarization
Rewriting
Classification
Bulk content
Tagging

Don’t waste a reasoning model on millions of lines of text — go cheap and fast.

Examples:

Gemini 2.5 Flash
GPT‑4o mini or GPT‑3.5 Turbo
Claude Haiku
Mistral‑7B or Mixtral (8×7B)

3. Vision models → Anything with images or video

If your app looks at images, screenshots, or frames, this is your category.

Use for:

UI/screenshot analysis
Gameplay or scene interpretation
Document layouts
Image annotation

Vision‑language models (VLMs) combine text + visual context and make a huge difference when visuals matter.

Examples:

GPT‑5.3 (multimodal: text, audio, image)
Gemini 3 Pro (VLM capable)
Claude 4.6 Opus
QWEN 3 Max

4. Signal detection models → Cheap filters

One of the best tricks in AI pipelines:

Cheap models detect signals. Expensive ones analyze.

Instead of sending everything to your most powerful model, filter first.

Example pipeline:

cheap classifier
↓
find interesting samples
↓
vision model looks closer
↓
reasoning model interprets
↓
generation model writes output

It saves cost and improves accuracy.

Examples:

DistilBERT, MiniLM, or Mistral 7B‑Instruct for lightweight classification
LLaMA‑3‑8B for pre‑filtering or tagging
GPT‑5 or Claude Opus for deep reasoning after filtering

The biggest mistake

The most common fail I see:

People pick one big model and try to use it for everything.

That's how you end up with systems that are:

Slow
Expensive
Inefficient

Better approach?

Orchestrate models.

Let each one do the part it's best at.

Just like you wouldn't use a screwdriver as a hammer, you shouldn't use a reasoning model for bulk classification work.

What real AI systems look like

It's not:

app → one LLM → output

It's more like:

input → filter → specialized model → reasoning model → generator → result

Each stage has a role. Modular. Extendable. Scale efficiently and keep quality high.

Think of it like an assembly line. Each worker (model) has one job they're really good at. The magic happens in the coordination, not in having one super-worker trying to do everything.

Why this matters for your next project

I see too many developers burning through API credits because they're using Claude Sonnet to classify 10,000 support tickets when a $0.001 classification model would do the job better and faster.

Or using a fast generation model for complex reasoning tasks and wondering why the outputs are inconsistent.

The real skill in AI engineering isn't picking the "best" model. It's designing systems where each model does what it's actually optimized for.

Final thought

Stop asking "Which model should I use?"

Start asking "Which model should I use for this job?"

Once you start thinking that way, your systems get cheaper, faster, and way more reliable.

That's when AI engineering starts to click. That's when it really starts to sound like music... figuratively, of course.

It's way more fun building systems that feel like orchestrated symphonies rather than trying to make one model do everything poorly.

Forem: camb

Our content engine now outputs 4K lossless WebM because I solved an RGBA problem that was killing quality!

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

How I Fixed Transparent Video Alpha in Playwright Using 1970s Film Math

The Problem

What's Actually Happening

Premultiplied vs. Straight Alpha

The background-clip: text Problem

Approaches That Don't Work

The Fix: Background Subtraction

The Math

Implementation

In the Capture Loop

FFmpeg Encode

One Remaining Gotcha

Result

Video included!

I Built a HIPAA-Compliant CMS with Bolt and Xano

I Built a HIPAA-Compliant CMS with Bolt and Xano

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

What HIPAA actually requires from developers

The stack

Field-level encryption

Two layers of access control

Audit logs

The contracts: BAA and BASA

Making changes safely

Shared responsibility

Try it

Built a HIPAA-compliant CMS with bolt.new and Xano. Bolt for the frontend. Xano for the backend. Field-level encryption, app-level RBAC, custom audit logs, BAA and BASA contracts covered. The whole… | Cameron Booth

Building a B2A Platform: The Agentic Architecture of "Sh*t My Dev Says"

I Built a Platform Where Agents Are the Primary Users

The Stack

The Backend

The Newsletter

What's the plan?

Building a B2A Platform: The Agentic Architecture of "Sh*t My Dev Says"

I Built a Platform Where Agents Are the Primary Users

The Stack

The Backend

The Newsletter

What's the plan?

Amazon Lost 6.3 Million Orders Because Nobody Reviewed the Code. Here's What Governance Actually Looks Like.

The Word Nobody Wants to Say

Executives Are Now Doing What the Architecture Should Have Done

What a Governance Layer Actually Looks Like

The AI Problem is a Governance Problem

Who This Is Actually For

The Takeaway

[Boost]

The Pillars Behind a Solo-Built AI Platform

camb ・ Mar 19

[Boost]

The Pillars Behind a Solo-Built AI Platform

camb ・ Mar 19

The Pillars Behind a Solo-Built AI Platform

Pillar 1: Xano — The Governance Layer

Pillar 2: GCP — The Muscle

Pillar 3: The AI Layer

Pillar 4: The Vibe Coding Philosophy

The Honest Part

The Web Tells Machines What Things Are. It Doesn't Tell Them Why.

The Semantic Web Tried This. It Failed.

LLMs Changed the Consumer

Intent: The Missing Primitive

Why This Is Different From Everything Before

What This Actually Unlocks

When Is Intent Even Necessary?

Architecture: Three Pillars

1. User Profile

2. Web Intent Index

3. Rendering Engine

This Doesn't Require Rebuilding the Web

Where This Idea Lives

The Actual Point

Stop Using One AI Model for Everything!

So what do AI models actually do?

1. Reasoning models → Deep thinking

2. Fast generation models → Throughput work

The `background-clip: text` Problem