DEV Community: Jordan Vance

A zero-dependency way to generate fantasy character names in Python

Jordan Vance — Thu, 04 Jun 2026 19:52:10 +0000

Every test suite I write ends up needing throwaway names. Faker is great for "John Smith" and "Acme Inc", but the moment I'm seeding a game's NPC table or a fantasy-app fixture, real-world names look wrong next to a dwarf cleric. So I went down the rabbit hole of procedural name generation. You can get believable fantasy names with nothing but the standard library.

Here's the whole idea in a few lines.

The trick: stitch syllables, don't store names

A lookup table of pre-written names runs dry fast and feels repetitive. Instead you keep small pools of sound fragments per race and assemble a name from one start + optional middle + ending:

import random

ELF_START = ["Ae", "Fae", "Lael", "Cael", "Syl"]
ELF_MID   = ["", "la", "ri", "va", "thy"]
ELF_END   = ["riel", "wyn", "thas", "lor", "ndil"]

def elf_name(rnd=random.random):
    pick = lambda pool: pool[int(rnd() * len(pool))]
    return (pick(ELF_START) + pick(ELF_MID) + pick(ELF_END)).capitalize()

print(elf_name())   # -> 'Faewyn'

Five fragments per slot already gives you 5 x 5 x 5 = 125 combinations that read like elf names, because the constraint lives in the fragments, not in a giant list. Swap the pools and an orc reads like an orc:

ORC_START = ["Gr", "Mog", "Rok", "Dur", "Kra"]
# harsh consonant clusters, short endings -> 'Grukgor', 'Rokmash'

A couple of design notes that matter once you actually use this:

Keep generate() pure. Pass the RNG in as a callable (rnd=random.Random(7).random) so you can seed it. Reproducible names mean your test fixtures don't churn the diff every run.
Capitalize at the end, not per-fragment, or you get FaeWyn.
An empty string in the middle pool is a cheap way to vary name length without a separate branch.

If you just want names, not a project

I packaged the full version as a pip install: seven races (human, elf, dwarf, orc, halfling, tiefling, dragonborn), masculine/feminine/any, still zero dependencies.

pip install dnd-name-generator

$ dnd-name-generator -r dwarf -g masculine -n 5
Thorin
Durgrim
Balek
Khazdin
Gimnor

Or from code:

from dnd_name_generator import generate, generate_many

generate("Tiefling", "Feminine")   # -> 'Kallieth'
generate_many(3, race="Orc")       # -> ['Grishnak', 'Moguk', 'Rokgor']

It's MIT and generate() takes the same rnd callable, so you can seed it for tests. Source and docs are on PyPI: https://pypi.org/project/dnd-name-generator/

Next time a fixture needs a half-orc barbarian instead of another "Test User 3", you've got options that don't pull in a single transitive dependency.

What a HIPAA risk assessment actually asks you, in plain English

Jordan Vance — Thu, 04 Jun 2026 13:43:56 +0000

Most developers I know hit "you need a HIPAA security risk assessment" and picture a $1,500 consultant engagement built around a 40-page Word template. That's one way to do it. But the assessment itself isn't mysterious. It's a fixed set of questions, and you can answer most of them yourself in an afternoon once you know what they are.

Here's the actual structure. If you'd rather just click through it, there's a free no-signup version that runs the same 18 questions in your browser and hands back a gap list: free HIPAA Security Risk Assessment self-check. Nothing leaves the page, so you can run it against a real system without filling in a lead form first.

The HIPAA Security Rule (45 CFR 164) splits into three families. What each one is really asking:

Administrative safeguards

The biggest bucket, and the one people skip because none of it is technical. Have you actually written down a risk analysis (the thing you're doing right now counts). Is someone named as the security official. Do you train the people who touch PHI. Do you have an incident response plan you've read in the last year. And the one that bites SaaS teams: do you have signed BAAs with every downstream vendor that sees PHI. Your cloud provider, your error tracker, your transactional email service. Each one separately.

Physical safeguards

Short section, easy to underweight if your team is fully remote. Who can physically reach the machines PHI sits on. How are workstations positioned, can someone in a waiting room read a screen over a shoulder. What happens to a laptop or drive when it's decommissioned. "We're in the cloud" doesn't zero this out; your laptops are still endpoints.

Technical safeguards

The part developers are most comfortable with, which is exactly why it's worth checking you didn't assume your way past it. Unique logins per user, no shared admin account. Encryption at rest and in transit. Audit logs that record who accessed what. Authentication that actually verifies identity. The gap I see most often is logging that exists but that nobody could query if an investigator asked "who opened this record on March 3rd."

Why the assessment matters more than the BAA people fixate on: a signed business associate agreement moves liability around, but it doesn't tell you where your gaps are. The risk analysis is the only artifact that does, and it's among the first things requested in basically every OCR settlement on record. "We assumed we were fine" is not an answer that survives that request.

Run it honestly. "In progress" is a valid answer and a more useful one than pretending everything's in place, the output is a list of what isn't done yet, which is the entire point. Then decide whether you need the consultant. For a lot of small teams, the answer after seeing the gap list is "we can close most of these ourselves."

Generating a PDF invoice in the browser with jsPDF (no backend)

Jordan Vance — Thu, 04 Jun 2026 10:22:27 +0000

A freelancer friend asked me for "a thing where I type in line items and get a clean invoice PDF." My first instinct was the usual stack: a server route, a headless-Chrome PDF renderer, maybe a queue so the Lambda doesn't time out. Then I stopped — none of that data should leave the browser in the first place. Client names, rates, amounts: it's exactly the stuff you don't want sitting in someone's request logs. So I built the whole thing client-side. Here's what I learned.

Two ways to make a PDF in the browser

There are really only two approaches, and picking the wrong one costs you a day:

Rasterize the DOM — render an HTML invoice, screenshot it with html2canvas, and drop the image into a single-page PDF. Fast to wire up, looks exactly like your HTML… and produces a picture of an invoice. The text isn't selectable, it's blurry when printed, and a one-page image can't paginate when someone adds 40 line items.
Draw the PDF directly — use jsPDF's text/vector API to lay the document out yourself. More code, but you get real selectable text, crisp print output, and genuine multi-page support.

For an invoice — a document people print, forward, and sometimes paste a number out of — vector text wins. So this is the jsPDF route.

The 30-second version

jsPDF gives you a document you draw onto in points, then save:

<script src="https://cdn.jsdelivr.net/npm/jspdf@2.5.1/dist/jspdf.umd.min.js"></script>
<script>
  const { jsPDF } = window.jspdf;
  const doc = new jsPDF({ unit: "pt", format: "letter" });
  doc.setFont("helvetica", "bold");
  doc.setFontSize(26);
  doc.text("INVOICE", 540, 60, { align: "right" });
  doc.save("invoice.pdf");
</script>

Two things that bit me immediately: it loads onto window.jspdf (lowercase namespace, capital-S jsPDF constructor), and unit: "pt" matters. Default is millimeters; a US Letter page is 612 × 792 points, and once you're thinking in points the rest of the layout math stays in one coordinate system.

Text is positioned by baseline, and you move the cursor yourself

This is the mental shift coming from HTML. There's no flow layout — every doc.text(string, x, y) places that string's baseline at (x, y). You keep your own y and increment it after each line:

let y = 90;
doc.setFontSize(11).setFont("helvetica", "bold");
doc.text(fromName || "Your business", 48, y);
y += 14;                       // advance the cursor by the line height
doc.setFontSize(9.5).setFont("helvetica", "normal");
doc.text(addressLine, 48, y);

Right-aligning the amounts column is just doc.text(value, x, y, { align: "right" }) with x pinned to the right margin. Once you accept that you're a cursor pushing text around a canvas, the layout gets predictable fast.

Wrapping long text without overflow

A "Notes" field or a long line-item description will happily run off the page edge, because doc.text does not wrap. splitTextToSize is the fix — it breaks a string into an array of lines that fit a given width:

function wrapped(doc, text, x, y, maxWidth, lineHeight) {
  const lines = doc.splitTextToSize(String(text || ""), maxWidth);
  lines.forEach((ln) => { doc.text(ln, x, y); y += lineHeight; });
  return y; // return the new cursor so the next block starts below
}

Returning the updated y is the small trick that keeps everything below it from colliding.

Paginate before you draw the row, not after

The invoice table is where naive code breaks: someone adds enough line items to run past the bottom margin and the last rows just vanish off the page. The fix is to check the cursor before drawing each row and add a page if you're close to the edge:

items.forEach((it) => {
  if (y > doc.internal.pageSize.getHeight() - 120) {
    doc.addPage();
    y = 48;                    // reset cursor to top margin on the new page
  }
  doc.text(it.desc, 54, y);
  doc.text(money(it.qty * it.rate), 558, y, { align: "right" });
  y += 22;
});

The - 120 is headroom so the totals block underneath the table never gets orphaned alone at the very bottom.

Embedding a logo — entirely locally

People want their logo on the invoice, and this is the part that most tempts you to add an upload endpoint. You don't need one. A <input type="file"> plus FileReader.readAsDataURL gives you a base64 data URL that both the on-screen preview and jsPDF can consume directly:

const reader = new FileReader();
reader.onload = (e) => {
  const dataUrl = e.target.result;          // "data:image/png;base64,..."
  // on-screen preview:
  previewImg.src = dataUrl;
  // and straight into the PDF, no network round-trip:
  doc.addImage(dataUrl, "PNG", 48, 40, 96, 48, undefined, "FAST");
};
reader.readAsDataURL(file);

The "FAST" compression flag keeps the output small, and the image never touches a server — it's read off the user's disk into memory and stamped into the PDF. That's the whole privacy story in one API.

Money formatting: do it once, in one helper

Mixing currency symbols and fixed decimals inline is how you end up with $1234.5 on a customer-facing document. Centralize it:

const fmt = (n) =>
  symbol + (isFinite(n) ? n : 0).toLocaleString(undefined, {
    minimumFractionDigits: 2,
    maximumFractionDigits: 2,
  });

toLocaleString handles the thousands separators and the trailing-zero cents for free, and you pass the same string to both the live preview and doc.text, so the two can never disagree.

Why client-side at all

After wiring this up I couldn't find a reason to put any of it on a server. The invoice data — who you're billing, for how much — never leaves the browser. There's nothing to rate-limit, nothing to pay for, no PII sitting in a log, and it works on a plane. The only thing a backend would buy you is generating invoices for non-browser clients, and if a human is filling in the form, you don't have one.

If you just want to type in line items and grab the PDF without wiring up jsPDF yourself, I put a no-signup version online while building this — Invoicely runs entirely in the browser (same jsPDF-under-the-hood approach, nothing uploaded). Handy for a one-off invoice, or for eyeballing how a layout paginates before you write the code.

Gotchas worth knowing

unit: "pt" from the start. Switching coordinate systems halfway through a layout is miserable. Letter = 612 × 792pt, A4 = 595 × 842pt.
Baseline, not top-left. doc.text positions the text baseline; if your first line looks clipped at the top, push your starting y down by roughly the font size.
Check pagination before the row. Always test with a 30-item invoice — the bug only shows up past the first page break.
Data URLs, not Blob URLs, for addImage. jsPDF wants the base64 string; URL.createObjectURL gives you a blob: reference it can't embed.

That's the whole thing — a print-ready, multi-page invoice generator with zero backend. jsPDF is more manual than rasterizing the DOM, but for a document people actually print and read, the selectable vector text is worth the extra cursor-pushing.

Rendering scannable barcodes in the browser with JsBarcode (no backend)

Jordan Vance — Thu, 04 Jun 2026 07:07:24 +0000

I had a small feature to add to a web app last month: let a user type a SKU and get back a Code 128 barcode they could print on a label. My first instinct was to reach for a barcode microservice or one of those GET /barcode?text=... image APIs. Then I remembered the whole thing can run on the client. No server, no rate limit, no data leaving the page.

The library that does the heavy lifting is JsBarcode. It's old, tiny, and it just works. Here's what I learned wiring it up for Code 128, EAN-13, and UPC-A.

The 30-second version

JsBarcode takes a target element (an <svg>, <canvas>, or <img>) and a value, and draws the barcode into it:

<svg id="bc"></svg>
<script src="https://cdn.jsdelivr.net/npm/jsbarcode@3.11.6/dist/JsBarcode.all.min.js"></script>
<script>
  JsBarcode("#bc", "ABC-12345", { format: "CODE128" });
</script>

That's a complete, scannable Code 128 barcode. It encodes any ASCII string, which is why it's the default for internal SKUs, asset tags, and anything that isn't a retail product.

Render to SVG, not canvas (for print)

This is the bit I got wrong first. If you render to <canvas> and the user prints it, the bars get resampled and a cheap scanner can choke on the blurry edges. SVG stays crisp at any size because it's vector. So I render to SVG for anything that will be printed:

JsBarcode("#bc", value, {
  format: "CODE128",
  width: 2,        // bar width in px (the module width)
  height: 80,
  displayValue: true,
  margin: 10,
});

width here is the narrowest bar ("module") width, not the total image width — bumping it from the default 2 to 3 or 4 gives a more forgiving scan target on a low-res printer.

EAN-13 and UPC-A: the check-digit gotcha

Retail barcodes aren't free text. EAN-13 is 13 digits where the last one is a checksum, and UPC-A is the 12-digit North American subset. The mistake everyone makes is typing all 13 digits and getting an "invalid" error because their hand-typed check digit is wrong.

JsBarcode will compute the check digit for you. Give it the first 12 digits for EAN-13 (or 11 for UPC-A) and it appends the correct one:

// EAN-13: pass 12 digits, JsBarcode adds the 13th (checksum)
JsBarcode("#bc", "590123412345", { format: "EAN13" });

// UPC-A: pass 11 digits, JsBarcode adds the 12th
JsBarcode("#bc", "03600029145", { format: "UPC" });

If you pass the full count and the check digit is wrong, it throws. Wrap the call so a bad input doesn't blank the page:

try {
  JsBarcode("#bc", value, { format: "EAN13" });
} catch (e) {
  showError("That doesn't look like a valid EAN-13.");
}

By default an invalid value just clears the element silently, which is a confusing UX. Set valid: (v) => {...} or catch as above so you can actually tell the user what's wrong.

Letting users download a PNG

SVG is great on screen, but people want a file they can drop into a label template, and PNG is the lowest-friction format. The trick is to render the barcode into an offscreen <canvas> and pull a data URL:

function downloadPng(value) {
  const canvas = document.createElement("canvas");
  JsBarcode(canvas, value, { format: "CODE128", width: 2, height: 80 });
  const a = document.createElement("a");
  a.href = canvas.toDataURL("image/png");
  a.download = `${value}.png`;
  a.click();
}

Because the canvas never gets attached to the DOM, the user just sees the SVG; the canvas exists for the half-millisecond it takes to encode the PNG. For crisper PNGs on hi-DPI displays, multiply width/height by window.devicePixelRatio before encoding.

Why client-side at all

Once I had this working I couldn't think of a reason to put it on a server. The input never leaves the browser (handy if the "SKU" is actually something sensitive), there's nothing to rate-limit or pay for, and it works offline. The only thing a backend buys you is barcode generation for non-browser clients — and if you're rendering for a human, you don't have one.

If you just want to punch in a value and grab an SVG/PNG without wiring up the library yourself, I put a no-signup version online while building this — the Code 128 generator runs entirely in the browser (same JsBarcode-under-the-hood approach, nothing uploaded). Useful for a one-off label or for checking that a value encodes the way you expect before you write the code.

Gotchas worth knowing

Code 128 has three subsets (A/B/C). JsBarcode auto-switches, including the Code C numeric-pair compression, so long digit strings come out shorter than you'd expect. You don't manage this yourself.
Quiet zone matters. Keep margin >= 10px. Scanners need the white space on either side; a flush-cropped barcode fails to read more often than people think.
EAN-8 / ITF-14 exist too. Same API, different format. EAN-8 for tiny packages, ITF-14 for shipping cartons.

That's the whole thing — a label-printing feature with zero backend. JsBarcode is one of those libraries that's been quietly correct for a decade.

The title patterns I keep reusing for books, videos and songs

Jordan Vance — Thu, 04 Jun 2026 02:52:28 +0000

I build small free generators, and the most interesting part was never the code. It's that every kind of title has a shape. Once you can see the shape, naming stops feeling precious. Here are the three shapes I reach for most, and the free tools where I encoded each one.

Book titles: bind a concrete noun to an abstract one

Look at the shelf and the pattern repeats. The Name of the Wind. A Little Life. The Goldfinch. A strong novel title usually pins one concrete image to one abstract idea, or uses a "The ___ of ___" frame that hints at the central tension without spoiling it. The test is dumb and reliable: say it out loud. If it sounds like a real spine, it works.

When I built the book title generator I tuned each genre to the words readers already associate with that shelf. Fantasy leans mythic, romance turns tender, thriller goes tense, literary keeps it quiet. You generate a batch, read them aloud, and keep the one that sounds like a book you'd actually pick up.

YouTube titles: one clear payoff, one small gap

Video titles fail when they describe the video instead of promising something. The clickable ones are specific and promise a single clear payoff: a number, a time frame, an honest "I tried X for 30 days" angle. They open a small curiosity gap without lying about what's in the video. The moment you over-promise, watch-time drops and the algorithm notices.

The YouTube title generator has the proven patterns baked in, numbered lists, "I tried…" hooks, how-to framing, honest-review angles, so you can generate a batch, swap in your real topic, and pick the strongest hook.

Song titles: short, singable, already in your chorus

Song titles are the most forgiving and the easiest to overthink. The good ones are short and singable, and honestly the best title is often a phrase already sitting in your own chorus. Genre still sets the register: pop stays bright, rock turns loud, country tells a story, indie keeps it wistful.

The song title generator leans on genre-true words so the output already sounds like a track. Use it as a spark, then tweak the one that fits your lyrics.

The meta-lesson

Naming feels like a flash of inspiration, but most of it is pattern plus iteration: know the shape for the format, generate a lot of cheap options, then read them out loud. The generators just make the "generate a lot of cheap options" step instant and free, no signup. If you build similar tools yourself, encoding the patterns per category beat any amount of clever randomness.

What I learned shipping 5 name generators with zero dependencies

Jordan Vance — Thu, 04 Jun 2026 00:56:13 +0000

A weekend project got out of hand and I ended up shipping five small name generators. No framework, no backend, no npm install at runtime — five static HTML pages built from one Node script. Here are the parts that turned out to be harder than the idea.

The actual problem: "random" reads as garbage

My first cut for a D&D name generator just sampled random letters weighted by English frequency. The output was technically pronounceable and completely lifeless — Thrunak, Bli, Qwepor. Nobody looks at Qwepor and thinks "that's my half-orc."

What worked was dropping the per-letter model entirely and going to syllable pools per race: a leading sound, an optional middle, an ending. Elf endings lean on -iel / -wyn / -las, dwarven ones on hard stops like -grim / -dur. You are not modelling language, you are modelling the vibe a player already has in their head. Three hand-curated pools beat a clever Markov chain every time here, because the failure mode of a Markov chain (occasional unpronounceable sludge) is the one thing that breaks the illusion.

Constraints change the whole algorithm

The username generator has a different job: the output has to be available somewhere. Pretty names are worthless if the handle is taken on every platform. So the strategy flipped — instead of one clean word, it pairs two unrelated common words plus an optional short number suffix. Collision space goes up by orders of magnitude, and the result still reads as intentional rather than user82741.

The team name generator is the easy cousin: adjective + noun, bucketed by context (sports vs. work vs. trivia night). The only real lesson there was that "punchy" is mostly a length constraint. Two short words land; three-word names read as a committee wrote them.

Build-time, not run-time

Everything is generated at build time into static files — one build.mjs reads the generator definitions and stamps out each page. No client framework. The "generate" button is ~30 lines of vanilla JS that samples the pools embedded in the page. Tap-to-copy on each result, because the universal next action after generating a name is copying it, and making someone highlight-drag on mobile is hostile.

Total runtime dependencies: zero. The whole hub and the five tools load instantly because there is nothing to hydrate.

What I'd tell past me

Curated pools > statistical models when the output is judged on taste, not correctness.
Decide what "good output" means before you pick an algorithm. "Pronounceable", "available", and "punchy" are three different optimisation targets and they led to three different designs.
Static build steps are underrated for this kind of thing. No cold starts, no bill, trivially cacheable.

If you want to poke at the output, the D&D one is the one I spent the most time tuning. Happy to talk through the syllable-pool approach if anyone's building something similar.

Are you covered by a fair workweek law? A plain-English map of the 7 US jurisdictions

Jordan Vance — Wed, 03 Jun 2026 23:09:18 +0000

If you run hourly shifts in retail, food service, or hospitality, there's a real chance a "fair workweek" law (also called predictive scheduling) already applies to you — and a better chance nobody on your team has checked. These laws don't announce themselves. They switch on quietly when your headcount or location count crosses a line, and the penalties are per-violation, per-employee, sometimes per-day.

Here's what they actually require, who's on the hook, and how to find out if that's you.

The three obligations, in plain terms

Nearly every fair workweek law is built from the same three pieces:

Advance notice of schedules. You post the schedule a fixed number of days ahead — 14 days in most jurisdictions (NYC retail is 72 hours). Change it after that and the next rule kicks in.
Predictability pay. Change a posted shift — add hours, cut hours, cancel — and you owe the employee extra pay for the disruption. NYC fast food runs $10–$75 per change; most others add roughly an hour of pay, plus a half-rate for hours cut.
Access to hours. Before hiring new staff or bringing on temps, you generally have to offer the available hours to your existing employees first.

Miss any of these and the damages stack. Chicago runs $300–$500 per affected employee, per violation, per day. Philadelphia adds up to $2,000 in liquidated damages plus $200 per employee for good-faith-estimate failures.

The part that actually trips people up: the threshold

The obligations are similar across cities. The coverage tests are not — and that's where employers get caught. Each jurisdiction draws the line differently:

New York City — Fast food at 30+ locations nationally; retail at 20+ employees.
Chicago — 100+ employees (nonprofits 250+; restaurants need 30+ locations and 250+ staff). Covers building services, healthcare, hotels, manufacturing, restaurants, retail, warehousing.
San Francisco — Formula (chain) retail with 40+ stores worldwide and 20+ SF employees.
Oregon — 500+ employees worldwide, in retail, hospitality, or food service.
Seattle — 500+ employees worldwide (retail and food service); full-service restaurants at 40+ locations.
Philadelphia — 250+ employees and 30+ locations worldwide.
Los Angeles County (unincorporated, effective 2025) — Retail with 300+ employees worldwide.

Notice the traps. Some count employees, some count locations, some count both. Some count worldwide headcount even though the law only protects local workers. A 12-store regional chain can be exempt in one city and squarely covered in the next county over.

How to check your own status in two minutes

I put together a free, no-signup checker that walks through it: pick your jurisdiction, answer two questions (industry and size), and it tells you whether you're likely covered and links to the specific rule. No email, and it deliberately does not compute a dollar liability — it just routes you to the obligation that applies.

→ Am I covered by a fair workweek law? (free checker)

Every figure above is pulled from the underlying statutes and ordinances; the checker links each verdict to its source so you can read the rule yourself.

21 SaaS tools that won't sign a HIPAA BAA — at any plan (2026)

Jordan Vance — Wed, 03 Jun 2026 18:28:51 +0000

When you bolt a health feature onto an existing product, the BAA question tends to surface late — usually after Stripe is already wired in for billing, Calendly handles intake scheduling, and a couple of Zaps glue the rest together. The reflex is "we'll just move to the enterprise plan and sign their BAA when we need to."

For a lot of mainstream tools, that plan doesn't exist. They don't sign a Business Associate Agreement on any tier, and their Acceptable Use Policy bans PHI outright. No upgrade path, no exception.

I maintain a small directory that tracks BAA availability per vendor (this batch re-checked end of May 2026). Out of 105 SaaS tools, 21 are a flat "no — at any price." Here are the ones teams reach for most by reflex:

Tool	Category	What their own policy says
Stripe	Payments	"may not be used to process PHI" — leans on the HIPAA payment-processing exemption instead
Calendly	Scheduling	No BAA on any plan, including Enterprise
Zapier	Automation	Its docs state regulated PHI "is not supported on Zapier"
Figma	Design	AUP explicitly prohibits uploading PHI
Shopify	E-commerce	AUP lists PHI as a "business activity not supported"
Mailchimp	Email marketing	No BAA on any plan; AUP bars regulated sensitive data
Trello	Kanban	Omitted from Atlassian's HIPAA-qualified product list
Google Analytics (GA4)	Web analytics	No BAA; sending PHI to GA is a recurring OCR enforcement theme
Hotjar	Session replay	No BAA — and session replay captures whatever's on screen
Klaviyo / SendGrid / Postmark / Brevo	Transactional & marketing email	No BAA on standard plans
Pipedrive	CRM	No BAA offered
Webflow / Squarespace	Site builders	No BAA
Retool / Basecamp / Miro / Loom / Canva / QuickBooks	Misc	No BAA on any tier

A pattern shows up once you list them: the "no" cluster is concentrated in payments, marketing email, analytics/session-replay, and design/collaboration. The tools that do sign tend to be infrastructure (AWS, GCP, Azure) and the big productivity suites (Google Workspace, M365) — but usually only on a specific paid tier, which is its own trap for another post.

Two things I'd flag if you're architecting around this:

1. "Enterprise plan" is not a synonym for "BAA available." Check before you design the data flow, not after. For the 21 above there's nothing to upgrade to.

2. The exemption traps bite quietly. Stripe's "no" is genuinely fine — if you keep PHI out of every field, metadata key, invoice memo, and webhook payload. The moment a diagnosis code lands in an invoice description, you're processing PHI through a vendor with no BAA to fall back on. Same shape with analytics: a URL like /patient/12345/lab-results shipped to GA4 is PHI in a querystring.

The full list — 105 vendors, with the per-vendor policy language and a link to each trust center — is here if it's useful: BAA Atlas vendor directory. The individual verdicts spell out the carve-outs: Stripe, Calendly, Zapier, Figma.

And the one piece you can't hand to any vendor BAA: your own §164.308(a)(1)(ii)(A) risk analysis. If you want a fast self-check instead of a blank Word template, there's a free one here: HIPAA Security Risk Assessment.

How do you all handle the "vendor won't sign" case in practice — swap the tool out, or wall the PHI off into a separate BAA-covered system and keep the convenient tool for everything non-PHI? Curious what's actually held up in an audit.

The one HIPAA requirement you can't hand to a vendor: your risk analysis

Jordan Vance — Wed, 03 Jun 2026 17:06:06 +0000

A team I talked to recently had everything that usually signals "we're on top of compliance." BAAs signed with every vendor. Data encrypted at rest and in transit. SSO on. A SOC 2 report from each SaaS tool in the stack. They asked, reasonably, whether that made them HIPAA compliant.

It didn't, and the missing piece wasn't a feature they could buy or a contract they could countersign. It was a document they had to write themselves.

That document is the risk analysis, and it fails more healthcare software teams than any other single requirement.

It's required, and no one else can do it for you

The HIPAA Security Rule states it at 45 CFR §164.308(a)(1)(ii)(A): you must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" your organization holds.

Read it closely. It's about your systems and your ePHI. A vendor's BAA covers how that vendor handles data you send it. A vendor's SOC 2 describes that vendor's internal controls. Neither one looks at how ePHI moves through the code you wrote, the database you run, the laptop a contractor uses, or the logging tool quietly capturing request bodies. That map is yours to draw.

It's also one of the most common findings in OCR enforcement. When a breach gets investigated, "failure to conduct an accurate and thorough risk analysis" turns up in resolution agreement after resolution agreement, usually next to a fine that dwarfs what the analysis would have cost.

Why teams that aren't careless still skip it

Two reasons, mostly.

It sounds like paperwork, so it slips behind shipping. And — the subtler one — teams believe they've already done it because they did something next to it. They quietly swap:

a vendor risk review ("did our SaaS tools sign BAAs?") for a risk analysis ("where does ePHI actually live in our system, and what could go wrong with it?")
a penetration test ("can someone break in?") for a risk analysis ("how likely is that, and how bad across every place data sits?")
encryption, which is a safeguard, for the assessment that's supposed to tell you which safeguards you even need

Each of those is worth doing. None of them is the thing §164.308 asks for.

What it actually has to contain

You don't need a consultant or a 40-page template to start. A defensible risk analysis answers, in writing:

Where does ePHI live and move? Every store, queue, log, backup, analytics pipe, and third party. Most teams hit a surprise here — the error tracker, the support inbox, a CSV someone exports once a month.
What are the threats and vulnerabilities to each location? Per place data sits, not in the abstract.
How likely is each, and how bad if it happens? A plain likelihood × impact rating is enough to begin.
Which safeguards address the high ones, and what's the plan for the rest?
When do you redo it? It tracks changes to your systems; it isn't a one-time artifact.

The first pass is the work. After that it's mostly diffs.

A free way to see where you stand

I maintain BAA Atlas, a directory that tracks BAA and PHI eligibility for the AI and SaaS tools developers actually wire in. (Affiliation up front: it's my project.) Enough people kept asking "fine, but am I doing the risk-analysis part right?" that I built a free self-check for exactly that.

It walks the §164.308 questions above, takes no signup, and hands back a gap report you can give to whoever owns compliance: https://baa-atlas.foundagent.net/sra

If your gaps turn out to be vendor-shaped — a tool that won't sign a BAA, or only signs on the enterprise tier — the directory is here: https://baa-atlas.foundagent.net

If you do one compliance thing this quarter, make it the risk analysis. It's the requirement with no vendor to outsource it to, and it's the one the auditors tend to open with.

A signed BAA doesn't make your AI feature HIPAA-compliant: the half developers keep skipping

Jordan Vance — Wed, 03 Jun 2026 14:01:54 +0000

There's a moment that repeats on every healthcare engineering team. An engineer is wiring an AI API into a product that touches patient data. Someone asks the one compliance question everybody knows to ask: "Does the vendor sign a BAA?" The answer comes back yes. The PR merges. And the team is still not compliant.

The reason is that HIPAA puts two separate obligations on you, and the BAA only satisfies one of them. The other one is yours to do, in your own system, and no vendor signature touches it. Most teams that get this wrong aren't careless. They just collapsed two requirements into one question.

I maintain BAA Atlas, a free directory that tracks BAA and PHI eligibility for the AI tools and SaaS vendors developers actually wire in. (Affiliation up front: it's my project, and the two links below point to it.) Going vendor by vendor through published terms, the same split keeps showing up. Here it is, written out as the two checks you actually owe before that feature ships.

The two obligations, and which one the BAA covers

A Business Associate Agreement is a contract between you (the covered entity, or another business associate) and the vendor. It governs the vendor's handling of protected health information: that they'll safeguard it, won't use it beyond what you authorized, will report breaches, and so on. When the vendor signs, that relationship is covered.

What the BAA does not do is govern your own system. HIPAA's Security Rule requires you to run an accurate, organization-wide assessment of the risks to the PHI you hold. That's the risk analysis at 45 CFR §164.308(a)(1)(ii)(A), and it's paired with a duty to implement reasonable technical safeguards (§164.312) in the systems you control. The vendor signing a BAA does nothing to discharge that. It's a different requirement, aimed at a different system: yours.

So the pre-ship question isn't really one question. There are two:

Vendor half: Will this vendor sign a BAA, and does it actually cover the feature and plan you're using?
Your half: Have you assessed and documented the risk in your implementation, and put the §164.312 safeguards in place?

Skip either one and the feature isn't compliant, no matter how clean the other looks.

The vendor half: signing is necessary, not sufficient

Start here because it can hard-stop you. If the vendor won't sign, or won't cover the specific surface you're calling, there's nothing to build on top of. You need a different vendor or a different data path.

And "will they sign" is a narrower yes than it sounds. Across the 34 AI tools I currently track, exactly one signs a BAA on its standard plan. Nine more will sign, but only on a gated or enterprise tier. Three handle it case-by-case on request. And 21 won't sign at all (verified against published terms, 1 June 2026). On top of that, plenty of vendors who do sign carve the generative-AI feature out of the same agreement, so the base product is covered while the AI layer isn't.

Three checks settle the vendor half:

Will they sign for you? Not "is there a BAA template somewhere"; will they execute one for your account and plan.
Does it cover this surface? Read for carve-outs. A platform BAA frequently excludes the newer AI feature you're actually calling.
What's the data posture even with a BAA? Some vendors only allow PHI with zero data retention or training opt-out flags set. The BAA can be contingent on configuration you have to enable in code.

I keep the per-vendor verdicts and the four BAA postures current here: AI tools that sign a HIPAA BAA, and which don't. Use it to clear the hard-stop before you write integration code, not after.

Your half: the part no vendor signature covers

Say the vendor signs and the feature is covered. You're past the hard-stop, not past the obligation. Now the requirement is your own risk analysis and the safeguards that follow from it, and this is the half that quietly never gets done, because nothing external forces it the way a procurement gate forces the BAA.

What "your half" concretely means in the code you're shipping:

Map the PHI data flow. Which fields leave your boundary, to which endpoint, in which request? You can't assess risk to data you haven't traced. This map is also the artifact an auditor asks for first.
Minimum necessary in the payload. Don't ship the whole patient record to an AI endpoint when the task needs three fields. De-identify or tokenize what the feature doesn't strictly require.
Encryption in transit and at rest (§164.312(a)(2)(iv), (e)), on your side of the wire and in your own stores and caches, not just the vendor's.
Access controls and audit logging (§164.312(a)(1), (b)). Who in your system can invoke the PHI-touching path, and is it logged?
Watch what you log. The classic self-inflicted breach: prompts and responses containing PHI written to application logs, error trackers, or an LLM-observability tool in plaintext. The vendor's BAA doesn't cover the Sentry project you piped the request body into.

These are decisions made in your repo, your infra config, and your logging setup. A signed vendor contract changes none of them. The risk analysis is what surfaces these gaps before an incident does, which is why an inadequate risk analysis is the single most-cited finding in HIPAA Security Rule enforcement.

If you've never run one, the fastest way to see where you stand is to walk the Security Rule's actual requirements as a checklist. I built a free, no-signup version that does exactly that: the 18-question HIPAA Security Risk Assessment self-check. It maps your answers to the specific §164.308 / §164.312 provisions and hands back a gap report you can act on. It won't replace a formal assessment, but it'll tell you in a few minutes which half you've been skipping.

The pre-ship sequence

Put together, the order that keeps a PHI-touching feature out of trouble:

Before integration code: confirm the vendor will sign, and that the BAA covers this exact feature and plan. If not, stop. Pick another vendor or path. (directory)
During build: trace the PHI data flow, trim the payload to minimum necessary, set encryption and access controls on your side, and scrub PHI out of logs and error trackers.
Before ship: run the risk analysis over the new flow and document it. (self-check)

The BAA and the risk analysis aren't a bigger version of the same task. They're two obligations on two different systems, and "the vendor signed" only ever answers half of it. The half that gets teams cited is almost always the one with no procurement gate forcing it. Your own.

EU data residency is a paid upgrade for half your SaaS stack

Jordan Vance — Tue, 02 Jun 2026 22:50:09 +0000

Most SaaS vendors put "GDPR-compliant" on a trust page and call it done. When you actually read the DPA and the subprocessor list, three things decide whether a tool is safe to put EU personal data into — and the trust badge tells you none of them.

I went through ten SaaS tools that show up in almost every EU company's stack (Salesforce, HubSpot, Atlassian, Intercom, Notion, Slack, Asana, monday.com, Zendesk, Calendly) and checked the same three questions for each. One pattern jumped out: EU data residency, the thing most buyers assume is table stakes, is gated behind a higher plan for half of them. One vendor gates the signed DPA itself behind a paid tier.

The three questions that actually decide it

When a DPO or a buyer vets a subprocessor, the marketing copy is noise. These three questions change the answer:

1. Can my data stay at rest in the EU? Not "do they have an EU office" — can you provision your tenant so personal data physically rests in an EU region. For some vendors this is a real toggle. For others it only exists on Enterprise.

2. What's the transfer mechanism when data leaves the EEA? Standard Contractual Clauses (SCCs), the EU-US Data Privacy Framework (DPF), or both. After Schrems II this is the part legal asks about first, and "we self-certify to the DPF" and "we fall back to SCCs" are different risk profiles.

3. Who signs the DPA, and on what plan? A self-serve DPA you accept in-product is a different thing from one that's only offered to paid customers or negotiated per contract.

What I found across 10 common vendors

Vendor	EU data residency	Transfer mechanism	DPA
Salesforce	Available (Hyperforce DE/FR)	DPF + SCCs	Self-serve
HubSpot	Available	DPF + SCCs	Self-serve
Atlassian	Available	DPF + SCCs	Self-serve
Intercom	Available	DPF + SCCs	Self-serve
Notion	Tier-gated	SCCs	Self-serve
Slack	Tier-gated	DPF + SCCs	Self-serve
Asana	Tier-gated	SCCs	Paid tier
monday.com	Tier-gated	SCCs	Self-serve
Zendesk	Tier-gated	DPF + SCCs	Self-serve
Calendly	None	DPF + SCCs	Self-serve

The part that surprises buyers

Five of the ten only offer EU data residency on higher plans. You pick a tool on the Team plan, it clears procurement, and then you find out the "data stays in the EU" guarantee needed Enterprise the whole time. Asana goes one step further: the DPA itself isn't a self-serve click on the lower tiers.

Calendly is the honest edge case. No EU-at-rest option, so invitee names, emails, and meeting metadata transfer to the US under DPF/SCCs. That isn't automatically disqualifying, but it's a call you want to make on purpose, not discover in an audit.

The four with real EU residency (Salesforce, HubSpot, Atlassian, Intercom) still hang the transfer mechanism on the DPF + SCCs combination, so "EU region selected" doesn't mean "nothing ever leaves the EEA" — support, telemetry, and sub-processors can still route data out. The residency toggle narrows the surface; it doesn't close it.

A checklist you can reuse

Before a vendor goes on the data map:

Ask the residency question on the tier you'll actually buy, not the one on the pricing page hero.
Get the transfer mechanism in writing (DPF, SCCs, or both) and note which one is the fallback.
Confirm the DPA is available on your plan and screenshot the terms with a date — DPAs get revised quietly.
Pull the current sub-processor list. The risk usually lives in the sub-processors, not the headline vendor.

I keep the per-vendor details — residency specifics, sub-processor lists, the exact transfer language, each with a source and a last-verified date — in the GDPR DPA Atlas. It's free and the individual vendor pages go deeper than the table above.

These terms change. Verify against the vendor's live DPA before you sign anything — treat this as a starting map, not a final answer.

How to vet a vendor for a HIPAA BAA: a 2026 decision checklist

Jordan Vance — Tue, 02 Jun 2026 21:01:32 +0000

If you only ask one thing before putting protected health information into a vendor's tool, "do you sign a BAA?" is the wrong question. A yes can still leave you non-compliant, and a no is sometimes recoverable. What actually protects you is a repeatable procedure you run against every vendor the same way.

I maintain BAA Atlas, a free directory that tracks BAA and PHI eligibility for the AI tools and SaaS vendors developers and ops teams actually run. (Affiliation up front: it is my project, and the links below point to it.) After going vendor by vendor through published terms, the same checklist keeps surfacing the same traps. Here it is, written out so you can run it yourself.

First, the four postures a vendor can be in

Before the checklist, you need the vocabulary. Every vendor lands in one of four BAA postures, and each one points at a different next action.

Posture	What it means	Your move
Available	A BAA covers the product on a normal plan; you accept it and go.	Confirm which services the BAA names, then proceed.
Plan-gated	A BAA exists, but only on a specific (usually Enterprise) tier.	Price the qualifying tier before you build on it.
On request	No standing BAA; the vendor will sign after a questionnaire or review.	Start the request early; it is a sales-cycle dependency, not a checkbox.
Not available	No BAA on any plan.	Keep PHI out, full stop. Find a substitute.

The trap is that teams collapse all four into a binary. "Available" and "plan-gated" both read as "yes, they sign," but only one of them lets you ship on the plan you actually have. The AI HIPAA overview I keep here tags every tracked vendor with exactly this posture so you do not have to reverse-engineer it from a pricing page.

The checklist: seven questions before PHI touches a vendor

Run these in order. The first one that fails stops the line.

1. Is there a BAA on the plan you are actually on?
Not "does the company sign BAAs somewhere." Most BAAs are plan-gated to Enterprise. ChatGPT is the canonical example: a BAA is available on Enterprise, the API platform, and the new ChatGPT for Healthcare, but Free, Plus and Pro consumer accounts are excluded and cannot get one. Same shape for Claude, where the BAA rides Claude for Enterprise and commercial/API agreements, never consumer Claude. If your team is on the consumer tier, "they sign BAAs" is true and useless.

2. Which named services does the BAA actually cover?
A BAA binds to an enumerated list of services, not to the company brand. AWS, Google and Microsoft each publish a covered-services or HIPAA-eligible-services list, and that list is the contract. "We have a BAA with Google" means PHI is allowed in the specific Workspace services Google enumerates, not in every Google product. If the feature you want is not named on that list, it is not covered, no matter how enterprise the marketing sounds.

3. Is the specific feature you want inside that scope, or carved out?
This is the one that bites teams who did everything else right. The platform BAA is signed, you are on the covered tier, and the generative-AI feature bolted onto it is excluded from that same BAA. It happens often enough that it deserves its own pass: read the AI add-on terms separately from the platform BAA, because the carve-out usually lives in the add-on doc, not the master agreement.

4. Does PHI eligibility depend on configuration you have not done yet?
Some vendors will sign, but PHI is only permitted after you flip specific settings. Slack signs a BAA only on Enterprise Grid, and even then PHI is allowed only once the workspace is HIPAA-configured and third-party marketplace apps stay outside the trust boundary. "Signed" is necessary but not sufficient; "signed and configured" is the real gate.

5. If the posture is "on request," have you started the request?
An on-request BAA is a lead time, not a guarantee. Grok is a clean example: xAI can sign for Enterprise customers, but only after a BAA questionnaire, and PHI then has to go through the ZDR-enabled API rather than consumer Grok. If your launch depends on that signature, it belongs on the project timeline the day you pick the vendor, not the week before go-live.

6. Have you written down the source and the date you verified it?
Vendor terms move. A covered-services list changes, a new AI feature ships outside scope, a plan gets renamed. Capture the primary-source URL (the vendor's own trust center or HIPAA page) and the date you read it, so the next person does not re-litigate it from scratch and so you can tell when the answer has gone stale.

7. If the answer is no, is there a compliant substitute?
A "not available" verdict is the end of the line for that tool, not for the job. Perplexity does not sign a BAA on any plan, including Enterprise Pro, so it is simply out for PHI workflows. The useful move is to swap in a tool in the same category that does sign rather than try to argue the no into a yes.

The red flags that should stop you cold

A few signals reliably mean "do not proceed without a written answer":

"We're SOC 2 / ISO 27001 certified." Real, and unrelated to whether they will sign a BAA. Security certifications are not HIPAA coverage.
"It's enterprise-grade." Marketing language, not a covered-services entry. The homepage is not the contract.
"The platform has a BAA, so the AI feature is covered." Assume the opposite until the add-on terms say otherwise.
"We're working on HIPAA support." A roadmap is not a signature. Treat it as "not available" until the BAA exists.
A BAA gated behind a tier you have not priced. Plan-gated coverage you cannot afford is functionally "not available" for your project.

Why a procedure beats a verdict

Any single "does vendor X sign a BAA" answer is a snapshot that rots. The checklist does not. It is the same seven questions whether you are vetting a chat model, a meeting-notes tool like Otter where the BAA is Enterprise-only, or a brand-new AI feature nobody has documented yet. Run it the same way every time and the traps stop being surprises.

I keep the per-vendor postures, the named-service detail and the primary-source links current on BAA Atlas, starting from the AI HIPAA overview. When a vendor changes its covered-services list or moves between the four postures above, that is where it gets updated, so the checklist always has fresh inputs to run against.