DEV Community: Isaiah Kim

Ranking a dashboard by funnel depth, not counts

Isaiah Kim — Mon, 27 Jul 2026 14:21:10 +0000

I had a metrics page that told me nothing. Page views per host, signups, a couple of Stripe lines, all rendered as cards in a grid. Every morning I'd look at it, feel vaguely informed, and then go build whatever I'd already decided to build the night before. That's the tell: if the dashboard never changes what you do next, it isn't a dashboard, it's decoration.

So I rewrote it around one question — how far do people actually get — and let that ordering decide what I see first.

The ordering is the product

Kynth Studios ships a lot of separate products on separate hosts: FetchDue chasing overdue invoices for agencies, BenchFile doing NYC Local Law 84 filings, CertScope determining CPSC scope per SKU, ParseRail for developers integrating against the API. They don't share a funnel shape in any interesting way, but they do share a funnel depth: someone lands, someone starts the demo, someone finishes the guided run, someone starts signup, someone finishes it, someone activates.

Depth is the only axis where those products are comparable. A traffic number tells me a host got attention. A depth number tells me where attention stopped.

So the model is a stage list plus a rollup per product:

// stages are ordered; index IS the depth
const STAGES = [
  'demo_start',
  'demo_complete',
  'signup_start',
  'signup_complete',
  'activated',
] as const

type Stage = (typeof STAGES)[number]

type ProductFunnel = {
  slug: string
  counts: Record<Stage, number>
}

// deepest stage a product has ANY reach into
function depth(f: ProductFunnel): number {
  for (let i = STAGES.length - 1; i >= 0; i--) {
    if (f.counts[STAGES[i]] > 0) return i
  }
  return -1
}

// the first stage that eats everything
function stall(f: ProductFunnel): Stage | null {
  for (let i = 1; i < STAGES.length; i++) {
    const prev = f.counts[STAGES[i - 1]]
    if (prev > 0 && f.counts[STAGES[i]] === 0) return STAGES[i]
  }
  return null
}

depth sorts the list. stall is the label on each row. Everything else on the page is subordinate to those two functions.

Vanity metrics are the ones with no stage below them

The rule I ended up with for what stays on the page: a metric earns its spot if there's a next stage it's supposed to feed. Page views feed demo starts. Demo starts feed completions. Completions feed signup starts.

Page views on their own feed nothing I control, so they came off. Same with a top-level "total events" number, which mostly moved when I deployed something. Anything that only ever goes up and never implies an action is a metric you can watch forever without learning anything.

The one that hurt to cut was a combined cross-product total. It looked healthy. It was healthy — it just averaged a product where people finish the demo together with one where nobody gets past the landing page, and the average was never the thing I needed to know. Now every row is per-product and the sort does the summarizing.

Keep the data engine away from the rendering

The part I'd do again on any dashboard: the thing that computes stages, predicates, sorts and rollups is framework-agnostic and knows nothing about React. It takes events, returns ProductFunnel[] sorted by depth. The components take that array and draw it.

That split has paid off more than once. When a number looks wrong, the first question is which half is wrong — and because the contract between them is a plain typed object, I can answer it by calling the rollup in a test and reading the output. A rendering bug costs nothing on the engine side. A rollup bug is visible without a browser.

It also means the same rollup feeds a morning summary that isn't a web page at all. Same functions, different renderer.

What the page actually looks like now

One list. Products sorted deepest-first, each row showing its stall stage and the counts on either side of it. FetchDue near the top because there's a one-click live demo with no signup form in front of it, so people reach the guided run. The compliance products — BenchFile, GoodStanding, DoseTrace — sit lower, because a done-for-you filing service has a different entry shape and the interesting stage is further along.

That ordering is doing real work. Last week it put a product at the bottom of the list whose landing page I thought was fine, with a stall at demo_start — plenty of people arriving, nobody starting. That's a specific bug in a specific place, which is more than the old grid ever gave me.

FetchDue has no customers yet and the dashboard says so; the honest zero is on the page next to a link to the live product and a recorded run. I'd rather look at a zero I can locate than a total I can't.

The bit I'd tell someone rebuilding theirs

Pick the axis before you pick the charts. I spent longer than I should have arranging cards, and none of that time mattered, because the layout question and the ranking question are different questions and only one of them changes what you build tomorrow.

Sorting by depth also has a property I didn't expect: the top of the list is the least urgent thing. The products getting people deepest need the least attention. Reading the page bottom-up is the actual workflow, which means the sort could arguably be reversed — I've left it deepest-first because I want the ceiling visible, and I go to the bottom on purpose.

Seek-safe animation: one paused timeline, scrubbed

Isaiah Kim — Sat, 25 Jul 2026 14:21:58 +0000

I've been building HyperFrames, the animation engine behind the product demo videos I make at Kynth. It renders video from HTML: a composition is an HTML file whose DOM declares its own timing with data-* attributes, and the renderer turns that into frames. The same pipeline cuts the walkthroughs for FetchDue, CertScope and DoseTrace, alongside the Playwright harness that drives a real browser through each product and the edge-tts narration track.

The whole design collapses into one requirement: same input time → same pixels. Everything below is what that requirement cost.

Why does a render pipeline need a paused timeline instead of playback?

Because there is no playback. The renderer doesn't watch an animation run and grab screenshots — it takes a time value, seeks the page to it, and reads a pixel buffer. Frames can be sampled out of order, and they can be sampled in parallel across workers. Nothing is allowed to depend on having arrived at this frame through the previous one.

That kills a whole category of normal web animation. requestAnimationFrame loops accumulate state. setTimeout chains assume wall-clock progression. Scroll and hover listeners never fire, because the renderer has no input events. If a visual only looks right after the browser has been sitting there for two seconds, it will never look right in a render.

So every composition registers exactly one paused GSAP timeline, built synchronously at page load, keyed by the composition's own id:

// index.html — built at load, never played
const tl = gsap.timeline({ paused: true });

tl.from("#headline", { y: 24, opacity: 0, duration: 0.6, ease: "power2.out" })
  .from("#rows .row", { y: 12, opacity: 0, duration: 0.4, stagger: 0.08 }, "-=0.2");

window.__timelines["invoice-scene"] = tl;

The key has to match data-composition-id on the root element exactly. No -mount or -host suffix, which I know because I spent real time staring at a blank frame that previewed perfectly.

The rule that makes the rest fall out

Build the timeline synchronously. Not inside async, not in a Promise.then, not in a setTimeout. The renderer can seek before an async builder finishes, and when it does you get a frame of the static HTML with none of the motion applied — and no error, because nothing failed. It's just early.

Once that rule holds, seeking is a one-liner (tl.seek(t)), and the interesting work moves to everything that isn't the timeline.

What actually breaks determinism in practice?

Clocks and randomness are the obvious ones, and they're the easy ones to lint. Date.now(), performance.now(), unseeded Math.random() — banned outright for anything that affects visual state. If you want random-looking placement, seed a PRNG so the scatter is identical on every run.

The subtler ones:

Infinite loops. repeat: -1 has no defined state at time t in a parallel sampler. Compute a finite count from the clip's duration instead:

const repeats = Math.max(0, Math.floor(duration / cycleDuration) - 1);

floor, not ceil. ceil overshoots the declared duration, and Math.max(0, …) stops a short clip from producing -1 — which is infinite again, by the back door.

Two timelines touching the same property. GSAP's overwrite behavior is order-dependent. If two tweens both animate opacity on the same element in the same window, which one wins depends on evaluation order, and that can flip between renders. This one is nasty because it usually looks fine and then produces one wrong frame in the middle of a delivered video.

Never measure the DOM at tween time

getBoundingClientRect() inside a tween callback is the desync I hit most while building scene templates. It reads fine in preview, where frames arrive in order. Under a parallel renderer, the element you're measuring may be in a different state than you assumed, so the number you get back depends on sampling order.

The fix is boring: compute layout constants once at composition setup and reuse them. Same for text — for anything dynamic, measure through the framework's own text helpers (fitTextFontSize, or the pretext measurement layer under it) rather than reflowing the DOM per frame.

There's an allowlist for what can be animated at all: opacity, x, y, scale, rotation, color, backgroundColor, borderRadius, transforms. Never display, never raw visibility, and never width/height/top/left for layout changes. Transforms compose predictably at an arbitrary time; layout properties trigger reflow and take their neighbors with them.

How do you seek a runtime that isn't GSAP?

You make each runtime publish something the engine can address by time, and you give the engine one adapter per runtime. GSAP covers most motion work, but a composition can mix runtimes, and each one seeks differently:

Lottie — every player registers itself on window.__hfLottie, and the adapter calls goToAndStop(timeMs, false) on lottie-web instances, or the frame/percentage API on dotLottie.
Web Animations API — the adapter walks document.getAnimations(), sets each currentTime to HyperFrames time in milliseconds, then pauses it. Author with fill: "both" so seeked states persist past their active window.
CSS keyframes — the adapter finds elements with a computed animation-name, seeks their Animation handles when the browser exposes them, and otherwise falls back to pausing with a negative animation-delay. Use animation-fill-mode: both.
Three.js — the adapter deliberately does not own your scene. It sets window.__hfThreeTime and dispatches hf-seek, and your composition renders that exact time:

window.addEventListener("hf-seek", (event) => {
  const t = event.detail.time;
  mixer.setTime(t);           // authored clips
  camera.position.z = 8 - t;  // pure function of time
  renderer.render(scene, camera);
});

The shape is the same every time: time in, frame out, no memory of the previous call.

Duration turned out to be a separate problem from seeking

This surprised me. The render engine needs a positive total duration before it captures a single frame, or capture fails outright. A GSAP timeline reports its own length, so that case is free. The others aren't.

CSS duration is inferred from the longest animation-delay + duration × finite iteration count. WAAPI comes from the longest effect's getComputedTiming().endTime. Lottie reads the asset's native length, which is finite even when loop: true. And Three.js is not inferable at all — the adapter only forwards time, it doesn't inspect your scene for an AnimationClip. So a Three.js composition must declare data-duration on its root, and the linter errors when it doesn't.

Two capabilities that felt like one: where am I on the timeline and how long is the timeline. Every adapter answers the first. Only some can answer the second.

How do you catch a desync before it reaches a delivered video?

Sample the frames a human would never scrub to. Three passes, in order of cost:

npx hyperframes check                      # lint, runtime, layout, motion, contrast
npx hyperframes snapshot --at 2.4,6.1,9.8  # eyeball the seams, not the beats
npx hyperframes render                     # only after the frames look right

check catches the mechanical violations — a missing duration source, a repeat that overshoots, a set on a clip from a later scene. Snapshots catch the silent class: a transformed element that's still inline and therefore invisible, a full-screen background painted on the root instead of a full-bleed child (which previews correctly and renders black), a pulsing decorative that clears its neighbor at rest and collides at peak scale.

There's also an audit script that walks every registered timeline, enumerates the tweens, samples bounding boxes and writes an animation map — useful for finding dead zones and inconsistent stagger after the fact.

Almost every bug that survived to a delivered frame had the same signature: preview looked right, render didn't. Preview plays forward, in order, in one process. The renderer doesn't do any of those three things. Anything you validate only by pressing play, you haven't validated.

Why a CSS diff reads right and renders wrong

Isaiah Kim — Thu, 23 Jul 2026 14:21:40 +0000

I shipped a mobile fix for one of our tenant sites last week — coi-tracking, the first real app we stood back up after the catalog teardown. The change was small: restore some breakpoint rules that had gone missing in a port, and un-hide a few elements that only exist once on desktop. Reading the diff, every line was obviously correct. Reading the site at 390px before the fix, it was obviously broken. Those two facts had been true at the same time for a while.

That gap — a change that reads right in the diff and wrong in the browser — is the thing I've spent the most effort building a habit around, because I'm one person and there is no second pair of eyes between my editor and production.

Why does a CSS diff read right and render wrong?

Because a diff shows you the rule you changed, and the browser shows you the rule that won. Those are different questions, and only one of them is answered by the text in front of you.

A media query block is a self-contained, readable thing. When it's present, it reads as deliberate. When it's absent, it reads as nothing at all — there's no line to notice. Deletions in CSS are silent in a way deletions in TypeScript are not. Remove a function and something fails to compile. Remove a @media (max-width: 768px) block and the desktop layout stays pixel-identical, the build passes, and the site is broken at a width you weren't looking at.

The coi-tracking landing came through our Framer→Next capture-and-own pipeline — we license a template, capture the live rendered DOM and CSS, and port it into code we own so it's ours to change forever. That pipeline is great, and it is also exactly the kind of transform where breakpoint blocks and display toggles get dropped one at a time without any of the surviving lines looking wrong.

The three shapes that keep doing this

Missing breakpoint blocks. Desktop unaffected, mobile stacked wrong. Zero signal in the diff.

Orphaned display: none. An element hidden at one width on the assumption that a different element covers that case — and then the covering element gets removed or renamed. Now nothing renders there at all. The diff shows a deletion of "unused" markup.

Reveal-on-scroll that never reveals. The element is in the DOM, present in view-source, passes any test that queries for it, and is invisible to a human forever because its opacity never got animated to 1.

That third one is the meanest, so it's worth taking apart.

How do you keep a scroll reveal from leaving content invisible?

Make the failure mode "shows too early" instead of "never shows," and add a hard failsafe that ignores your own logic.

IntersectionObserver reveals fail in three ways I now check for by reflex:

A negative bottom rootMargin shrinks the observation box, so the callback fires after the element is already visible to the reader — the animation plays late, or looks like a flicker. A positive margin fires early, which is what you actually want.

A large hide-transform (translateY(80px), a big scale) means the rect the observer measures is the post-transform rect. If your transform pushes the element far enough, the observer's geometry and the layout geometry disagree, and the intersection can simply never happen.

And anything above the fold on first paint may never trigger a scroll event at all.

Every one of those leaves content permanently invisible, which is the worst possible outcome for a marketing page — worse than an ugly animation, worse than no animation.

// reveal.ts — the version I ship now
export function observeReveal(el: HTMLElement) {
  // Above the fold on load: reveal immediately, never wait for a scroll.
  if (el.getBoundingClientRect().top < window.innerHeight) {
    el.dataset.revealed = "true";
    return;
  }

  const io = new IntersectionObserver(
    ([entry]) => {
      if (!entry.isIntersecting) return;
      el.dataset.revealed = "true";
      io.disconnect();
    },
    // Positive margin: fire BEFORE it enters view, not after.
    { rootMargin: "0px 0px 15% 0px", threshold: 0 }
  );

  io.observe(el);

  // Failsafe: whatever the observer thinks, this content becomes
  // visible. A broken animation beats a blank section.
  setTimeout(() => {
    el.dataset.revealed = "true";
    io.disconnect();
  }, 3000);
}

The hide state pairs with a small transform — 16px, not 80 — so layout and observer geometry stay in agreement:

[data-reveal] { opacity: 0; transform: translateY(16px); }
[data-reveal][data-revealed="true"] { opacity: 1; transform: none; }

The setTimeout is the part I'd have argued against a year ago as sloppy. I don't anymore. It converts an entire class of invisible-content bugs into a mild timing artifact, and it costs three lines.

What does a browser check look like when there's no QA team?

It's a script that opens real Chrome at the widths you actually ship at and saves a screenshot of each one, and you look at them.

I already had this lying around for a different reason. Our demo recordings are driven by Playwright — a real browser walking the full product flow with no human in the loop, which I wrote up separately. Once you have a harness that can drive a live page and wait for it to settle deterministically instead of guessing at timeouts, pointing it at a landing page across breakpoints is a ten-line job.

const WIDTHS = [390, 768, 1280, 1728];

for (const width of WIDTHS) {
  const page = await browser.newPage({ viewport: { width, height: 900 } });
  await page.goto(url, { waitUntil: "networkidle" });
  await page.screenshot({ path: `shots/${width}.png`, fullPage: true });
}

That's it. No pixel diffing, no baselines to maintain, no flaky visual-regression suite that I'd start ignoring within two weeks. Four images I look at with my eyes.

What I'm actually looking for

Large blocks of empty vertical space — that's an element that failed to render or is sitting at opacity 0. A section that appears at 1280 and vanishes at 768 without a mobile counterpart taking its place. Text that wraps to five lines in a container built for two. And any image slot that's a blank rectangle, which is the failure mode after an asset purge.

That last one is worth calling out. I recently stripped a pile of unused Framer template images and the dead <img> refs pointing at them, and deleted the orphaned components that came with them. On paper that's the safest kind of change — removing code nothing uses. In practice "nothing uses it" is a claim about the whole render tree at every viewport, and the diff can only show you the deletion.

Which changes get a browser check and which don't?

Anything that touches a breakpoint, toggles visibility, deletes an asset, or moves a route. Everything else I merge on the diff.

That's a deliberately narrow list, because a rule I apply to every change is a rule I'll stop applying. Backend logic, schema changes, agent prompts, API routes — I trust tests and the diff. But the four categories above share a property: their failure is invisible in text and obvious in a browser.

Route moves earned their spot recently. I folded apps/landing into the Artemis app so the marketing site and the builder live in one place — landing at the root, builder at /create. Every individual file move was correct. Whether the combination of moves left a working site is not a question source code answers. Our deploy.sh verify step checks real URLs after deploy, including accepting the post-teardown redirects from the retired catalog, and it's the only thing that actually knows.

What about bugs that only exist in a browser at all?

Some errors have no source-code representation, and hydration is the clearest example.

Artemis had a hydration mismatch I could not see anywhere in the code, because it wasn't in the code — it came from the DOM being modified before React hydrated, in a real browser with real extensions installed. Server HTML and client HTML disagreed for reasons no file in the repo mentioned. The fix was pinning a vendored dependency to a known-good version and gating the injected case explicitly. No amount of diff-reading would have found it; it needed a browser with the extension installed, which is to say, a normal user's browser.

This is the same principle underneath all of it, and it's why Kynth Apollo — our capabilities layer, where every hard problem gets solved once and reused — holds the browser harness alongside everything else. Artemis assembles apps out of those finished pieces. A piece that renders correctly at one width and disappears at another isn't finished, and there's exactly one place you can find that out.

Open the browser. Four widths. Look at the pictures.

Recording product demos with Playwright and no human

Isaiah Kim — Tue, 21 Jul 2026 14:21:06 +0000

I record full product demos with no human touching the keyboard — a real Chrome instance drives the app end to end, clicks through the flow, and a recorder captures every frame. The interesting part turned out not to be the clicking. It was deciding when the page was actually ready for the next step, and realizing the thing I'd built was a state machine wearing a recorder's clothes.

Here's what I learned building it for Kynth, where the demos have to look hand-driven even though nobody's there.

Why do fixed timeouts break automated demos?

Fixed timeouts break because they encode a guess about the network and the machine, and both change under you. The classic version is await page.waitForTimeout(2000) after a navigation. On my laptop with a warm cache, 2000ms is 1500ms of dead air on camera. On a cold CI runner rendering the same page, 2000ms is 400ms short and I capture a spinner mid-flight — a demo that pauses awkwardly, then jump-cuts into a half-loaded dashboard.

You can't win this by tuning the number. A bigger timeout wastes screen time on every fast run; a smaller one flakes on every slow one. The number is wrong in both directions at once because it's answering the wrong question. I don't care that 2 seconds passed. I care that the page stopped changing.

So the whole recorder is built around one idea: settle-detection. Instead of waiting a duration, wait for the DOM to go quiet.

What "settled" actually means

A page is settled when nothing meaningful has mutated for a short quiet window. I watch the DOM with a MutationObserver injected into the page, reset a timer on every mutation batch, and consider the page ready when the timer survives, say, 350ms untouched — plus network idle, because a settled DOM that's still waiting on an XHR is about to un-settle.

// runs inside the page via page.evaluate
async function waitForSettled(quietMs = 350, maxMs = 8000) {
  return new Promise<void>((resolve) => {
    let last = performance.now();
    const obs = new MutationObserver(() => { last = performance.now(); });
    obs.observe(document.body, {
      childList: true, subtree: true,
      attributes: true, characterData: true,
    });

    const started = performance.now();
    const tick = () => {
      const now = performance.now();
      if (now - last >= quietMs) { obs.disconnect(); resolve(); }
      else if (now - started >= maxMs) { obs.disconnect(); resolve(); } // hard ceiling
      else requestAnimationFrame(tick);
    };
    requestAnimationFrame(tick);
  });
}

The maxMs ceiling matters more than it looks. Some pages never fully go quiet — a looping CSS animation, a polling badge, an SSE connection nudging a counter. Without the ceiling, settle-detection waits forever for a page that's never going to be still. So it's settle-with-a-deadline: quiet wins if it can, the clock wins if it can't. That single fallback is the difference between a recorder that's robust and one that hangs on a <marquee>.

Why is a demo recorder really a state machine?

A recorder is a state machine because every step depends entirely on the exact state the last step left the app in, and the hard bugs all live in the transitions, not the actions. I didn't set out to build one. I started with a flat script — click, wait, click, wait — and it worked until it didn't, and every time it broke it was because step N assumed a screen that step N-1 didn't actually produce.

Once I named the states, the failures got legible. The recorder moves through explicit nodes — boot, landing, demo-open, flow-step-k, result, teardown — and each transition has three parts: an action (the click), a settle (wait for quiet), and an assertion (prove we landed where we meant to). If the assertion fails, I don't blindly continue into a black recording. I know exactly which edge broke.

The assertion is the part people skip

The temptation is to trust that clicking a button lands you on the next screen. It usually does. But "usually" is how you get a 90-second video where seconds 40 through 55 are a modal that failed to open, recorded in full confidence. So every transition ends by asserting the target state exists before the camera is allowed to move on:

async function transition(page, edge) {
  await edge.act(page);            // e.g. click "Run demo"
  await settle(page);              // DOM quiet + network idle
  const ok = await edge.assert(page);  // target state visible?
  if (!ok) throw new StateError(edge.from, edge.to);
  return edge.to;
}

Modeling it as a machine also gave me retries for free. A flaky edge — a cold Supabase connection that 500s the first time, an auth redirect that resolves a beat late — can retry just that transition from a known state, instead of tearing down and re-recording the whole demo from boot. When you're rendering these for real, re-running one edge versus the whole flow is the difference between a 3-second recovery and starting over.

How do you keep an automated flow from looking robotic?

You add human-shaped pacing back in on purpose, after settle-detection has removed the accidental pauses. This felt backwards at first. I spent all this effort deleting dead air, then deliberately put some back — but the two kinds of waiting are different. Settle-detection removes the pauses that come from not knowing the page is ready. Then I add small, intentional dwell before a click so a viewer's eye can land on the button before it depresses.

The rule I settled on: settle to zero, then dwell to taste. Settle-detection guarantees the floor — we're never recording a spinner. The dwell is a fixed, small, deliberate beat layered on top, and because it sits on a known-quiet page it reads as a person deciding, not a script stalling. Crucially the dwell is constant across machines; the settle absorbs all the variance. Fast runner or slow, the rhythm of the final video is identical, which is the whole point when these get cut together.

Settle-detection is a recording primitive, not a test trick

The waiting strategy that makes a good recorder is the same one that makes a good end-to-end test, which is why this generalizes past demos. A test that waits for settle instead of a timeout is a test that doesn't flake and doesn't waste minutes of CI on padding. The demo harness and the test harness want the identical thing: proof that the app reached a state, not proof that time passed.

That overlap is why the recorder lives next to the app in the Turborepo monorepo rather than in some separate video project. It drives the real Next 16 app against real Supabase and Stripe — the same stack a user hits. When FetchDue went live the weekend of July 18, the recorded run that proves it works — a real reply classified, a real answer drafted, a real email delivered — came out of this exact harness driving the live product. No mock, no staged screen. The camera watched Chrome do the thing a customer does.

What I'd tell someone building this

Stop tuning the timeout and start watching the DOM. Almost every flaky wait in an automated flow is a fixed duration standing in for a state you could have observed directly. Replace it with settle-with-a-deadline — quiet window plus a hard ceiling — and the whole class of "worked on my machine, flaked in CI" problems goes away, because you stopped guessing at time and started measuring readiness.

The state-machine framing is the other half. The moment you write down the states and make each transition assert its target, your failures tell you which edge broke instead of leaving you a black video and a shrug. And you get per-edge retries as a bonus, which is what makes recording against a real backend — where a cold connection occasionally hiccups — tolerable instead of maddening.

This recorder is one of the pieces inside Kynth Apollo, the layer where I solve a hard problem once and never solve it again. Every demo, every product screenshot, every proof-it-works run pulls from the same harness now. That's the quiet luxury of building this way: the second time you need a driven browser, you're not building — you're composing.

Getting paid is a state-machine problem

Isaiah Kim — Thu, 16 Jul 2026 14:21:08 +0000

I build a lot of things on top of one shared Core — a capabilities layer where every hard problem gets solved once and reused. The wedge I keep coming back to is the least glamorous thing a small business deals with: getting paid. Invoices go out, some get paid, some get ignored, a few get reversed weeks later. I used to think the product was the invoice. It turned out the product is everything that happens after you hit send.

Here's what I learned modeling that middle as real engineering.

How do you model an invoice that might get paid, ignored, or reversed?

Model it as a state machine, not a paid boolean. The first version of the invoices schema in Supabase had a status column with three values — draft, sent, paid — and it fell apart the first time a payment came back as a chargeback three weeks after the money had "arrived."

Why a `paid` boolean is a trap

A boolean encodes one transition and assumes it's terminal. But money moving is not a one-way door. A paid invoice can be disputed. A dispute can be won or lost. A lost dispute leaves you needing to recover funds you already counted as revenue. If paid is the end of your graph, you have nowhere to put any of that, so it leaks into ad-hoc columns and if statements scattered across the app.

The tell is when you find yourself writing if (invoice.paid && invoice.disputed && !invoice.recovered). That's three booleans pretending to be one state, and every new edge case adds another boolean and doubles the combinations you have to reason about.

The states that actually matter

I rewrote it as an explicit lifecycle where every value is a real place an invoice can sit, and every transition is something that actually happens in the world:

type InvoiceState =
  | 'draft'
  | 'sent'
  | 'viewed'        // opened the link, hasn't paid
  | 'overdue'       // past due date, still in chase
  | 'paid'
  | 'disputed'      // chargeback opened
  | 'dispute_won'
  | 'dispute_lost'  // funds clawed back
  | 'in_recovery'   // chasing money we already lost
  | 'recovered'
  | 'written_off';

// transitions are a lookup, not a pile of ifs
const NEXT: Record<InvoiceState, InvoiceState[]> = {
  draft:        ['sent'],
  sent:         ['viewed', 'overdue', 'paid'],
  viewed:       ['overdue', 'paid'],
  overdue:      ['paid', 'written_off'],
  paid:         ['disputed'],
  disputed:     ['dispute_won', 'dispute_lost'],
  dispute_won:  ['paid'],
  dispute_lost: ['in_recovery', 'written_off'],
  in_recovery:  ['recovered', 'written_off'],
  recovered:    [],
  dispute_won_terminal: [] as never,
  written_off:  [],
  recovered_terminal: [] as never,
};

Once the states were explicit, a lot of downstream code got boring in the best way. The aging view — the rows that show which invoices are drifting from sent toward overdue — is just a query grouped by state and time-in-state. When I replaced an old placeholder in the Mercury workspace with the real KynthMark org avatar and invoice aging rows, the rows had something honest to render because the state model underneath them was honest.

What is a chase cadence, and how do you build one?

A chase cadence is a scheduled ladder of reminders that escalates as an invoice ages, and the thing I learned is that it should be data, not code. My first instinct was to write the follow-up logic imperatively — send at day 3, day 7, day 14, change the tone each time. That works until the second product needs a slightly different ladder and you're copy-pasting setTimeout-shaped logic.

So the cadence is rows. Each rung is a record: how many days after the due date it fires, which channel, and which tone.

[
  { "offsetDays": -2, "channel": "email", "tone": "friendly_heads_up" },
  { "offsetDays": 1,  "channel": "email", "tone": "gentle_nudge" },
  { "offsetDays": 7,  "channel": "email", "tone": "firm_reminder" },
  { "offsetDays": 14, "channel": "sms",   "tone": "direct" },
  { "offsetDays": 30, "channel": "email", "tone": "final_notice" }
]

When I redid the cadence display in the workspace, I rendered the ladder literally as rows — one line per rung — because that's what it is in the data. The UI stopped being a diagram I hand-drew and became a view of the table. That's a small thing, but it's the through-line of the whole Core: when the model is right, the interface is a window onto it instead of a second source of truth you have to keep in sync.

The other reason cadence-as-data matters: a rung is a scheduled effect, and scheduled effects are exactly what breaks when a serverless instance dies mid-flight. If you fire these from a "run after the response" hook and the box goes away, the reminder is orphaned. The fix is to give each scheduled send a lease and run a reaper that moves anything whose lease lapsed into a terminal state — but that's a whole article on its own.

How do you handle chargebacks without special-casing every provider?

Route payments through a capability interface instead of calling the Stripe SDK directly. This is the single decision that keeps the ugly middle from metastasizing across the codebase. In the Core, apps don't import stripe. They call a payments capability, and the capability resolves to a driver based on which environment keys are present.

// apps never see the vendor — they see the capability
export function resolvePayments(): PaymentsDriver {
  if (process.env.STRIPE_SECRET_KEY) return stripeDriver();
  // more drivers slot in here by key presence
  return stubPayments(); // first-class stub, builds with zero creds
}

interface PaymentsDriver {
  charge(invoiceId: string, amount: Cents): Promise<ChargeResult>;
  onDispute(handler: (e: DisputeEvent) => Promise<void>): void;
  refund(chargeId: string): Promise<RefundResult>;
}

The stub matters more than it looks. Because a missing key falls back to a first-class stub instead of throwing, every app in the monorepo builds and renders with no credentials set. A demo can run the entire invoice → chase → dispute → recovery flow against the stub driver, deterministically, without a real Stripe account in the loop. That's what lets the Playwright automation drive the whole thing in a real browser end to end — the money side is real code paths, just with a driver that never touches a network.

And when a chargeback lands, it enters through onDispute in exactly one place. The capability translates the vendor's dispute event into the disputed transition from my own state machine. Nothing downstream knows or cares that it was Stripe. If I ever swap providers, the state graph doesn't move.

Why is the ugly middle the actual product?

Because the invoice is a commodity and the recovery is not. Anyone can render a PDF with a total on it. The hard, valuable part is the state machine that knows an invoice is drifting overdue, the cadence ladder that escalates on its own, and the recovery path for money that already left. That middle is unglamorous, full of edge cases, and exactly where small businesses lose real money — which is why it's worth building carefully.

Framing it as engineering changed how I think about the whole thing. Once the payments capability, the invoice lifecycle, and the cadence ladder were solved once in the Core, the next product that needed to get someone paid didn't start from scratch. It snapped together from finished pieces, and I got to spend my time on the parts that were actually new. That's the quiet payoff of solving the hard thing once: building starts to feel less like building and more like composing. The ugly middle, done properly, is the part you never have to write twice.

What 1,000 invoices a month actually costs across five document-AI APIs

Isaiah Kim — Fri, 10 Jul 2026 18:34:06 +0000

Pricing pages for document-extraction APIs are written to win a different comparison than the one you actually need. Per-page rates hide minimums. Credit systems hide per-document math. So here's the arithmetic for one concrete, boring workload: 1,000 single-page invoices a month, at each vendor's published July-2026 pricing. (I sell one of these APIs — disclosure at the bottom — but every number here is from the vendor's own pricing page.)

The table

API	Published rate	1,000 invoices/mo	The catch
AWS Textract (AnalyzeExpense)	$0.01/page	$10	You build the pipeline: retries, failures, schema mapping. Every attempt bills, including failed ones.
Google Document AI (Invoice parser)	$0.01/page	$10	Same deal. (Their Bank Statement parser is $0.75/classified doc.)
Azure Document Intelligence (prebuilt)	$0.01/page	$10	Same again — the hyperscalers are interchangeable here.
LlamaParse	$1.25/1k pages	~$1.25	It's a parser, not an extractor: structure back, not validated invoice fields. Budget your own extraction layer (and its LLM bill) on top.
Veryfi	$0.16/invoice	$160 — except no. Production starts at a $500/mo minimum buying <5k docs	At 1,000 invoices your effective rate is $0.50/doc, not $0.16.
Kynth Core (mine)	$0.08/invoice	$80	Charged only when extraction succeeds; no minimum, no commitment.

The three questions that actually price this category

1. What does a failure cost? The per-page APIs bill per attempt. If your docs are ugly — photographed receipts, scanned faxes, tables that explode — your effective per-successful-document rate is higher than the sticker. That's why "cost per correctly extracted document" (price ÷ accuracy) is the only number worth comparing, and why I publish a reproducible accuracy benchmark alongside this post — including the suites where the hyperscalers beat me.

2. What does the minimum cost? Veryfi's per-doc rates look adjacent to mine until the commitment line. Minimums are a bet the vendor makes you place on your own volume. Process 800 invoices a month and you're paying for 5,000.

3. Who owns the pipeline? $10/month at Textract is real if your engineering time is free. The hyperscaler APIs hand you fields; everything around them — schema validation, retries, normalization, the 3am alert when a new invoice layout breaks parsing — is yours.

Disclosure and receipts

Kynth Core is my product, so weight my row accordingly. What I can offer instead of neutrality is reproducibility: the accuracy benchmark behind these claims is an MIT-licensed harness (public datasets, pinned revisions, raw responses committed, fork-safe CI) — re-run every number with your own keys, or re-score my committed responses with no keys at all. Links: benchmark repo · live scores · pricing sources.

I benchmarked my document-extraction API against Textract and Google DocAI — on public datasets, in public CI

Isaiah Kim — Fri, 10 Jul 2026 14:04:01 +0000

Vendor benchmarks are rightly distrusted: pick a friendly dataset, tune on the test set, round up, publish. I sell a document-extraction API (Kynth Core), I wanted to publish accuracy numbers, and I couldn't find a form of "trust me" that I would accept from someone else. So the benchmark became a repo instead of a claim.

The rules I couldn't let myself break

Public datasets only, pinned. FATURA for invoices (synthetic — disclosed loudly), SROIE + CORD-v2 for receipts, FinTabNet for tables, and the Bankstatemently open benchmark for statements — where the ground truth is held server-side by a third party, so I literally cannot tune against it. Every dataset pinned by revision with SHA-256s.
Subsets pre-registered. The seeded selection of document IDs was committed before any API was called. No document was dropped after seeing results.
No fuzzy matching in headline numbers. Amounts to the cent, dates exact (ISO), strings after whitespace/punctuation normalization. ANLS is a secondary column only.
Raw responses committed. Every vendor's verbatim API output is in the repo — anyone can re-score everything with zero API keys (pnpm replay && pnpm report), or challenge my adapters' normalization line by line.
CI runs it, not me. Fork PRs run keyless replay-scoring only, so nobody's keys leak.

Results

Suite	Metric	Kynth Core	AWS Textract	Google DocAI
Invoices (FATURA, n=100)	field accuracy	99.4%	92.2%	93.1%
Receipts (SROIE, n=100)	field accuracy	88.8%	68.8%	52.8%
Receipt line items (CORD, n=100)	F1	41.9%	77.1%	36.6%
Receipt totals (CORD, n=100)	accuracy	67.1%	95.5%	82.2%
Tables (FinTabNet, n=100)	TEDS	0.791	0.836	0.365

Where Kynth lost, plainly: Textract beats it decisively on CORD line-item extraction (77.1% vs 41.9% F1) and receipt totals from the same set, and edges it on table structure (0.836 vs 0.791 TEDS) — where Kynth also logged 14 outright failures on hard tables, counted against it rather than dropped. Kynth is also roughly 10× slower per document than Textract. Kynth wins where fields need semantic understanding (invoice fields, messy scanned receipts); the hyperscalers win on dense structural extraction. That trade is the honest takeaway.

Notes that keep the table honest: Textract has no bank-statement product (N/A, not zero). Bank statements are pending entirely — the third-party evaluator currently 400s on its own published files; the n=5 parses are committed and will score when it's fixed. Veryfi and LlamaParse adapters are implemented but unscored — no credentials this cycle; I wasn't going to pay Veryfi's $500/mo minimum to benchmark a competitor. FATURA is synthetic, which flatters everyone equally, but flatters.

What I'd want you to take from this

Not "Kynth wins" — on three of five rows it doesn't. The claim is narrower: flat per-document pricing, billed only on success, with accuracy you can reproduce is a different product shape than per-page-per-attempt with a pipeline you own. The repo is MIT: doc-extract-bench. PRs that improve competitors' adapters are especially welcome — that's the failure mode a vendor benchmark can't recover from on its own.

Live scores: api.kynth.studio/benchmarks. The engine behind it runs 73 production apps; that story is on my site.

How one person runs a whole studio of production apps

Isaiah Kim — Thu, 09 Jul 2026 01:02:41 +0000

I maintain a whole studio of production web apps by myself. Not landing pages — real apps with auth, billing, a database, their own domains, their own UI, and real AI features behind a paywall. People assume the trick is that they're thin. It's the opposite: the only way one person keeps a studio of real apps alive is to make the apps thin and the engine thick. Almost everything an app does, it borrows.

This is a teardown of that engine. I'm writing it because the engine is now a product — api.kynth.studio, which I call Kynth Core — and a whole studio of apps in production is the most honest load test I can offer for it.

The shape of the problem

A single app is easy. The cost of software isn't the first instance, it's the Nth. Every app wants the same twelve things: sign-in, a session, a user row, a Stripe subscription, a webhook to reconcile it, analytics, SEO metadata, a design system, an AI call with a budget on it, and a way to ship without babysitting a pipeline. If each app owns its own copy of those twelve things, then N apps is 12N surfaces to patch when Stripe rotates an API version or Next ships a breaking change. That number is where solo maintenance dies.

So the design rule is blunt: an app is allowed to own its domain logic and its screens, and nothing else. Everything horizontal lives once, in a shared package, and every app imports it. When I fix auth, I fix it for the entire studio in one commit.

The monorepo and the shared packages

It's a Turborepo monorepo. The apps are Next.js. The load-bearing part isn't the apps directory — it's packages/. A few of them do most of the work:

@kynth/analytics — one React component, mounted in every app's root layout. It initializes PostHog, fires $pageview, and — this is the part that pays for itself — self-labels every event with an app super-property derived from the host. A signup on one app's subdomain and a signup on any other land in the same event stream, correctly attributed, with zero per-app wiring. It also fires the funnel events and the ads conversion pixel on the same shared success boundary. No app writes analytics code. They inherit it.
@kynth/shell / @kynth/layouts — the design system as components, not copied CSS. A three-zone workspace layout, the modals, the toasts, the form primitives, the dashboard cards. Each app sets exactly one variable — --shell-accent, its identity hue — and the whole chrome recolors. The house chrome is monochrome on purpose so that one variable is the only thing an app has to decide.
@kynth/seo — metadata, JSON-LD, sitemaps, and the cross-app link graph, generated from a single catalog file.

That catalog file is the spine. catalog.ts is the source of truth for what apps exist: slug, display name, the accent hue, the marketing copy. The build reads it; the SEO package reads it; the launcher reads it. When I add an app, I add a catalog entry, and the rest of the platform notices.

One database, one deploy

Two decisions do more for maintainability than any code:

One Supabase project for all of them. Every app shares one auth pool and one Postgres. A user is a user across the whole suite; I don't run a database per app or reconcile a pile of separate identity systems. Row-level security and a per-app column keep each app's data its own. The operational win is that there is exactly one place to look when something is wrong with data, and exactly one migration surface.

One Vercel project, not one per app. This is the counterintuitive one. The apps used to deploy as separate Vercel projects — dozens of dashboards, dozens of env-var sets, dozens of build configs drifting apart. Now they consolidate into a single deployment that routes by Host header: the same running project serves every subdomain and decides which app to render from the hostname. I deploy once. Rolling an app back is re-pointing a subdomain, not a redeploy. The 12N surface problem collapses because there's one of most things.

Shared infra follows the same "one of it" rule everywhere it can:

One OAuth callback per provider, app-agnostic, at a single hub URL. Apps fan out from a state param carrying { app, uid } instead of each registering its own redirect URI. Adding an app doesn't touch the Google Cloud console.
One Stripe webhook endpoint for the whole suite, routing by metadata.app. Stripe caps endpoints per account; sharing one means the cap never binds and there's a single signature to verify.

The AI layer is a wallet, not a hundred keys

Every app has AI features, and AI features are where a solo operator gets destroyed two ways: unbounded cost, and copy-pasted prompt plumbing that rots. So the AI doesn't live in the apps either. It lives behind a credit-wallet API — the same Kynth Core I mentioned at the top.

An app doesn't hold a model key or manage a rate limit. It spends credits against a wallet through a typed endpoint. The API is a suite of capabilities — document parsing (PDF / invoice / receipt / statement / contract → schema-valid JSON), text and structured-extraction endpoints, and more — each with a fixed request/response contract and a per-call credit cost. A runner gives every endpoint the same shape: auth, wallet debit, validation, execution, structured error. Adding an endpoint is implementing one function against that runner; every app gets it for free the moment it lands.

This is why the AI is Pro-only inside the apps: a metered wallet has a real marginal cost, so the paywall isn't a growth tactic, it's the actual economics showing through. The free tier is the deterministic, non-AI path; the AI is what you pay for, in the app and on the API alike.

Generation, not hand-authoring

New apps aren't hand-built from an empty folder. There's a generation pipeline: a new app starts from the shared packages and the catalog entry, with the workspace shell, auth, billing, analytics, and SEO already wired because those come from imports, not from boilerplate I retype. What I actually write per app is the domain: the data model and the handful of screens that make this app different from the last one. The horizontal 90% is inherited; I author the vertical 10%.

That ratio is the whole story. It's why the studio can keep growing instead of stalling at a handful. The size isn't a flex — it's the proof I care about as a developer, because a whole studio of apps sharing one auth, one billing surface, one analytics contract, one deploy, and one AI wallet means those shared surfaces have been exercised across every failure mode the studio can throw at them. Battle-tested is a claim; a studio of apps in production is the receipt.

Why you might want the engine

Most of what I described you can't buy — it's a monorepo I run. But the part that's genuinely reusable, I extracted: the credit-metered capability layer is Kynth Core, and it's live at api.kynth.studio with SDKs on npm and PyPI and an MCP server. If you've ever bolted an AI feature onto an app and then spent the next month babysitting the key, the budget, and the retry logic, that's the exact tax this removes. You get a typed endpoint, a wallet with a hard ceiling, and a response you can trust the shape of.

I built it because I needed it over and over, in every app I ship. That's the only endorsement I can give it, and it's the one I'd trust.

Isaiah Kim — one-person AI product studio.