DEV Community: Jack-hao615

Why we charge $2.99 per headshot instead of a $29 subscription

Jack-hao615 — Sun, 15 Nov 2026 15:53:39 +0000

I built AmiHeadshot because I needed a headshot for my own team page, and every service I found wanted to sell me a subscription or a 40-photo bundle. I needed four photos. One afternoon, done. The pricing mismatch stuck with me long enough that I ended up building the thing I wanted to buy.

Here's the case for per-image pricing, and why I think the bundle model is quietly broken for most people who just need a LinkedIn photo or a company page avatar.

The bundle math doesn't work for single-use buyers

HeadshotPro charges $29 for 40 headshots. Aragon starts at $35 for 20. BetterPic starts at $35 for 20. These are real prices I checked before building anything.

If you're a job seeker updating your LinkedIn once a year, or a founder who needs four photos for the about page, you're paying $29-35 and using maybe 5-10% of what you bought. The other 35 photos sit in a zip file you'll never open. The per-photo cost you actually paid isn't $0.73 — it's $7.25 per photo you'll actually use.

I kept doing this math for people I know. A realtor who needed one listing photo. A grad student who needed a thesis defense portrait. A speaker who needed a conference bio photo. Every single one needed fewer than five images, and every service wanted to sell them twenty or forty.

The subscription model is even worse. $19/month for unlimited headshots sounds reasonable until you realize most people generate headshots once, maybe twice a year. You're paying $228/year for a task that takes ten minutes.

What per-image pricing actually looks like

AmiHeadshot charges $2.99 per image. That's the whole pricing model. No credits, no subscription, no minimum order. You pick from 32 studio styles, choose poses, upload one selfie, and pay for the count you want. Five images cost $14.95. One image costs $2.99.

The generation quality is the same whether you buy one image or twenty. There's no "premium tier" with better models or faster processing. The AI pipeline (fal direct, identity-preserving edit, face-similarity gate at 0.93) runs identically for every order.

This means the person who needs one photo for a conference bio pays $2.99 and gets the same result as someone who buys ten for a full team page refresh. The pricing is honest about what you're actually getting.

The privacy math matters too

Most headshot services keep your uploaded selfie indefinitely, or bury the deletion policy in a privacy policy you'll never read. Some use uploads for model training. You find out after the fact, if you find out at all.

AmiHeadshot deletes uploads automatically after 30 days. Never used for model training. Finished images stay downloadable for 90 days. These aren't premium features or privacy tier upgrades — they're the default for every order, including the $2.99 single-image one.

I think this matters more than pricing, honestly. Your face is biometric data. A service that charges you $29 and then trains on your selfie is charging you twice: once with money, once with your face.

Where the bundle model actually wins

I want to be fair here. Bundles make sense if you're a content creator who needs fresh headshots monthly, or an agency generating photos for clients regularly. The per-photo cost drops fast at volume, and the convenience of having a credit balance you can dip into is real.

But that's not most people. Most people need headshots once, maybe twice. The bundle model optimizes for the power user and charges everyone else for capacity they'll never touch.

What I'd change if I were starting over

I'd probably add a small bundle option — say, 5 images for $12.99 — for the people who genuinely need a set. Not because the math demands it, but because some buyers feel more comfortable with a "package" even when the per-unit price is the same or worse. That's a psychology problem, not a pricing problem.

I'd also be more upfront about the generation time. Five images typically finish in under a minute, but the first-time user doesn't know that. The pricing page should say "five photos, about a minute, $14.95" instead of making you do the math yourself.

Try it if you need one photo

AmiHeadshot is live. 32 styles, $2.99 per image, uploads deleted after 30 days. If you need four photos for a team page, that's $11.96 and about a minute of your time. If you need one photo for a conference bio, that's $2.99.

We're launching on Product Hunt on November 18 if you want to follow along or ask questions there.

I'm Jacky, the maker. Happy to answer questions in the comments — about the pricing model, the generation pipeline, or why I think the AI headshot market has a honesty problem.

30 PDF Tools, Zero File Uploads — What Running pdf-lib in the Browser Actually Takes

Jack-hao615 — Mon, 14 Sep 2026 16:04:27 +0000

Every online PDF tool asks you the same uncomfortable question: do you trust us with this file?

Merge a contract. Redact an ID scan. Compress last year's tax records. The honest answer for most tools is "your file goes to a server, gets processed, and you have to believe our retention policy." We built AmiPDF around the opposite default: if a task can run in the browser, it must run in the browser. That turns out to be about 30 out of our 40+ tools.

This post is the architecture rundown — what client-side PDF processing actually looks like, where it bites, and the honest list of things we still run server-side.

The stack, in one paragraph

Two libraries carry almost everything:

pdf-lib for every write operation: merge, split, rotate, page numbers, watermarks, crop, metadata, encryption.
pdf.js for every read/render operation: page previews, the workspace viewer, text extraction for search-based redaction.

Everything else is glue. The site itself is static hosting behind a CDN — no accounts, no database, no session state. When you merge three PDFs on AmiPDF, your browser opens the files with FileReader, hands bytes to pdf-lib, and gets a Blob back. The file never crosses the network.

What is genuinely easy

The bread-and-butter operations are embarrassingly simple once you accept one mental model: a PDF is just bytes you transform locally.

import { PDFDocument } from 'pdf-lib'

const merged = await PDFDocument.create()
for (const file of files) {
  const src = await PDFDocument.load(await file.arrayBuffer())
  const pages = await merged.copyPages(src, src.getPageIndices())
  pages.forEach(p => merged.addPage(p))
}
const out = await merged.save()

That is a working merge tool. Rotate, reorder, extract pages, stamp page numbers, attach watermarks — all the same shape: load, transform, save. None of it needs a server, and none of it ever did. The reason most sites upload your file anyway is that servers made their analytics, quotas, and upsells easier — not because the browser couldn't do it.

Where it bites

Three problems ate most of our debugging time.

1. pdf.js text layers lie about spaces

Our redaction tool works like a search box: type a word, we highlight every occurrence, you click to black it out. That means mapping your query onto the rendered text layer. Except pdf.js inserts spaces where a PDF only has glyph-position changes — runs that visually touch get a space inserted between them, and runs that overlap can also produce phantom whitespace.

The fix is unglamorous: normalize whitespace on both sides, and keep an offset map from normalized positions back to original text-layer nodes so a match lands on the right highlight rect. If you're building anything that searches inside rendered PDFs, budget real time for this. It was the single worst bug of the entire project — search "worked" except on documents where it silently matched nothing.

2. Memory is the real quota

Server-side tools limit uploads by policy. Client-side tools get limited by physics: a 200 MB PDF is 200 MB in an ArrayBuffer, and pdf-lib will copy it more than once while saving. We tuned compression to stream where possible and to do page-level work (rotate one page, extract a range) without materializing multiple full copies. Practical ceiling on a mid-range phone is lower than on a desktop, and the honest move is to say so in the UI rather than let the tab crash.

3. Fonts

Embedding fonts for watermarks and page numbers means carrying font bytes you usually don't have. Standard 14 fonts get you surprisingly far; everything beyond that is a subsetting problem.

The honest server-side list

Three categories genuinely cannot run in a browser at acceptable quality, and pretending otherwise would be worse than the upload:

Office ↔ PDF conversion. LibreOffice in a headless container does this properly. No browser-side library matches it for fidelity.
OCR. Tesseract has WASM builds, but for scan-heavy documents the native server build is dramatically faster and produces a real text-embedded PDF via its PDF renderer.
High-fidelity PDF → Word/Excel/PPT. Layout reconstruction is a research-grade problem; we run a two-engine pipeline with different speed/quality tradeoffs.

For those lanes the rules are: files are deleted immediately after the job, we keep no accounts (there are none), and we don't log file contents. "Server only when necessary" only means something if the exceptions are named, so we name them.

The economics nobody mentions

Client-side processing isn't just a privacy stance — it inverts the cost model. A conversion server bills you per megabyte forever; a static site bills you (almost) nothing per user. That is why AmiPDF has no signup and no daily limits: the marginal cost of the 30 browser tools is close to zero, so charging or nagging would be artificial scarcity.

The server lanes are metered and rate-limited because they cost real CPU — and that's fine, because they're the minority of tasks.

Try it

amipdf.com — 40+ tools, 14 languages, no account. If you have a privacy-sensitive workflow, I'd genuinely like to know which tool you'd want verified as fully local next.

We're launching on Product Hunt soon — if browser-first tools are your thing, keep an eye out.