DEV Community: Ahnhyeongkyu

We shipped 4 SaaS products and made almost nothing. Here's what we got wrong.

Ahnhyeongkyu — Tue, 02 Jun 2026 15:21:32 +0000

Three of our four products can take payments right now. Combined, they've made almost nothing. For a while I thought the hard part was building them. That was the easy part. Here's the honest version, and what we're changing.

How it's set up

We run this as a small AI-agent operation. One terminal acts as the CEO: strategy, what to build, reviewing the work. Another is the CTO and writes the actual code. The products: a stats helper, a testimonial widget, an AI resume builder, a timeboxing app.

It ships fast. That was never the problem.

What we shipped recently

A normal day:

timebox: pulled out a placeholder "mock user" (everyone saw the same fake data) and wired in real Supabase login
added Pro gating: free tier has limits, Pro unlocks the rest
got cold email running from our own domain with a proper warmup
added UTM tracking across three products so we can see where traffic actually goes

Six commits, all verified, all live.

Where it actually broke

Three products are live and take money. Total revenue is a rounding error.

We kept building and never built a way for anyone to find it. No audience, no distribution. Ship something, post it once, move on to the next build. It felt productive and it was exactly the trap. You can't out-build a distribution problem.

What we're changing

Stop starting new products. We have enough.
Cold email to founders who'd actually use the widget. Real 1:1 reach, not blasting.
Build-in-public (this post included) to grow an audience from zero.
Measure first. Let the data say which product has real demand, then go all-in there instead of guessing.

The numbers are small and we're early. That's the point of writing it down now, while it's still messy. More as it happens.

Build in public, month 2: 615 of 616 visitors never clicked anything

Ahnhyeongkyu — Sat, 30 May 2026 19:32:34 +0000

A follow-up in our series on running a SaaS portfolio with AI agents. Here are the real numbers from this cycle, no spin.

Revenue (LemonSqueezy, statmate): $26.36 lifetime, $6.59 in the last 30 days, $0.00 MRR, 0 active subscriptions. Every dollar so far is one-off credit — not a single recurring subscriber.

Funnel (IME-1, last 14 days):

landing_view: 616
cta_click: 1 (0.2%)
signup_started: 0 (0.0%)
paid_conversion: 0 (0.0%)

Overall landing→paid: 0.00%. The biggest drop is the very first step — 615 of 616 people left without clicking a single CTA.

The lesson we're taking from this: it is not a checkout or pricing problem. You cannot A/B-test a stage that 99.8% of visitors never reach. When almost no one clicks, the bottleneck is upstream — traffic intent, not conversion rate. The one click we did get came from a "word-export-paywall" CTA: someone who wanted a specific utility, not the paid product.

So the honest read on statmate.org: the organic search traffic we attract is task-intent and low purchase-intent. The lever isn't tuning the funnel — it's reaching people who actually intend to pay. More when the next data lands.

The one product with real traffic right now: statmate.org — a stats helper for students/researchers. I'm watching whether build-in-public readers actually click through and convert.

Building something and need social proof that converts? That is what we are building at trustfolio.dev — and I am testing whether this build-in-public audience fits trustfolio better than the stats tool.

An AI runs my company. A solo dev vibe-coded $15K in a week — we made $[X]. A cold autopsy.

Ahnhyeongkyu — Sat, 30 May 2026 15:05:44 +0000

An AI runs my company. Not as a demo — as the actual operator. Two Claude terminals (a "CEO" that does strategy and a "CTO" that writes the code), plus an agent orchestrator that's supposed to behave like a small staff. I am the chairman. I approve money and irreversible actions; the machine does the rest.

Earlier this year a solo builder vibe-coded a product to roughly $15K in a week. Same category of tools I have. Our number, after months and eight shipped products, is $[X] — and $[X] is small enough that I'm using a placeholder out of dignity, not secrecy.

This is the cold autopsy. No hype, no "AI changed everything." Just what actually happened and why.

The numbers, unflattering

8 products shipped. Live, deployable, real auth, real checkout wiring on several.
~0 paying customers.
One product (a small stats utility) has real organic traffic — hundreds of search clicks and thousands of users a month. Paid conversion: effectively zero.
The rest range from "launched to silence" to "domain now 404s."

If you only looked at the build output, you'd think this was a competent shop. That was exactly the trap.

Autopsy finding #1: I built a process-theater company

I optimized the org for activity, not outcomes. The agents generated standups, status reports, "daily activity," kanban motion. It looked like a company. It produced almost no revenue.

This isn't a unique personal failing — it's a documented one. There's now a published failure taxonomy for multi-agent LLM systems (search "MAST, Multi-Agent System failure taxonomy"). A large share of failures aren't bad models; they're specification and coordination failures: agents that talk to each other, drift, re-litigate decisions, and confidently report progress on work that doesn't move a real metric. A "99-agent autonomous company" is not an achievement. It's the failure mode with a press release.

The fix isn't more agents. It's fewer, gated, narrow workers whose output is checked by rules, not by another LLM's opinion: did the URL return 200? did a payment land? did the PR merge? did the event fire in analytics? "An agent said it's done" is not evidence.

Autopsy finding #2: build was never the bottleneck

Both the $15K dev and I can build. Building is the commodity now. The difference was everything around the build:

Distribution & audience. The $15K came from a person who already had eyes on them and shipped in public. I shipped quietly into search engines and waited.
Wave & willingness to pay. They rode a hot category where early adopters spend money. I built a calculator for students in a saturated niche where the entire audience wants it free.
Focus. They pushed one thing end-to-end to revenue. I had eight half-finished things and an elaborate fake org chart.

Three orders of magnitude of outcome, and none of the gap was the code.

Two technical war stories (because this is Dev.to)

The company brain died from a cron interval.

The agent backbone runs on serverless Postgres (Neon free tier). Free-tier compute auto-suspends after 5 minutes idle — that's the whole cost model. At some point I "improved" responsiveness by bumping the agent heartbeat cron from every 30 minutes to every 5 minutes. Feels harmless.

It wasn't. A query every 5 minutes means the compute never gets a 5-minute idle window. It stayed awake 24/7 — roughly 720 compute-hours/month against a free allowance closer to ~190. One day every query started returning:

HTTP 402: "exceeded the compute time quota"

Six tables — agents, tasks, messages, approvals, events — all unreachable. The "company brain" was down, and it had been quietly burning toward this for weeks. Lesson: with scale-to-zero infra, your cron interval is a billing decision. If it's at or under the suspend threshold, you've silently bought an always-on server.

Worse: I had a daily quota monitor. It never fired — because it was pointed at the wrong database (a legacy connection string), so it cheerfully reported "OK" while the real DB suffocated. Monitoring you don't verify is theater too.

One webhook, four products, silent cross-contamination.

Several products check out through the same payment provider. That provider sends all sales to a single account-level ping URL. So a sale for product A was hitting product B's webhook and — because the handler trusted the payload — granting entitlements in the wrong app. The fix was a per-product discriminator (url_params[workspace_id]) and a foreign-sale guard that drops anything that isn't ours. Multi-tenant billing is mostly about refusing events, not processing them.

What the renewal actually is

No grand relaunch. Concrete moves:

Kill process theater. Retire the agent-as-staff fiction. Keep a few narrow workers with rule-based output gates.
Redefine "done." "Done" = a test payment goes end-to-end (checkout → entitlement → feature works). Everything before that is a demo, and gets called a demo.
Distribution is now first-class, co-equal with building — including writing this, in public, with the embarrassing number left in.
Measure conversion, not motion. Real funnel events or it didn't happen.

The honest close

We made $[X]. I'm not going to dress that up. But the diagnosis is unusually clear, and clear diagnoses are rare and cheap to act on: the machine can build all day; what it couldn't do is pick a market with a wave, earn an audience, and call a shell what it is.

If you want to watch the renewal happen — including whether it works — the one product with real users is a small stats helper at statmate.org, and the credibility-portfolio experiment is at trustfolio.dev. Both are deliberately public lab rats now.

I'll post the next number whether it's up or down. That's the deal with building in public — the autopsy only counts if you keep the table open.

We shipped a 5KB testimonial widget that uses AI to pick the most persuasive review

Ahnhyeongkyu — Thu, 28 May 2026 14:53:44 +0000

Testimonials are the highest-leverage copy on your landing page. Most SaaS founders ship the worst three they have.

The problem we ran into

We were running a normal SaaS landing page. Twelve testimonials. Pretty headshots. Real customers.

Conversion was flat.

When we A/B tested swapping the testimonial block in and out, the lift was within margin of error. We started reading the actual reviews. Two of them were great. The other ten were variations of "the product is good and the team is friendly."

Polite. True. Useless.

We were doing what every SaaS founder does: dumping every review we could collect into a section and hoping volume = trust. It doesn't.

What we shipped

trustfolio — a testimonial platform that collects reviews from your customers, scores each one on a 0-100 conviction scale using an LLM, and embeds the highest-converting ones on your site via a widget that ships in under 5KB.

Three things make this different from the spreadsheet you're using now:

1. A conviction score, not a star rating

Five stars tells you a customer didn't hate you. It doesn't tell you whether the review will convert anyone.

We score every incoming testimonial against four axes:

Specificity — does it name a measurable outcome ("cut onboarding from 3 weeks to 4 days") or a vague feeling ("really helpful")?
Objection-handling — does it dismantle a doubt a prospect would have?
Identifiability — does the reader picture themselves in the customer's shoes?
Tension and resolution — does it tell a story, or is it a sentence?

A 92-conviction testimonial belongs on your hero. A 41 belongs in the archive.

2. Smart highlights instead of full quotes

A 180-word testimonial buries the line you want. We surface the 12 words that actually do the work, link them to the full quote on click, and serve the rest only if the reader keeps reading.

This is one of the largest lifts we see in customer A/B tests: average widget click-throughs went up 2.3x when we replaced full quotes with smart highlights.

3. A 5KB widget that respects your Lighthouse score

Most testimonial widgets are 60-200KB of React + dependencies. They tank LCP and tag along third-party fetches.

Ours ships as a single self-contained ESM bundle: 4.8KB gzipped, zero runtime deps, lazy-loads the rest only when the widget enters the viewport.

<script async src="https://cdn.trustfolio.dev/v1/widget.js"
        data-project="your-slug"
        data-layout="card-row"></script>

That's the whole install. Six layouts available, all under the same size budget.

What we learned building this

A few things were not obvious until we shipped it:

Conviction scoring needs anchoring examples. The first version of our scorer drifted: the same review would get a 71 one day and an 86 the next. We fixed it by anchoring each score to a fixed reference set of customer-graded examples. Drift dropped to single digits.

Customers will give you better reviews if you ask better questions. The default "leave a review" prompt produces "great product." A 3-question collection form (situation → friction → outcome) produces reviews that score 30+ points higher on conviction, on average.

Video is hard, but solvable. We chose to do auto-transcription + AI-pulled timestamps for the moment in a video where the customer says the thing. Video testimonials with auto-pulled highlight clips outperformed text on our own funnel.

Pricing

Free — 15 testimonials, one widget layout, basic AI analysis. Good for landing pages with light traffic.
Pro — $29/mo — unlimited text, 50 video/mo, all 6 layouts, full AI features.
Business — $79/mo — unlimited projects + video, A/B testing, API, white-label.

No credit card on free.

Try it

If you have a landing page and ten or more existing testimonials, drop them into trustfolio in 5 minutes and see what your highest-conviction quote actually is. Most founders are surprised.

trustfolio.dev — Show customer reviews, convert 34% more.

If you ship this on a real page, I'd love to hear about your lift in the comments. We're collecting before/after numbers across the launch cohort.

I Tried 10 ChatGPT Resume Prompts. Here's What Actually Got Me Interviews.

Ahnhyeongkyu — Tue, 28 Apr 2026 03:49:21 +0000

I sent 47 applications with my old resume. 0 callbacks.

Then I tried 10 ChatGPT prompts I'd been collecting. I sent the next 12 applications with rewritten resumes. 4 callbacks. Here are the prompts that actually worked, and the ones that wasted my time.

The pattern that worked: every prompt that produced something useful was specific about output format and gave the model permission to leave things blank. Every prompt that failed was vague.

Prompt 1: STAR with [needs metric] markers

"Rewrite my resume bullets using the STAR method (situation, task, action, result). Use the job description below as context. If a bullet doesn't have a measurable result, mark it [needs metric] instead of inventing one."

This was the unlock. The "[needs metric]" instruction stopped ChatGPT from hallucinating numbers. Half my old bullets came back marked, which forced me to actually go check Slack archives and find real outcomes. The other half came back tightened.

Prompt 2: Keyword gap analysis (don't add — identify)

"Read the job description. List the 10 most important keywords (skills, tools, methodologies) it uses. Then check my resume and tell me which keywords I'm missing or underusing."

Don't ask the AI to add keywords. Ask which ones are missing. Then you decide which ones genuinely apply.

This is critical for ATS without resume-stuffing — the bot detects keyword density above ~2-3% and downgrades you for it.

Prompt 3: 3-sentence summary cap

"Rewrite my summary in 3 sentences max. Sentence 1: who I am professionally. Sentence 2: my biggest measurable achievement. Sentence 3: what I'm looking for next."

The 3-sentence constraint is what makes this work. Without the cap, ChatGPT writes corporate filler ("results-driven professional with a passion for...").

Prompt 4: ❌ "Make my resume more impressive"

The one that failed for me. Vague prompts produce vague output. Skip.

Prompt 5: Multi-dimension scoring

"Compare my resume to the job description. Score the match 0-100 across these 5 dimensions: keyword overlap, experience relevance, seniority match, industry fit, recency. Explain each score in one sentence."

Forces structured feedback you can actually act on. "Your industry fit is 30/100 because the JD mentions 'fintech' 4 times and your resume has none" is fixable. "Your resume could be better" is not.

Prompt 6: Weakness audit

"What's the weakest bullet on my resume? Why is it weak? Suggest a rewrite if I provide more context — but if you don't have enough context, ask me 1 specific question."

The "ask me a question" branch is what makes this useful. Most ChatGPT outputs are confidently wrong. This forces it to admit when it needs more info.

Prompts 7-10

I'll spare you the full list. The structure is what matters:

Specific output format (numbered, capped, marked)
Permission to leave things blank ([needs metric], "I don't know")
Cap on length (3 sentences, 5 bullets, 100 words)
Compare-don't-fix framing (score it before fixing it)

After spending a weekend running these manually...

I built ResumeAI to do all 10 automatically. Same prompts (refined), career-situation branching (switcher / returning / new grad / senior), and 23-criteria ATS scoring built in.

It's $9 once. No subscription.

If you want to do it manually, the 5 prompts above are enough. If you want it in 30 seconds, that's the link.

When Paddle Live Checkout Silently Broke - A Literal Backslash-N Debugging Story

Ahnhyeongkyu — Sat, 18 Apr 2026 23:27:52 +0000

The symptom

Paddle's domain approval for trustfolio.dev came through on a Thursday afternoon. I flipped the environment from sandbox to production, clicked Upgrade on my own dashboard, and got an overlay saying "Something went wrong. Please try again later."

No stack trace. No meaningful Paddle.js error object — just { error: {}, meta: {} } when I tried to capture it. Production logs looked fine. Webhook endpoint responded 200 OK for test pings. All the env vars were set. All the Paddle dashboard pieces existed.

I spent an afternoon staring at this before figuring it out.

The hypothesis that was wrong

My first guess: Paddle's live API needed something the sandbox didn't. Maybe a tax category, maybe a stricter domain verification. I re-read the Paddle dashboard twice. Everything looked correct.

Then I tried Paddle.PricePreview — the client-side preview API — with the production price ID I had pulled from my Vercel env. It threw the same blank error.

So I copied the price ID directly out of the Paddle dashboard and used that string instead of the env var. PricePreview worked immediately. Subtotal $79, discount $0, total $79.

The problem was in my environment variable.

The culprit

I pulled all seven PADDLE_* env vars down with vercel env pull and inspected the raw bytes of each value's tail:

PADDLE_BUSINESS_PRICE_ID  last6hex=7a 33 67 68 5c 6e

The last two bytes are 0x5c and 0x6e — a literal backslash followed by the letter n. Not a real newline (0x0a). Just the two characters \n stuck onto every value as a plain string.

I had written a defensive envTrim() earlier in the day that used JavaScript's String.prototype.trim() to strip whitespace. But trim() only removes actual whitespace — space, tab, newline, carriage return. It does not remove the two-character string \n.

So when my webhook compared priceId === process.env.PADDLE_BUSINESS_PRICE_ID, it was really comparing 'pri_01knw040zen6akf7mrncx5z3gh' to 'pri_01knw040zen6akf7mrncx5z3gh\n'. Equality test failed silently. The webhook fell back to its default branch and labeled every incoming purchase as a Pro subscription, regardless of what was actually bought.

The fix in two layers

Layer 1 — code is defensive from now on. I replaced every .trim() in the Paddle code path with a regex that handles both whitespace and literal escape sequences:

const envTrim = (v) => v ? v.replace(/(?:\\n|\\r|\s)+$/g, '').replace(/^(?:\\n|\\r|\s)+/g, '') : '';

This catches the case even if somebody copy-pastes an env var with a trailing \n again in the future.

Layer 2 — Vercel env vars are now clean. A one-shot Node script pulled each variable, stripped the trailing junk, and re-registered it with vercel env rm / vercel env add. After a redeploy, the raw bytes looked exactly as expected. PricePreview and Checkout both succeeded immediately.

How the bad characters got there

I never typed \n into a Vercel env value on purpose. My best guess is that I pasted from a terminal or a note where a line ending got escaped as the literal two-character sequence, and Vercel stored it verbatim. Vercel's UI doesn't render trailing control characters, so the value looked clean in the dashboard.

This is the kind of bug where the platform behaves correctly by any reasonable definition. The string you give it is the string it stores. The surprise is entirely in the mismatch between what you think the string is and what it actually is.

Lessons worth carrying forward

When an API returns a blank error object, suspect your own input before suspecting the service. Especially for services like Paddle that have been running at scale for years. The bug is usually on your side.
Hex-inspect env vars when checkout mysteriously breaks. vercel env pull plus a five-line Node script saved me hours.
Defensive trimming should handle literal escape sequences, not just whitespace. Especially for values that cross system boundaries — env vars, webhooks, CSV imports.
Keep a webhook-inspection utility ready. My DB monitor that printed every workspaces row change let me see exactly where the plan comparison was going wrong.

Why this matters for SaaS reliability

Checkout reliability is the whole game for a paid SaaS. A silent 5% failure rate on upgrade attempts is more expensive than any growth channel. If you run a small SaaS, take an afternoon and try to break your checkout in weird ways — paste env vars from a shell history, use a discount code for an unrelated product, hit the checkout from a Safari incognito window. You will find at least one bug. The question is whether you find it or a paying customer does.

Trustfolio collects customer testimonials, scores them with AI for conversion potential, and embeds them anywhere with a single <script> tag. Free tier, no credit card.

👉 trustfolio.dev

How Trustfolio's testimonial widget stays under 5KB — while the rest of the market ships 65–125KB

Ahnhyeongkyu — Sat, 18 Apr 2026 07:59:18 +0000

I've been running Trustfolio for a few months now, and the one decision that keeps coming up in sales calls is the widget bundle size.

People don't buy a testimonial tool because it's 4.8KB. But they stop looking at alternatives the moment they realize the competitor's widget drops their Lighthouse score by 15 points.

So here are the exact choices that kept our embed under 5KB while the category average sits at 65–125KB gzip.

The benchmark (measured with Chrome DevTools, 2026)

Widget	Layout	Transfer size (gzip)
Testimonial.to	Wall	125 KB
Senja	Carousel	65 KB
Famewall	Wall	88 KB
Trustfolio	Wall	4.8 KB
Trustfolio	Carousel	3.9 KB
Trustfolio	Badge	2.1 KB

These numbers came from Chrome DevTools' Network tab with the "Disable cache" + "Slow 3G" options. I'm comparing equivalent rendered outputs, not the vendor's marketing numbers.

Choice #1 — Ship vanilla JS. No framework runtime.

Every competitor I audited ships some flavor of React or a micro-framework at runtime. React plus ReactDOM alone is ~45KB gzip — that's already 9x our entire widget.

Our embed is a single IIFE. It reads the data-trustfolio attribute, fetches JSON from an edge route, and renders DOM directly. No JSX, no virtual DOM, no reconciler.

const init = async () => {
  for (const mount of document.querySelectorAll('[data-trustfolio]')) {
    const id = mount.dataset.trustfolio;
    const data = await fetch(`https://trustfolio.dev/api/widgets/${id}/data`).then(r => r.json());
    const shadow = mount.attachShadow({ mode: 'closed' });
    render(shadow, data);
  }
};
init();

render() is a small set of layout functions (wall, carousel, badge, popup, marquee, card) that directly assemble DOM nodes. Each layout lazy-loads its handlers on first interaction — carousel's swipe handler is only fetched when the user actually swipes.

Choice #2 — Shadow DOM, not CSS-in-JS.

Testimonial widgets have to deal with hostile host styles. Your widget might be rendered inside a WordPress theme that has * { box-sizing: border-box } on every element, or a Tailwind Preflight that strips all default margins.

Most vendors solve this by shipping their styles inline or via CSS-in-JS — which is why you see styled-components or emotion in their bundles.

We use a closed Shadow DOM. The shadow root has its own style scope. No host style can leak in. No widget style can leak out. And we don't ship a runtime because the browser handles encapsulation natively.

Stylesheet is a <style> element inside the shadow, declarative, zero runtime.

Choice #3 — `async` script + `navigator.sendBeacon`.

The script is async, so it never blocks rendering. Impression and click analytics use navigator.sendBeacon, which queues the request in the browser's network stack and returns instantly — no awaiting a fetch promise, no perf regression on user interaction.

function track(event, data) {
  const blob = new Blob([JSON.stringify({ event, ...data })], { type: 'application/json' });
  navigator.sendBeacon('/api/analytics', blob);
}

The analytics endpoint writes to an edge-adjacent table. No third-party tracking scripts. No cookies. The widget is GDPR-trivial because it collects nothing a user wouldn't expect.

Choice #4 — No web fonts.

We render testimonials with font-family: system-ui, -apple-system, sans-serif. Native UI font on every platform. Zero KB of font download. Zero FOIT/FOUT.

Competitors that load Google Fonts pay 20–80KB per weight for the privilege of a slightly prettier wall of quotes. Not worth it.

Choice #5 — Bundle once, not per layout.

All six layouts share the same bundle. Dead-code elimination via esbuild removes unused layouts at build time — but the runtime itself is one file. The tradeoff: the carousel user downloads ~0.7KB of wall-specific code they'll never run. The win: one HTTP request instead of six, one cached URL instead of a cache-busting nightmare per layout combination.

What this unlocks for customers

Shopify product pages that still score >95 on Lighthouse with social proof embedded.
Framer landing pages that keep their signature "single HTTP request" speed.
WordPress sites that don't need to install a plugin (just a <script> tag).

None of this is magical. It's just a refusal to ship more than the feature requires. Every line of code I considered adding, I asked: "does this change what the user actually sees?" If not, it didn't go in.

The wider point

A lot of modern SaaS ships weight by default because frameworks make it easy and bundlers don't warn you until it's already too late.

Testimonial widgets are a small niche, but the same pattern applies to every embedded SaaS asset — chat bubbles, cookie banners, analytics scripts, A/B testing agents. They accumulate until your site is 60% third-party JS.

If you're building one, the question worth asking is: what's the smallest thing that still delivers the feature? Not "what's the easiest stack to reach for?"

Trustfolio collects customer testimonials, scores them with AI for conversion potential, and embeds them on any site with a single <script> tag. Free tier, 15 testimonials, no credit card.

👉 trustfolio.dev

PS: for the first founder reading this, FOUNDER100 gives you 100% off the first month of Pro or Business. 24 hours, one use.

I Built a Testimonial.to Alternative — Here's What I Learned

Ahnhyeongkyu — Mon, 13 Apr 2026 18:02:53 +0000

I've been shipping products for a while now — StatMate, RoastSite, CodeNeat, RestInLight, and a few others. Every single one of them had the same problem: I'd get great feedback from users in DMs and emails, but none of it was visible on my landing pages.

I looked at Testimonial.to. Great product, $2.4M ARR, clearly solving a real problem. But three things bugged me:

The widget was heavy. Loading a 50KB+ widget to show three quotes felt wrong.
CSS conflicts were constant. Their widget styles would clash with my Tailwind setup.
No intelligence layer. All testimonials were treated equally.

So I built Trustfolio. Here's the technical story.

Shadow DOM for Style Isolation

If you've ever embedded a third-party widget on your site, you know the CSS collision nightmare. Shadow DOM solves this completely. The widget renders inside an encapsulated DOM tree with its own scoped styles. Zero leakage in either direction.

The result: embed one line of code, and the widget looks exactly the same on every site, regardless of what CSS framework the host page uses.

The Sub-5KB Challenge

Competitors ship 50-125KB widget bundles. Ours is under 5KB. How?

No framework runtime (vanilla JS, no React/Vue/Svelte)
No CSS-in-JS library
No external font loading
Aggressive tree-shaking and minification
Single IIFE bundle, zero external dependencies

AI Conversion Scoring

This is the experimental part. Every testimonial gets analyzed on ingestion:

Sentiment detection — genuine enthusiasm vs. polite filler
Specificity scoring — "saved 10 hours/week" scores higher than "great tool"
Conversion prediction — 0-100 score based on specificity + emotion + outcome mentions

Where I Am Now

Product is live at trustfolio.dev
Free tier: 15 testimonials, full AI features
Pro: $29/mo, Business: $79/mo
Using it on all my own products (dogfooding)

What I'd love feedback on: Is AI conversion scoring genuinely useful, or is it solving a problem that doesn't exist?

Happy to answer any technical questions in the comments.

I Built 8 Developer Tools That Never See Your Code

Ahnhyeongkyu — Sun, 12 Apr 2026 22:59:28 +0000

The Moment I Realized the Problem

A few months ago, I was debugging a production issue at midnight. I had a large JSON config file that was not parsing correctly. I did what every developer does — I opened the first Google result for "json formatter online" and pasted my config.

Then it hit me. That config contained database connection strings, API keys, and internal service URLs. I opened DevTools and checked the Network tab.

Sure enough: a POST request carrying my entire input to the site's server. My production credentials had just traveled across the internet to a server I knew nothing about.

I checked three more popular formatting sites. Same pattern. Every one of them sent the input to their backend for processing.

This Is Not a Theoretical Risk

Think about what developers paste into online tools on a daily basis:

JSON files containing API keys, database credentials, and service configurations
Base64 strings that encode authentication tokens and binary data
SQL queries revealing table names, column structures, and business logic
JWTs containing user identities, roles, and session data
Regex patterns tested against real production data
Code diffs showing proprietary source code changes

The leading online developer tool sites handle tens of millions of visits per month. That is an enormous volume of sensitive developer data flowing through third-party servers every day.

And here is the thing: none of these operations require a server. JSON formatting, Base64 encoding, URL encoding, regex matching, text diffing, JWT decoding, SQL formatting, hash generation — all of these can be done entirely in the browser with JavaScript.

So I Built CodeNeat

CodeNeat is a set of 8 developer tools where every operation runs 100% in your browser. No data is ever sent to any server for processing.

The 8 Tools

1. JSON Formatter & Viewer
Format, validate, minify, and explore JSON with syntax highlighting and interactive tree view.

2. Base64 Encode/Decode
Encode and decode Base64 strings. Instant results with zero server round-trip.

3. URL Encode/Decode
Full Unicode support for URL encoding and decoding.

4. Regex Tester
Real-time matching with capture groups and flag controls.

5. Diff Checker
Side-by-side text comparison with line-level highlighting.

6. JWT Decoder
Decode and inspect JWTs — header, payload, signature, expiration.

7. SQL Formatter
Multi-dialect SQL formatting. Your queries never leave the browser.

8. Hash Generator
MD5, SHA-1, SHA-256, SHA-512. All computation via Web Crypto API.

How It Works

Each tool is a pure TypeScript function in lib/tools/:

// lib/tools/json.ts
export function formatJson(input: string, indent: number = 2): string {
  const parsed = JSON.parse(input);
  return JSON.stringify(parsed, null, indent);
}

These functions are imported directly into React client components. No fetch(). No XMLHttpRequest. No server endpoint.

How to Verify

Method 1: DevTools

Open any tool on codeneat.dev, open DevTools Network tab, filter by Fetch/XHR, use the tool. Zero processing requests.

Method 2: Offline

Load any tool, disconnect from the internet, use the tool. It works because the processing never needed a server.

Method 3: Source Code

Open source: github.com/Ahnhyeongkyu/codeneat. Search for fetch( in lib/tools/. Zero results.

The Stack

Framework: Next.js 16 with App Router
Language: TypeScript
Styling: Tailwind CSS v4 + shadcn/ui
Deployment: Vercel
License: MIT

What Is Next

A Chrome extension that brings these tools into the browser toolbar. The core logic ports directly since it is pure functions.

Try It

codeneat.dev — free, no account required.

If useful: Star on GitHub to help others discover it.

Your code should stay yours. That is not a feature — it should be the default.

Stop Shipping 300KB Testimonial Widgets — There's a Better Way

Ahnhyeongkyu — Sat, 28 Mar 2026 04:29:09 +0000

If you've ever added a testimonial widget to your site, you probably noticed the performance hit. Most popular solutions load 200-300KB of JavaScript, inject iframes, and tank your Core Web Vitals.

I run five different web products. Every one of them needed social proof. And every testimonial tool I tried made the same trade-off: nice-looking widgets that quietly destroyed page speed.

So I built Trustfolio.

The Problem

Here's what a typical testimonial widget does to your site:

200-300KB of JavaScript loaded on every page
Layout shift from async-loaded content
Extra DNS lookups and third-party connections
No way to know which testimonials actually drive conversions

How Trustfolio Is Different

1. Under 5KB Widget

The entire embed script is under 5KB gzipped. It uses Shadow DOM for style isolation, loads async, and renders in under 100ms. Zero layout shift.

<div data-trustfolio="YOUR_WIDGET_ID"></div>
<script src="https://trustfolio.dev/embed.js" async></script>

That's it. Two lines. No iframes, no external CSS, no layout shift.

2. AI That Knows What Converts

Instead of manually picking which testimonials to show, Trustfolio's AI analyzes every submission:

Sentiment Analysis — scores emotional tone from 0 to 1
Smart Highlights — finds the most persuasive phrases automatically
Conversion Score — rates each testimonial 0-100 based on how likely it is to drive action
Auto-Tagging — categorizes by topic (support, pricing, features, etc.)

3. Six Widget Layouts

Layout	Best For
Wall of Love	Landing pages, dedicated testimonial sections
Carousel	Limited space, above the fold
Badge	Compact trust signals
Single Card	Hero sections, sidebars
Popup	Exit intent, time-delayed social proof
Marquee	Continuous scrolling banners

4. Multiple Collection Methods

Custom collection pages — branded forms with your questions
Import from CSV — migrate from other tools
Google/G2 imports — pull existing reviews (more sources coming)

Technical Architecture

Next.js 16 with Edge Runtime for the OG image API
Neon (serverless Postgres) via Drizzle ORM
Shadow DOM (closed mode) for widget style isolation
sendBeacon for analytics tracking without blocking
AI analysis powered by Claude API

Pricing

Free: 10 testimonials, 1 widget, wall layout
Pro ($29/mo): Unlimited testimonials, all layouts, AI analysis
Business ($79/mo): Everything + API access, white label, A/B testing

Try It

If you're running a SaaS, portfolio, or any site that shows customer feedback, give it a shot: trustfolio.dev

Free tier is genuinely usable — no credit card, no trial expiration. I'd appreciate any feedback from the dev community.

I Built a Sub-5KB Testimonial Widget Because Every Alternative Tanked My Lighthouse Score

Ahnhyeongkyu — Fri, 27 Mar 2026 11:51:25 +0000

Every testimonial widget I tried added 200-500KB to my pages. My Lighthouse scores dropped. My ads got more expensive because pages loaded slower.

So I built Trustfolio — a testimonial platform where the entire embed widget is under 5KB gzipped.

The Problem

Most testimonial tools treat performance as an afterthought. They load heavy JavaScript bundles, inject their own CSS that conflicts with yours, and add hundreds of milliseconds to your page load.

Research shows each second of delay reduces conversions by 4.42%. If you're running paid ads, slow pages = wasted ad spend.

What I Built

Trustfolio is a full testimonial management platform:

Collect: Shareable collection pages (text + video, no sign-up needed for customers)
Analyze: AI-powered sentiment analysis, theme detection, and highlight suggestions using Claude Haiku
Display: 5 widget layouts — Wall, Carousel, Badge, Popup, Marquee
Track: Conversion tracking to see which testimonials actually drive sign-ups

The embed widget uses Shadow DOM for zero CSS conflicts and loads in under 10ms from CDN.

Tech Stack

Next.js + React
Drizzle ORM + Neon PostgreSQL (serverless)
Clerk Auth (GitHub + Google + Email)
Claude Haiku API for AI analysis
Shadow DOM embed widget (3.1KB gzipped)
Vercel deployment

Try It

Trustfolio is live with a generous free tier — 15 testimonials, 1 widget, full AI analysis. No credit card required.

Check it out: trustfolio.dev

I'd love to hear your feedback!

Regex Lookahead and Lookbehind: Patterns Every Developer Should Know

Ahnhyeongkyu — Wed, 04 Mar 2026 02:40:11 +0000

Lookaheads and lookbehinds are the regex features that separate "I know regex" from "I know regex." They let you match patterns based on what comes before or after — without including that context in the match itself.

Once you understand them, problems that seemed impossible with basic regex become straightforward. Let's break them down.

What Are Lookaheads and Lookbehinds?

Think of regular expressions as a cursor moving through text. Normally, every part of your pattern consumes characters — the cursor advances as it matches. Lookaheads and lookbehinds are different: they peek at surrounding text without consuming it. The cursor looks, but doesn't move.

An analogy: Imagine you're searching a bookshelf for books with red covers. A normal regex is like pulling each book off the shelf to check it. A lookahead is like glancing at the next book without pulling it out. A lookbehind is like glancing at the previous book. You're gathering information, but you're not removing anything from the shelf.

This "zero-width" property is what makes them powerful. You can assert that certain text exists nearby without including it in your match result.

The Four Types: A Syntax Reference

Type	Syntax	Meaning
Positive Lookahead	`(?=...)`	What follows must match
Negative Lookahead	`(?!...)`	What follows must not match
Positive Lookbehind	`(?<=...)`	What precedes must match
Negative Lookbehind	`(?<!...)`	What precedes must not match

The key to remembering the syntax:

= means positive (it does match)
! means negative (it doesn't match)
< means look behind (to the left)
No < means look ahead (to the right)

Now let's put them to work with five real-world examples.

Example 1: Password Validation

The problem: Validate that a password contains at least one uppercase letter, one lowercase letter, one digit, and is at least 8 characters long.

Without lookaheads, you'd need to check each condition separately or write an absurdly complex alternation. With lookaheads, you can stack multiple conditions at the same position:

const passwordRegex = /^(?=.*[A-Z])(?=.*[a-z])(?=.*\d).{8,}$/;

// Test cases
passwordRegex.test('MyPass1234');  // true — has upper, lower, digit, 8+ chars
passwordRegex.test('mypass1234');  // false — no uppercase
passwordRegex.test('MYPASS1234');  // false — no lowercase
passwordRegex.test('MyPassword');  // false — no digit
passwordRegex.test('Mp1');         // false — too short

How it works, step by step:

^ — Start of string
(?=.*[A-Z]) — Lookahead: somewhere ahead there's an uppercase letter. The cursor doesn't move.
(?=.*[a-z]) — Lookahead: somewhere ahead there's a lowercase letter. Still at position 0.
(?=.*\d) — Lookahead: somewhere ahead there's a digit. Still at position 0.
.{8,}$ — Now actually consume: match 8 or more of any character to the end.

All three lookaheads fire from the same starting position. They each independently scan the entire string for their condition. Only when all three succeed does the engine proceed to the actual match.

Adding more rules is trivial. Need a special character too?

const strongPassword = /^(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[!@#$%^&*]).{10,}$/;

Example 2: Extract Prices Without Currency Symbols

The problem: You have text containing prices in various formats and you want to extract just the numeric values, without the currency symbol.

const text = 'Products: $49.99, €120.00, £75.50, $1,299.00';

// Positive lookbehind: match numbers preceded by a currency symbol
const priceRegex = /(?<=[$€£])\d[\d,.]*\d/g;

const prices = text.match(priceRegex);
// => ['49.99', '120.00', '75.50', '1,299.00']

How it works:

(?<=[$€£]) — Lookbehind: the position must be preceded by $, €, or £. This symbol is NOT included in the match.
\d[\d,.]*\d — Match digits, possibly with commas and decimal points in between.

The beauty here is that the currency symbols are used to locate the right numbers but aren't captured. Without a lookbehind, you'd need a capture group and an extra extraction step:

// Without lookbehind (less clean)
const fallback = /[$€£](\d[\d,.]*\d)/g;
const matches = [...text.matchAll(fallback)].map(m => m[1]);

The lookbehind version is more direct and readable.

Example 3: Match Words NOT Followed by Specific Text

The problem: In a codebase, find all uses of import that are NOT followed by type (you want value imports, not TypeScript type imports).

const code = \`
import React from 'react';
import type { FC } from 'react';
import { useState } from 'react';
import type { Props } from './types';
import axios from 'axios';
\`;

const valueImports = /import(?!\s+type)\s+.+/g;
const matches = code.match(valueImports);
// => [
//   "import React from 'react';",
//   "import { useState } from 'react';",
//   "import axios from 'axios';"
// ]

How it works:

import — Match the literal text "import"
(?!\s+type) — Negative lookahead: what follows must NOT be whitespace + "type"
\s+.+ — Then consume the rest of the import statement

The negative lookahead acts as a filter. It says "yes, I found import, but only keep it if type doesn't come next."

Another practical use — excluding test files:

// Match .js files that are NOT test files
const regex = /\w+(?!\.test)\.js/g;

'app.js utils.test.js config.js'.match(regex);
// => ['app.js', 'config.js']

Example 4: Parse Structured Log Files

The problem: You're parsing log entries and need to extract the log level, but only from lines that contain an IP address (indicating network-related events).

Sample log:

2026-03-01 10:15:32 [ERROR] Connection timeout from 192.168.1.100
2026-03-01 10:15:33 [INFO] Cache cleared successfully
2026-03-01 10:15:34 [WARN] Rate limit approaching for 10.0.0.55
2026-03-01 10:15:35 [DEBUG] Query executed in 42ms
2026-03-01 10:15:36 [ERROR] SSL handshake failed from 172.16.0.200

const logs = \`2026-03-01 10:15:32 [ERROR] Connection timeout from 192.168.1.100
2026-03-01 10:15:33 [INFO] Cache cleared successfully
2026-03-01 10:15:34 [WARN] Rate limit approaching for 10.0.0.55
2026-03-01 10:15:35 [DEBUG] Query executed in 42ms
2026-03-01 10:15:36 [ERROR] SSL handshake failed from 172.16.0.200\`;

// Positive lookahead: match log level only if an IP address appears later in the line
const networkLogs = /\[(ERROR|WARN|INFO|DEBUG)\](?=.*\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/gm;

const matches = [...logs.matchAll(networkLogs)].map(m => m[1]);
// => ['ERROR', 'WARN', 'ERROR']

How it works:

\[(ERROR|WARN|INFO|DEBUG)\] — Match the log level in brackets, capturing the level name
(?=.*\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) — Lookahead: somewhere on this line, there's an IP address pattern

Lines without IP addresses (the INFO cache line and the DEBUG query line) are excluded. The lookahead lets you filter on content that appears much later in the line without having to match everything in between.

Combining with lookbehind to extract the IP itself:

// Extract IPs that appear after the word "from"
const fromIPs = /(?<=from\s)\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/g;
logs.match(fromIPs);
// => ['192.168.1.100', '172.16.0.200']

Example 5: Email Username Extraction

The problem: Extract the username portion of email addresses (everything before the @) from a block of text.

const text = \`
Contact us:
  - Support: support@codeneat.dev
  - Sales: sales.team@codeneat.dev
  - Bug reports: bugs+tracker@codeneat.dev
\`;

// Positive lookahead: match word characters (plus dots, hyphens, and +)
// that are followed by @
const usernameRegex = /[\w.+-]+(?=@)/g;

const usernames = text.match(usernameRegex);
// => ['support', 'sales.team', 'bugs+tracker']

How it works:

[\w.+-]+ — Match one or more word characters, dots, plus signs, or hyphens
(?=@) — Lookahead: this match must be followed by @, but don't include @ in the result

Without the lookahead, you'd match the @ and then have to strip it:

// Without lookahead
const fallback = /([\w.+-]+)@/g;
const matches = [...text.matchAll(fallback)].map(m => m[1]);

The lookahead version is cleaner because the match itself is exactly what you want.

Extracting the domain instead (using lookbehind):

const domainRegex = /(?<=@)[\w.-]+/g;
text.match(domainRegex);
// => ['codeneat.dev', 'codeneat.dev', 'codeneat.dev']

Browser and Engine Support

Lookaheads have been supported everywhere for decades. Lookbehinds are newer — here's the current status:

Feature	Chrome	Firefox	Safari	Node.js	Edge
Positive Lookahead `(?=...)`	All versions	All versions	All versions	All versions	All versions
Negative Lookahead `(?!...)`	All versions	All versions	All versions	All versions	All versions
Positive Lookbehind `(?<=...)`	62+	78+	16.4+	8.10+	79+
Negative Lookbehind `(?<!...)`	62+	78+	16.4+	8.10+	79+

Key takeaway: As of 2026, lookbehinds are safe to use in all modern browsers. The only concern is if you need to support Safari 16.3 or older (released early 2023). For server-side JavaScript (Node.js), lookbehinds have been available since Node 8.

If you need to support older environments, you can always rewrite lookbehinds using capture groups:

// Lookbehind version (modern)
/(?<=\$)\d+/g

// Capture group equivalent (universal)
/\$(\d+)/g  // then use match[1]

Common Pitfalls

1. Variable-length lookbehinds: JavaScript supports variable-length lookbehinds, but some regex engines (notably older Python re module) don't. If your pattern works in JS but fails elsewhere, this might be why.

2. Performance with .* in lookaheads: Patterns like (?=.*something) cause the engine to scan the entire remaining string. In tight loops or very long strings, stack multiple specific lookaheads rather than using greedy quantifiers.

3. Forgetting that lookarounds are zero-width: A common mistake is expecting (?=foo)bar to match "foobar". It won't — after the lookahead asserts "foo" is ahead, the cursor is still at the same position, and it tries to match "bar" starting where "foo" starts. You'd want (?=foo)foobar or just foobar.

Test Your Patterns Live

Regex is a skill you build by doing. Reading about lookaheads is useful; writing and testing them is where the understanding clicks.

Test these patterns live at codeneat.dev/regex-tester — it provides real-time match highlighting, capture group visualization, and runs entirely in your browser so your test data stays private.

Paste any of the examples from this article and experiment. Change the patterns, try different inputs, and build intuition for how lookaheads and lookbehinds actually work.

DEV Community: Ahnhyeongkyu

We shipped 4 SaaS products and made almost nothing. Here's what we got wrong.

How it's set up

What we shipped recently

Where it actually broke

What we're changing

Build in public, month 2: 615 of 616 visitors never clicked anything

An AI runs my company. A solo dev vibe-coded $15K in a week — we made $[X]. A cold autopsy.

The numbers, unflattering

Autopsy finding #1: I built a process-theater company

Autopsy finding #2: build was never the bottleneck

Two technical war stories (because this is Dev.to)

What the renewal actually is

The honest close

We shipped a 5KB testimonial widget that uses AI to pick the most persuasive review

The problem we ran into

What we shipped

1. A conviction score, not a star rating

2. Smart highlights instead of full quotes

3. A 5KB widget that respects your Lighthouse score

What we learned building this

Pricing

Try it

I Tried 10 ChatGPT Resume Prompts. Here's What Actually Got Me Interviews.

Prompt 1: STAR with [needs metric] markers

Prompt 2: Keyword gap analysis (don't add — identify)

Prompt 3: 3-sentence summary cap

Prompt 4: ❌ "Make my resume more impressive"

Prompt 5: Multi-dimension scoring

Prompt 6: Weakness audit

Prompts 7-10

After spending a weekend running these manually...

When Paddle Live Checkout Silently Broke - A Literal Backslash-N Debugging Story

The symptom

The hypothesis that was wrong

The culprit

The fix in two layers

How the bad characters got there

Lessons worth carrying forward

Why this matters for SaaS reliability

How Trustfolio's testimonial widget stays under 5KB — while the rest of the market ships 65–125KB

The benchmark (measured with Chrome DevTools, 2026)

Choice #1 — Ship vanilla JS. No framework runtime.

Choice #2 — Shadow DOM, not CSS-in-JS.

Choice #3 — async script + navigator.sendBeacon.

Choice #4 — No web fonts.

Choice #5 — Bundle once, not per layout.

What this unlocks for customers

The wider point

I Built a Testimonial.to Alternative — Here's What I Learned

Shadow DOM for Style Isolation

The Sub-5KB Challenge

AI Conversion Scoring

Where I Am Now

I Built 8 Developer Tools That Never See Your Code

The Moment I Realized the Problem

This Is Not a Theoretical Risk

So I Built CodeNeat

The 8 Tools

How It Works

How to Verify

Method 1: DevTools

Method 2: Offline

Method 3: Source Code

The Stack

What Is Next

Try It

Stop Shipping 300KB Testimonial Widgets — There's a Better Way

The Problem

How Trustfolio Is Different

1. Under 5KB Widget

2. AI That Knows What Converts

3. Six Widget Layouts

4. Multiple Collection Methods

Technical Architecture

Pricing

Try It

I Built a Sub-5KB Testimonial Widget Because Every Alternative Tanked My Lighthouse Score

The Problem

What I Built

Choice #3 — `async` script + `navigator.sendBeacon`.