DEV Community: Kynth

Compiling one tokens.json into an app, its landing page, its PDFs, and its OG card

Kynth — Mon, 27 Jul 2026 11:12:13 +0000

TAGS: designsystems, webdev, css, architecture

draw-your-font did the rounds this week — photograph your handwriting, get a real TTF/WOFF back. Nice hack, and a good reminder that generating a brand asset is the easy half. Keeping that one asset identical across a React app, a marketing site, a generated PDF, and a 1200×630 share image is the half that quietly rots.

That rot has a specific cause: those four surfaces usually get built by different people at different times. The app gets built first, the landing page gets bolted on before launch, the PDF export is a ticket nobody wanted, and the OG card is made in Figma the morning of. Each one re-declares the brand from memory. Six weeks later the accent color exists in four slightly different hexes.

Here's the pipeline we use to stop that, and the three places it broke.

Rule 1: tokens are primitives, never references

The temptation is to write tokens as CSS:

:root { --accent: #1f5f4b; --accent-weak: color-mix(in srgb, var(--accent) 12%, white); }

This works right up until a consumer that isn't a browser needs the value. Chrome's Page.printToPDF header template can't resolve your var(). Neither can a canvas-based OG generator, nor an email, nor a <meta name="theme-color">.

So the source of truth is a flat JSON of resolved primitives, and everything else is generated:

// tokens.json  →  four artifacts
const t = JSON.parse(await readFile("tokens.json"));

await write("app/tokens.css",      `:root{${vars(t)}}`);           // web app
await write("site/tokens.css",     `:root{${vars(t)}}`);           // landing page
await write("pdf/theme.js",        `export default ${json(t)}`);   // print + header/footer
await write("og/theme.js",         `export default ${json(t)}`);   // share card renderer

const vars = t => Object.entries(flatten(t))
  .map(([k, v]) => `--${k}:${v}`).join(";");

Any derived value — a 12% tint, a hover state — gets computed in the build step and written out as a literal. If a consumer has to do color math at runtime, it will do it differently than the others eventually.

Where it actually broke

Chrome's PDF header/footer is a separate document. headerTemplate renders in its own tiny page with no access to your stylesheet, no external fonts, and it silently ignores most of what you send it. Everything has to be inlined, sized in pt, and the font has to be a data URI of the same file the site loads:

headerTemplate: `<style>@font-face{font-family:B;src:url(data:font/woff2;base64,${b64})}
  div{font:8pt B;color:${theme.ink.muted};padding:0 14pt}</style>
  <div><span class="title"></span></div>`

Backgrounds vanish in print. Any token used as a fill needs print-color-adjust: exact on the element, not just the page. We set it once on a .binder * selector after losing an afternoon to a header block that rendered correctly in the browser preview and white in the output.

Page breaks are a token too. Section spacing that looks right on a scrolling page produces orphaned headings on paper. We added break-inside: avoid and a --section-gap-print value to the same file, so the print rhythm is versioned alongside the screen rhythm instead of living in one person's head.

Versioning across repos

The app and the landing page deploy separately, so tokens.json is published as a tiny internal package and pinned by version in both. Not because the semver matters, but because it makes drift a diff instead of a discovery. When the accent shifts, you get one PR touching one file, and the next deploy of each surface picks it up.

The payoff is that launch assets stop being a separate project. The OG card is a headless render of a component that imports the same theme; the ad thumbnails are crops of it. Change the accent, run the build, and the share preview, the report cover, and the landing hero all move together.

That's the whole argument for shipping the product and its surrounding surfaces as one job rather than two: not that it's faster, but that consistency is a build artifact when the same team owns the pipeline, and a manual chore when it isn't.

We built this for CivicBinder — a service that runs web-accessibility audits for public agencies and generates the evidence binder as a PDF. Same pipeline: one tokens file, four renderers.

Put an LLM QA gate in front of your paid deliverable: fail-closed review, one self-heal, no retry loops

Kynth — Fri, 24 Jul 2026 22:57:22 +0000

TAGS: ai, node, automation, playwright

I built and shipped a compliance-report service — domain registered, Stripe live, fulfillment automated — in under a week of calendar time. Not a quarter. Not a team. One person with an AI-native toolchain. The point of this post isn't the speed; it's the specific piece of engineering that made the speed possible, because it's the piece most solo builds skip and then get burned by.

The pipeline is the easy part

The product audits public-sector websites for ADA Title II accessibility and produces an evidence binder. The pipeline is boring on purpose — a chain of CLI stages, each writing JSON to disk:

crawl-scan.mjs   → Playwright + axe-core over N pages → findings.json
pdf_census.py    → every linked PDF, tagged/untagged   → pdf-census.json
summarize.mjs    → severity-weighted score             → summary.json
evidence.mjs     → annotated screenshots of failures   → evidence/*.png
binder.mjs       → 13-page PDF                         → readiness-binder.pdf

Files on disk, not in-memory state. Every stage is resumable, inspectable, and re-runnable against a single town's directory. That's not architectural purity — it's what lets one person debug page 9 of a PDF at 11pm without re-crawling a municipal website.

None of that is the hard part. AI-assisted, that chain came together fast.

The part you can't hire

Here's what actually blocks a solo operator from charging money: nobody checks the work before it goes out. In a company that's a role. Someone reads the deliverable, notices the screenshot is missing its markers, and stops the send. Alone, you're the generator and the reviewer, and you cannot review every artifact of an automated pipeline forever.

So the reviewer became a subprocess. Before any binder is emailed, a headless model reads the actual PDF, the scan data, and — with vision — the evidence screenshots:

const prompt = `You are the pre-delivery QA reviewer, reviewing a PAID deliverable.
Read: readiness-binder.pdf (every page), summary.json, evidence/*.png (LOOK at them).
Check strictly:
 1. Entity name + domain correct on cover/headers — no other town's name anywhere.
 2. Counts in Section 1 match summary.json.
 3. Every screenshot shows numbered flag markers; captions match what's visible.
    A screenshot with no visible markers is a FAIL.
 4. No overflow into footers, blank pages, unreplaced {{PLACEHOLDER}} tokens.
Output ONLY: {"pass":bool,"issues":[...],"notes":"..."}`;

let verdict = qaReview(...);                 // reviewer errored? → pass:false
if (!verdict.pass) {
  if (selfHeal(verdict.issues)) {            // fixes src/, commits, ONE attempt
    regenerateArtifacts();
    verdict = qaReview(...);
  }
  if (!verdict.pass) throw new Error(...);   // send stays blocked, owner notified
}
await sendBinder();

Three things in there are load-bearing, and I got each of them wrong first.

Fail closed, including on the reviewer itself. If the model times out, crashes, or returns garbage, the verdict is pass: false. A broken referee must never become a green light. Every failure path routes to a human inbox with both verdicts attached.

Parse tolerantly or you'll false-fail good work. "Output only JSON" is a suggestion. Code fences, a stray sentence, a lone { in prose — early on, perfectly good binders got blocked by formatting quirks. The fix is a scanner that walks the string for the first balanced {...} that parses and contains a pass key, ignoring fences and preamble. Strict on the deliverable, forgiving on the envelope.

Self-heal fixes the generator, not the artifact — exactly once. When the gate rejects, a headless coding session gets the findings plus repo access, with hard rules: only edit src/, never hand-patch the generated PDF, never touch the email or payment logic, commit the fix. Then artifacts regenerate and the gate re-reviews. One attempt. On the money path, a retry loop is just a slower way to ship something broken.

What it caught

The gate earned itself in its first days. evidence.mjs was placing its numbered flags before the final scroll, so badges landed outside the captured frame and visible numbering started at #2 — a defect I'd have shipped, because the JSON manifest said four annotations and four annotations existed. Only something looking at the PNG catches that. The fix went into the generator with a comment naming the date it was caught.

That's the real speed argument. It isn't that AI writes code fast. It's that the review loop that normally costs a headcount and a week of calendar time is now a subprocess you can call from a fulfillment script — so an idea gets to actually deployed and taking payments in days, and stays trustworthy after you stop watching it.

That's how we built CivicBinder.

Auditing a 40,000-page government site for WCAG without auditing 40,000 pages

Kynth — Fri, 24 Jul 2026 20:57:53 +0000

A city of 30,000 people has more web pages than it has employees. Agendas back to 2009, a permit portal, three departments that each bought their own CMS, and 12,000 PDFs. The DOJ's ADA Title II rule gives that city a hard date to be at WCAG 2.1 AA, and the person responsible is usually one IT generalist who also fixes the printers.

You cannot run a human audit on 40,000 pages. You also cannot just run axe-core over a crawl and call the output an audit — that produces a 900,000-row CSV that proves nothing and fixes nothing. Here's the approach that actually works.

Pages don't vary. Templates do.

The insight that makes this tractable: a 40,000-page municipal site is usually 40–80 templates. Every agenda page fails the same way. If the events template has a table without a <caption>, you have one bug, not 4,000.

So the first pass is clustering by DOM skeleton, not by URL:

const fingerprint = (dom) => {
  const skeleton = [...dom.querySelectorAll('*')]
    .filter(el => !isContentLeaf(el))          // drop <p>, text-only <span>, <li> bodies
    .map(el => `${el.tagName}.${stableClasses(el.className)}`)
    .join('>')
  return sha256(skeleton)
}

// stableClasses drops anything that looks generated:
//   /\d/ -> hashed utility classes, CSS-modules suffixes, per-post ids
const clusters = groupBy(crawledPages, p => fingerprint(p.dom))

Two knobs matter more than the hashing:

isContentLeaf is the whole ballgame. Include too much and every page is its own cluster. Include too little and the permit form collapses into the same bucket as a press release. Tune it until cluster count stabilizes across two crawls a week apart — that's your signal the fingerprint is keyed on structure and not on content.

One sample per cluster is not enough. Take three: shortest, median, and longest page by content length. The long tail is where the embedded YouTube video, the nested data table, and the 2011 Flash-era markup live. Same template, wildly different violations. This one change roughly doubled real findings for us.

40,000 pages → ~60 clusters → ~180 audited pages. That's a week of human review, not a year.

Automated scans prove about a third of it

This is the part most "compliance scanners" quietly skip. axe-core reliably detects roughly 30–40% of WCAG failures. It cannot tell you whether alt text is accurate, whether focus order is logical, or whether an error message is understandable. A tool that reports "98% compliant" from a scan is reporting a number it did not measure.

So every success criterion gets a three-state ledger entry, per template:

machine_verified — a rule mapped to that criterion ran and passed
human_verified — a reviewer performed the documented procedure (keyboard-only pass, screen-reader pass, contrast spot-check)
not_applicable — with a written reason, because "N/A" without a reason is the single most common thing that gets a conformance claim thrown out

A criterion is only conformant if it's covered by one of the first two. The ledger makes the gap visible instead of hiding it behind a percentage.

Evidence has to be frozen

An audit finding is worthless six months later if the page has changed. Every finding stores a content-addressed evidence bundle: raw HTML, a full-page screenshot, the axe JSON, the response headers, an RFC 3161-style timestamp, and a SHA-256 over all of it. Findings reference the hash, never the live URL.

That also gives you cheap remediation tracking — re-crawl, re-fingerprint, diff the hashes. Templates whose fingerprint changed get re-audited. Everything else carries forward.

PDFs are where the real liability is

Municipal sites are PDF delivery systems wearing a website. Check for a /StructTreeRoot (untagged = fail), a document title, a language tag, and whether the text layer is real text or a scan. Cluster those too — the "agenda" generator produces one failure mode across 4,000 documents, and fixing the generator fixes all of them.

What comes out

Not a dashboard. A binder: scope and methodology, the sampling justification, the criterion ledger, per-finding evidence with hashes, a remediation plan with owners and dates, and the conformance statement. That's the artifact that answers a complaint.

That's how we built CivicBinder.

MVP in a Month — $12,000, ~4 weeks. Empty repo to a shipped product doing real work, like the one above. See the work and what it costs.

Turning an axe-core scan into a defensible ADA Title II evidence binder

Kynth — Wed, 22 Jul 2026 21:27:07 +0000

This is a real deliverable CivicBinder produces — a filed ADA Title II readiness binder for a small municipality. It's live: point it at a city's web presence, and it audits, gathers evidence, and assembles the whole thing. Everything below is how it actually works.

The April 2024 DOJ rule gave state and local governments a hard deadline to conform their web content to WCAG 2.1 AA. A small city clerk cannot read a WCAG spec. So the interesting engineering problem isn't "run a scanner" — it's turning scanner output into something that survives a records request.

Watch the CivicBinder — ADA Title II compliance, done for you demo

Automated scans cover maybe a third of WCAG

The first thing you learn: axe-core (and every tool built on it) is honest about only catching ~30–40% of WCAG success criteria. Color contrast, missing alt text, form labels, ARIA misuse — machine-verifiable. But "is this alt text meaningful?" or "does the reading order make sense?" — not.

If you dump raw axe violations into a PDF and call it a binder, you've produced a document that quietly claims full coverage while silently omitting the half a scanner can't see. That's the opposite of defensible. So the core design decision is a three-way split on every success criterion:

for each SC in WCAG_2_1_AA:
    checks = rules_mapping[SC]          # axe rule ids → SC
    if checks and all machine-verifiable:
        status = run_axe(checks)         # PASS / FAIL, with evidence
    elif checks partially cover SC:
        status = "PARTIAL — machine-checked + needs review"
    else:
        status = "MANUAL — human attestation required"

Every SC lands in exactly one bucket, and the binder shows all three. The clerk sees precisely what the tool verified and what a human still has to sign off on. Honesty is the feature.

The mapping table is the actual product

axe emits rule ids like color-contrast and image-alt. WCAG is organized by success criterion — 1.4.3, 1.1.1. The glue is a hand-curated map, because it's many-to-many: one SC can need several axe rules, and one rule can touch several SCs.

"1.1.1": ["image-alt", "input-image-alt", "area-alt", "object-alt"],
"1.4.3": ["color-contrast"],
"4.1.2": ["aria-required-attr", "button-name", "link-name", ...],

Get this table wrong and the whole binder is wrong. It's the part I'd never let a model hallucinate — it's reviewed against the official ACT rules and pinned to an axe version, because rule ids drift between releases.

Evidence needs provenance, not just a boolean

A "PASS" with no proof is worthless in a filing. So for every finding the crawler captures, at scan time:

the URL and a content hash of the page,
the DOM node and selector that triggered (or cleared) the rule,
a screenshot with the element highlighted,
an ISO-8601 timestamp.

That bundle is what makes a line in the table a piece of evidence instead of an assertion. When someone asks "prove the city was compliant on this date," the binder answers with a timestamped artifact, not a claim.

The crawl is messier than a SaaS site

Municipal web presence is not one Next.js app. It's a main .gov site, a third-party permit portal, a legacy PDF library, an agenda-management subdomain, and an embedded payment iframe — different owners, different auth. The crawler treats each surface as its own scope with its own coverage report, and PDFs get routed to a separate document-accessibility check entirely (tagged structure, reading order), because axe only speaks HTML.

The lesson that generalizes past ADA: compliance tooling lives or dies on the boring mapping layer and the evidence provenance — not the scanner. The scanner is a commodity; the defensible trail around it is the work.

I built this into a done-for-you product — book a slot and I'll run your city's binder.

Building a Shared Capability Layer: Why Your Fifth App Shouldn't Reimplement Email

Kynth — Mon, 20 Jul 2026 10:07:19 +0000

You know the moment. You're three weeks into a new app, and it needs to send a password reset email.

You already solved this. Twice. Once in the app you shipped last year, once in the side project before that. Both times you learned the same things: that SendGrid's sandbox mode silently swallows messages, that you need a suppression list before your first bounce, that the retry logic has to be idempotent because your queue will deliver twice eventually. Both times you wrote it down in a comment nobody read.

And now you're opening the SendGrid docs again, because copying the old file means copying its bugs, its 2024 API version, and a TODO: handle 429 you never got to.

That's the tax. Not the hard problems — the solved problems you keep re-solving at 70% quality because the last solution was welded to the app it was born in.

Copy-paste is a fork, and forks rot

The usual instinct is a shared utils package. That works until it doesn't, and it stops working for a specific reason: shared code that only shares interfaces still leaves every app owning its own state.

An email helper that wraps the SDK is nice. But bounce handling isn't a function — it's a table. Suppression lists, delivery status, retry counters, per-recipient backoff. If each app owns its own copy of that state, you don't have one email capability. You have five, and only the one you're currently looking at is correct.

The line I've landed on: a capability is a function plus the state it needs to be correct. If you extract the function and leave the state behind, you extracted the easy half.

What "built once" actually requires

Three properties, and skipping any one of them collapses it back into a utils package.

One deployment, not one library. The capability runs as a service the apps call. When you fix the 429 handling, every app has the fix — not "every app that bumps the version."

Tenancy at the boundary, not in the caller. Every call carries which app it's for. The capability owns partitioning. Apps can't get isolation wrong because they never touch it.

A narrow surface that hides the vendor. send(to, template, data) — not the SendGrid shape. Because you will migrate providers, and the migration should be one deploy, not five refactors.

# The seam that matters:
capability.send(tenant, to, template, data)
  → check suppression (shared table, all tenants)
  → render template (tenant-scoped assets)
  → dispatch via provider adapter
  → record delivery state, emit event

# Apps never see: the provider, the retry policy,
# the suppression table, the backoff curve.
# They see: send(). That's the whole API.

The suppression check being shared is the part people push back on. If a recipient hard-bounces in App A, should App B still email them? Usually yes — different products, different consent. So the table is shared but tenant-partitioned, and the reputation signal is global. That distinction has to be a deliberate design decision, not an accident of where you put the WHERE clause.

The tricky part: versioning without freezing

Here's what bit us. One deployment means one behavior — great, until App A needs the behavior to change and App B depends on the old one.

The fix that held: capabilities may add, never change. New optional parameters, new fields on responses, new event types. Never a changed default, never a removed field. When a change is genuinely breaking, it's a new capability with a new name, and the old one keeps running until the last caller is off it.

That sounds expensive. It's cheaper than the alternative, which is every app pinning a version and quietly reconstituting the five-forks problem in a worse form.

Start with the boring ones

The instinct is to extract the interesting stuff first. Wrong order. Extract the capabilities where correctness is subtle and the surface is stable: sending, payments, auth, storage. Nobody argues about what send() should do. Everybody argues about what your domain layer should do — leave that in the apps.

The test: if you can't name the capability in one verb, it's not a capability yet.

We built this as Kynth Apollo — one capability layer, and every app we ship inherits it.

Booking a slot over the phone without double-booking the truck: the race condition nobody warns you about

Kynth — Wed, 15 Jul 2026 10:23:16 +0000

A plumber I know keeps his phone face-down on the passenger seat. Not because he doesn't want the work — he is the work — but because when it rings, he's usually under a sink with both hands wet, or up a ladder, or elbow-deep in a job that pays exactly nothing extra if he stops to answer. So it rings out. And the person on the other end doesn't leave a voicemail. They just call the next name on the list.

That missed ring is a booked job walking to a competitor. He knows it. He can't do anything about it. That's the dread.

So we built a thing that answers every call, hears the job, quotes it, and books a crew. Sounds like a chatbot with a phone number. The hard part turned out to be one sentence: book a crew into the slot without ever double-booking a truck.

Why this is a real problem, not a CRUD write

Voice calls are slow and concurrent. A call lasts 90 seconds. During those 90 seconds the caller is deciding, the AI is talking, and — critically — other calls are happening on other lines. Two callers can both be told "Thursday 2pm is open" because at the moment each was quoted, it was open. Neither has confirmed yet. Both say yes. Now one truck, two jobs, and a customer who took the afternoon off for nobody.

The naive version looks fine in every demo and breaks the first busy Monday:

// DON'T: read-then-write with a human-length gap in between
const slot = await db.findOpenSlot(crew, when);   // t=0s, both calls see it open
await speak(`I've got you Thursday at 2. Sound good?`);
// ...15 seconds of the caller saying "uh, let me check with my wife"...
await db.book(slot, job);                          // t=18s, both calls write. collision.

The gap between quote and confirm is filled with human speech. You cannot hold a transaction open for 18 seconds of "let me check with my wife."

The fix: hold, don't book

We split the single write into two phases with a short-lived reservation between them. Quoting a slot places a hold with a TTL. Confirming promotes the hold to a booking, but only if the hold is still yours.

// Phase 1 — at quote time: claim a hold, atomically
const hold = await db.query(`
  INSERT INTO holds (slot_id, call_id, expires_at)
  SELECT $1, $2, now() + interval '90 seconds'
  WHERE NOT EXISTS (
    SELECT 1 FROM holds    WHERE slot_id = $1 AND expires_at > now()
    UNION
    SELECT 1 FROM bookings WHERE slot_id = $1
  )
  RETURNING id;
`, [slotId, callId]);

if (!hold.rows.length) return offerNextSlot();  // someone holds it — quote a different time

The WHERE NOT EXISTS runs inside the insert, so the check and the claim are one atomic step. Two concurrent calls race for the same row; the database picks a winner. The loser never even quotes 2pm — it's already moving on to 2:30 before the caller notices a pause.

Phase 2, at "yes," is a conditional promote: INSERT INTO bookings ... WHERE hold still valid AND owned by this call. If the caller rambled past the TTL, the hold's gone, the promote fails, and the agent gracefully re-quotes instead of silently overwriting someone.

The parts that bit us

TTL tuning is a UX knob, not a config value. Too short and slow talkers lose their slot mid-sentence; too long and you artificially block a slot while someone hangs up on you. We settled on releasing the hold the instant a call ends, not just on timeout — a dropped call shouldn't freeze a truck's calendar for 90 seconds.
"One truck" isn't one row. A crew has drive time. Booking 2pm across town when the 1pm job is 40 minutes away is a double-book in disguise. The hold has to reserve the travel envelope, not just the appointment box.
Idempotency on retries. Phone networks retry webhooks. The promote had to be safe to run twice — same call_id, same slot, second attempt is a no-op, not a second booking.

None of this is exotic. It's the boring, correct version of a reservation system — the same trick airlines and ticket sites use — applied to a domain where the "user" is a synthesized voice negotiating in real time with someone who won't stop talking about their water heater.

That reservation engine is the thing that lets Kynth Receptionist answer the plumber's phone so he doesn't have to leave it face-down anymore.

Hear it take a call → https://kynth.studio/l/receptionist

Stop sending net-30 reminders: predicting when a client actually pays

Kynth — Sun, 12 Jul 2026 15:20:56 +0000

Every freelancer knows the invoice that goes into the void.

You did the work. You sent the PDF. "Net 30" in the footer like it means something. Day 31 comes and goes. Now there's $4,250 sitting in someone else's account, and the only way to get it is to write the email you least want to write — the one where you chase your own money and try not to sound desperate. So you don't. You tell yourself you'll do it Monday. Monday you find something else to do.

The tedious part isn't writing one reminder. It's that the right moment to send it is different for every client, and you have no idea what it is.

Net-30 is a lie your accounting software tells you

Here's the thing I learned staring at a spreadsheet of paid invoices: the due date has almost nothing to do with when people pay.

One client pays like clockwork — 3 days before due, every time. Another pays 12 days late but always pays, and a reminder before day 12 just annoys them. A third only pays when you nudge, and the nudge has a 4-day lag. If you send everyone the same "friendly reminder on day 31," you're early for some, late for others, and wrong for most.

The interesting problem isn't writing reminders. It's estimating each client's personal payment distribution and firing at the point where a nudge actually moves the date.

Model the client, not the invoice

Every client is a tiny time-series. For each one, collect the gap between issue date and paid date across their history:

# days-to-pay samples for one client
history = [28, 31, 33, 30, 45, 29]  # 45 was the holiday one

# robust center + spread (median beats mean — one late pay skews it)
import statistics as st
median = st.median(history)                       # 30.5
mad    = st.median([abs(x - median) for x in history])  # 1.5

# the window where a nudge is worth sending
nudge_start = median - 2*1.4826*mad   # ~26 days
nudge_end   = median + 2*1.4826*mad   # ~35 days

MAD (median absolute deviation) instead of standard deviation matters more than it looks: one holiday-delayed payment shouldn't widen the whole window. You want the typical rhythm, not the worst case.

The signal you're really after is: is this invoice tracking behind this client's own baseline? Day 30 means nothing in the abstract. Day 30 for someone who always pays by day 27 is a real anomaly worth a nudge. Day 30 for the reliable-day-40 client is noise.

Cold start: you have no history

New client, zero samples. You can't model a distribution from nothing, so you fall back to a prior — a payment-terms segment (industry, invoice size, agency vs. direct) — and update toward the client's real behavior as payments land. Two invoices in, the prior barely matters. It's just enough to not send a tone-deaf reminder on day one.

estimate = (k * prior + n * client_median) / (k + n)
# k = prior strength (~2), n = number of real samples

The part everyone gets wrong: the words

A perfectly-timed reminder that reads like a debt collector still costs you the relationship. The timing model tells you when; the harder half is what, and it has to sound like you — same greeting, same sign-off, same amount of "hey, no rush but."

The trick we landed on: don't generate from scratch. Extract a voice profile from the user's already-sent emails (greeting style, formality, whether they use the client's first name, how they hedge), then condition the draft on both the profile and the situation — 4 days behind baseline reads different from 20 days behind. Early: light touch. Overdue past the whole distribution: warmer, firmer, and it offers a path (payment link, "want me to split this?").

And critically — it drafts. It never sends on its own. You still hit approve. The AI removes the dread of the blank compose window and the "is now the right time" second-guessing; you keep the final say on your own client relationship.

What actually changed

Once the moment is computed per client and the words show up pre-written in my voice, the invoice stops being a thing I avoid. There's no Monday-that-never-comes. The reminder is just there, correct, waiting for one click.

That's what we built into Kynth Invoices — it watches every invoice, learns each client's rhythm, and drafts the nudge at the moment that client actually pays.

Try it → https://kynth.studio/l/invoices

Dashboards Don't Get Opened: Building a Weekly Lapse-Risk Pipeline That Pushes Work Instead of Waiting for Logins

Kynth — Thu, 09 Jul 2026 13:43:21 +0000

TAGS: ai, automation, llm, python

There's a specific kind of dread in every independent insurance agency, and if you've ever built software for one, you've seen it: the renewal list. Somebody — usually the owner, at 9pm, after actual work — is supposed to pull every policy renewing in the next 60 days, cross-reference which clients haven't been contacted, and start making calls. It's tedious, it's never urgent today, and so it slides. Then a slow month happens, nobody works the book for three weeks, and four policies quietly lapse. No alarm goes off. The revenue just isn't there anymore, and nobody can point to the day it left.

We built a system to end that, and the interesting engineering lesson wasn't the AI part. It was this: the failure mode was attention, not information. The data was always sitting in the AMS. A dashboard showing it would have changed nothing, because dashboards require someone to log in, and "nobody logged in for three weeks" was the whole problem.

So we inverted the model: instead of a dashboard that waits, a pipeline that runs weekly and pushes a finished work product — a ranked risk list plus drafted outreach — into the agent's inbox.

The pipeline shape

Three stages, run on a cron:

Ingest & normalize renewal data (this is 70% of the work, see below)
Score each policy's lapse risk
Draft outreach for the top of the list, human-reviewed before send

def weekly_run(book):
    policies = normalize(fetch_renewals(book, horizon_days=90))
    scored = sorted(
        (score_lapse_risk(p) for p in policies),
        key=lambda s: s.risk, reverse=True
    )
    actionable = [s for s in scored if s.risk > THRESHOLD
                  and not recently_contacted(s.policy, days=21)]
    drafts = [draft_outreach(s) for s in actionable[:MAX_WEEKLY]]
    deliver_digest(scored, drafts)  # push, don't wait for a login

The tricky parts nobody warns you about

Renewal dates are lies. Effective dates, expiration dates, and actual renewal-processing dates disagree constantly across carriers. Some carriers auto-renew unless cancelled; others lapse silently at expiration. Your scoring function has to model what happens if nobody acts per carrier, not just "days until date X." We ended up with a per-carrier default-behavior table before any ML mattered at all.

Risk scoring can be embarrassingly simple. We started sketching a model and then realized a weighted heuristic — days to renewal, premium change at renewal (rate increases drive shopping), contact recency, payment-history flags — caught nearly everything an experienced agent would flag. Ship the heuristic first. The fancy model is a v3 problem; the cron job is the product.

The LLM's job is drafting, not deciding. We use the model to write the outreach email/text: it gets the client's first name, policy type, renewal date, and the premium delta, and produces a short, specific message ("your auto policy renews March 12 and the premium is going up $31/mo — want 10 minutes to review options?"). Two hard rules we learned to enforce in the harness, not the prompt: the model never sees or invents numbers — premium figures are injected into the template post-generation from source data — and every draft lands in a review queue. In insurance, a hallucinated dollar amount isn't a quality bug, it's an E&O claim.

Idempotency beats cleverness. A weekly job that occasionally double-runs will nag the same client twice and torch trust instantly. Every (policy, renewal_cycle) pair gets a deterministic key; outreach is recorded against it; the pipeline checks before drafting. Boring, essential.

The result

The agent's Monday inbox now contains the ten policies most likely to walk, each with a ready-to-edit message. The work that used to require someone remembering to do it now requires someone to stop it — and defaults are destiny.

If you're building for any business with a renewal-shaped revenue stream (SaaS, memberships, contracts), the pattern transfers whole: normalize the dates, score with a heuristic, let the LLM draft but never decide, and push the output instead of hosting it.

This is how we built Kynth Policy Renewals — it runs an agency's renewal pipeline every week so the book stops lapsing quietly.

Any document in. Clean JSON out. — how I turned my apps' AI layer into a 39-endpoint API

Kynth — Wed, 08 Jul 2026 13:26:48 +0000

I run a suite of AI products, and every one of them kept re-implementing the same jobs: parse an invoice, normalize a bank statement, redact PII before it hits a log, fight a chargeback. Prompt-level extraction fails silently — the JSON comes back malformed or subtly wrong just often enough that every app grew its own retry/validation/normalization layer.

So I pulled that whole layer out into one API. It's called Kynth Core.

The spearhead: documents

Nine document engines, each committed to one document kind — that commitment is what makes the output schema-valid and field-accurate instead of "usually fine":

Endpoint	Job	Price
`invoice`	Invoice → vendor, dates, PO refs, tax, line items	$0.08/invoice
`receipt`	Receipt → merchant, items, totals, expense category	$0.06/receipt
`statement`	Bank/card statement → every transaction, normalized	$0.12/statement
`resume`	Resume → structured candidate profile	$0.08/resume
`tables`	Any document → every table as clean headers + rows	$0.08/document
`split`	Multi-doc scan bundle → classified, split documents	$0.10/bundle
`compare`	Two contract versions → material changes + risk	$0.15/comparison
`contract`	Contract → parties, term, renewal, obligations, risks	$0.12/contract
`parse`	Anything else → structured, validated JSON	$0.10/document

Flat price per document — a 9-page statement costs the same as a 1-pager. And the accuracy isn't a vibe: every endpoint's field-level score is public at api.kynth.studio/benchmarks, run against the live production API and re-run on every prompt or model-routing change.

…and 30 more jobs on the same wallet

The catalog behind the spearhead, browsed at /endpoints: guaranteed-schema extraction (structure — your JSON Schema in, conforming output out, retries handled), entity matching, batch categorization, ticket triage, meeting minutes, reply drafting, collections sequences, 3-way PO matching, fraud triage, moderation against your own policy, brand-voice rewriting, a cited web-research brief, lead screening, agent memory (semantic store/search, no vector DB to run), transcription, image generation, and TTS.

Every endpoint is a finished job with its own page and its own per-task price — never a prompt you have to engineer.

The design decisions I actually care about

Priced per task, not per token. You know what a document costs before you send it.

You're only charged on success. The charge happens after a valid result, in the same row-locked transaction that writes the usage ledger.

Model routing is internal. Each task runs on the cheapest model that's good enough (Gemini / Claude / GPT, chosen per job, re-tuned as models improve). You never configure it; you just get the price on the tin.

500 free credits every month, no card. Enough to ship a real integration before you pay anything.

Three ways to call it

curl https://api.kynth.studio/v1/invoice \
  -H "Authorization: Bearer ksk_live_…" \
  -d '{ "fileUrl": "https://…/invoice.pdf" }'

TypeScript:

import { KynthCore } from "@kynth/api";
const kynth = new KynthCore({ apiKey: process.env.KYNTH_API_KEY! });
const doc = await kynth.invoice({ fileUrl });
console.log(doc.total, doc.usage.balanceRemaining);

Python:

from kynth import Kynth
doc = Kynth(api_key="ksk_live_...").invoice(file_url="https://.../invoice.pdf")

And an MCP server, so Claude or Cursor call all 39 endpoints as native tools:

claude mcp add kynth-core -e KYNTH_API_KEY=ksk_live_… -- npx -y @kynth/api-mcp

The SDKs and MCP server are generated from the same catalog the OpenAPI spec is built from, so they can't drift from the API.

Try it

Home: https://api.kynth.studio
All 39 endpoints: https://api.kynth.studio/endpoints
Benchmarks: https://api.kynth.studio/benchmarks
Interactive reference: https://api.kynth.studio/reference
OpenAPI spec: https://api.kynth.studio/openapi.json

I'd genuinely like feedback on the endpoint set — which of these you'd actually reach for over rolling your own against a raw model, and what's missing. Reply here or poke at the API.

Modeling Prior Authorization as a Payer-Policy Matching Problem

Kynth — Mon, 06 Jul 2026 16:03:02 +0000

It's 4:47 PM. There are nine prior authorizations in the queue and the person working them has been at it since lunch. Each one is the same ritual: open the chart, hunt for the diagnosis codes, cross-reference the payer's coverage policy PDF (the one that changed last quarter and nobody told you), copy the ICD-10 that justifies the CPT, paste it into a portal that logs you out every twenty minutes, and hit submit knowing there's maybe a 70% chance it comes back denied for a reason you could have caught if you'd had time to read all eleven pages of the policy.

Then it comes back denied. And now it's an appeal, which is the whole thing again but angrier.

If you've built anything near a medical practice, you know this queue never empties. It just ages. And every aged auth is revenue sitting in limbo. I spent the last year building software to work this pile, and the interesting part wasn't the AI — it was realizing prior auth isn't a writing problem. It's a matching problem.

The pile is a matching problem, not a writing problem

The naive build is: dump the chart into an LLM, say "write a medical necessity letter," ship it. It produces confident, fluent prose. It also gets denied, because a payer doesn't grade prose. A payer grades whether specific, enumerated criteria in their coverage policy are each backed by something in the chart.

So the real unit of work isn't a letter. It's a set of (criterion → evidence) pairs. Aetna's policy for a given procedure might require: failed conservative therapy for ≥6 weeks, documented functional impairment, imaging confirming the indication. UnitedHealthcare wants a different three things. The job is to bind each criterion to a concrete chart citation — and to notice, before submitting, when a criterion has no evidence behind it. That empty binding is your denial risk, and you can see it coming.

def assemble_justification(chart, payer_policy):
    bindings = []
    for criterion in payer_policy.required_criteria:
        evidence = retrieve_evidence(chart, criterion)  # dated chart citations
        bindings.append({
            "criterion": criterion,
            "evidence": evidence,
            "satisfied": bool(evidence),
        })

    unmet = [b for b in bindings if not b["satisfied"]]
    denial_risk = len(unmet) / len(bindings)   # the number you want BEFORE submit
    return Justification(bindings=bindings, risk=denial_risk, gaps=unmet)

The gaps list is the whole product, honestly. It turns a blind submission into "these two criteria are unmet — go get the PT notes before you send this."

Grounding, because hallucinated evidence is malpractice

retrieve_evidence is where every shortcut bites you. You cannot let the model say the conservative therapy happened. It has to cite the note that says it, with a date. We treat any binding whose evidence isn't traceable to a real chart span as unsatisfied — a false "satisfied" is far more dangerous than a false gap. A gap gets flagged for a human; a fabricated citation gets you denied, or worse.

The other subtle bit: coverage policies drift. The criteria set has to be re-parsed from the live policy, not memorized, or you'll assemble a beautiful justification against last year's rules.

The denial is structured too

When a denial comes back, resist the urge to "write an appeal." A denial cites specific reasons — usually a criterion the payer claims wasn't met. So the appeal is just the inverse operation: take each denial reason, find the criterion it maps to, and rebut it with the evidence binding you already built. Point by point, in the payer's own vocabulary. Half the time the evidence was there and the reviewer missed it, and a targeted rebuttal is far stronger than a fresh persuasive essay.

What actually changed

The lesson that generalizes beyond healthcare: when an LLM task feels like "generate a document," check whether it's secretly a matching task with an audit trail. Model the criteria, bind them to evidence, expose the gaps, and let the fluent-prose part be the last, cheapest step. The pile still exists — but now something works it down instead of just aging it.

We packaged this as Authorize — try it free. It's how we built the thing that finally empties the queue.

Predicting When a Client Will Actually Pay: Modeling Invoice Timing With an AI Agent

Kynth — Mon, 06 Jul 2026 00:38:49 +0000

The single hardest thing about getting paid isn't writing the invoice. It's the follow-up — knowing when to nudge a quiet client, and doing it in a tone that doesn't torch the relationship. Most tools solve this with a dumb cron job: "send a reminder 7 days after the due date." That's wrong for almost everyone, and here's why.

The problem with fixed reminder schedules

Payment behavior isn't uniform. One client pays like clockwork on day 32 of a "net 30" invoice — not late, just their rhythm. Another pays on day 5 but only if you remind them on day 3. A blanket "day 7 past due" reminder annoys the first client (who was always going to pay) and misses the second (who needed the poke earlier).

So the real problem is per-client timing prediction, not scheduling. You want to model each client's payment distribution and act at the point where a reminder has the highest marginal effect — the moment they're most likely to convert intent into a transfer.

Modeling payment rhythm as a per-client distribution

Every invoice gives you a labeled data point: (sent_date, due_date, paid_date, amount, was_reminded). Over time, per client, that's a distribution of "days from send to pay." The naive move is to average it. Don't — averages hide the shape, and the shape is the whole signal.

We model each client's pay-day as a distribution and track two things that matter more than the mean:

Dispersion — a tight distribution (always day 30–32) means a reminder before day 30 is noise. A wide one means the client is reminder-sensitive.
Reminder lift — comparing paid-day distributions with and without a nudge tells you whether reminders actually move this client, and by how much.

for client in clients:
    hist = paid_events(client)              # list of days-to-pay
    p50, p90 = quantiles(hist, [.5, .9])
    lift = mean(days_without_reminder) - mean(days_with_reminder)

    # act just before the client's own habitual pay point,
    # but only if a nudge historically helps them
    if lift > MIN_LIFT_DAYS:
        send_at = due_date + p50 - REMINDER_LEAD
    else:
        send_at = due_date + p90     # let reliable-but-slow payers be

The else branch is the one people skip, and it's the most important. A client who reliably pays on day 45 doesn't need three reminders — they need zero until day 44. Suppressing unnecessary nudges is as valuable as sending well-timed ones, because every needless reminder trains the client to ignore you.

Cold start: the first invoice has no history

With no per-client data, you fall back to a hierarchical prior: start from the population distribution (or a segment — agencies pay differently than startups), then let each new payment pull that client's estimate toward their own behavior. Bayesian updating does this cleanly. After two or three invoices, the client-specific signal dominates the prior. Before that, you're at least not guessing blind.

Drafting in the user's voice — the calibration problem

Timing gets the money moving; tone keeps the client. The reminder has to sound like you, not like a collections agency. We feed an LLM a few of the user's real past messages as style exemplars, plus structured context (days overdue, prior reminders sent, relationship length) so the model can calibrate escalation:

First nudge on a reliable client → light, assume-good-faith.
Third nudge, 30 days over → firmer, still professional.

The trick is that escalation is a function of the client's own history, not a global template. Same overdue count, different tone, depending on whether this client has ghosted before. Pass that history into the prompt and the model calibrates it far better than any if/else ladder you'd hand-write.

What makes it an agent, not a script

It closes the loop. Every paid invoice updates the distribution, re-estimates lift, and reschedules the next client's reminders. It decides not just what to send but whether to send at all — and the "send nothing" decision is a first-class action. That feedback loop is the difference between automation and an agent that gets better at your specific book of clients over time.

We built this as Tally — it watches every invoice, learns each client's rhythm, and drafts reminders in your voice at the moment they actually pay. Try it free → https://kynth.studio/l/tally

DEV Community: Kynth

Compiling one tokens.json into an app, its landing page, its PDFs, and its OG card

Rule 1: tokens are primitives, never references

Where it actually broke

Versioning across repos

Put an LLM QA gate in front of your paid deliverable: fail-closed review, one self-heal, no retry loops

The pipeline is the easy part

The part you can't hire

What it caught

Auditing a 40,000-page government site for WCAG without auditing 40,000 pages

Pages don't vary. Templates do.

Automated scans prove about a third of it

Evidence has to be frozen

PDFs are where the real liability is

What comes out

Turning an axe-core scan into a defensible ADA Title II evidence binder

Automated scans cover maybe a third of WCAG

The mapping table is the actual product

Evidence needs provenance, not just a boolean

The crawl is messier than a SaaS site

Building a Shared Capability Layer: Why Your Fifth App Shouldn't Reimplement Email

Copy-paste is a fork, and forks rot

What "built once" actually requires

The tricky part: versioning without freezing

Start with the boring ones

Booking a slot over the phone without double-booking the truck: the race condition nobody warns you about

Why this is a real problem, not a CRUD write

The fix: hold, don't book

The parts that bit us

Stop sending net-30 reminders: predicting when a client *actually* pays

Net-30 is a lie your accounting software tells you

Model the client, not the invoice

Cold start: you have no history

The part everyone gets wrong: the words

What actually changed

Dashboards Don't Get Opened: Building a Weekly Lapse-Risk Pipeline That Pushes Work Instead of Waiting for Logins

The pipeline shape

The tricky parts nobody warns you about

The result

Any document in. Clean JSON out. — how I turned my apps' AI layer into a 39-endpoint API

The spearhead: documents

…and 30 more jobs on the same wallet

The design decisions I actually care about

Three ways to call it

Try it

Modeling Prior Authorization as a Payer-Policy Matching Problem

The pile is a matching problem, not a writing problem

Grounding, because hallucinated evidence is malpractice

The denial is structured too

What actually changed

Predicting When a Client Will Actually Pay: Modeling Invoice Timing With an AI Agent

The problem with fixed reminder schedules

Modeling payment rhythm as a per-client distribution

Cold start: the first invoice has no history

Drafting in the user's voice — the calibration problem

What makes it an agent, not a script

Stop sending net-30 reminders: predicting when a client actually pays