DEV Community: taewoo

19 days, 546 messages, 141 users: building my app by mostly talking to Claude Code

taewoo — Sat, 24 Oct 2026 06:00:59 +0000

I make Tabby, a free tab manager for Chrome, Firefox and Edge. This week I shipped version 1.2 and made a "lock in" short for TikTok and YouTube in three languages.

I barely wrote code for any of it. Mostly I talked to Claude Code in plain Vietnamese ("this looks ugly", "the text is cut off", "the music is wrong"), looked at what it showed me, and said yes or no.

People keep asking me three things: how long it takes, whether it actually works, and what it costs. So here are my real numbers, plus the times it misunderstood me.

🎬 1.2 video: https://youtu.be/rFEa6yeJnX8
🎬 The short: English · 日本語 · 中文

What got done

Tabby 1.2:

29 themes, 6 of them free (Graphite, Catppuccin, Dracula, Zen Garden, Sakura, Capy Chill)
12 languages
a calmer board and a new Home page
new store pages in every language
a 51-second promo video

The "lock in" short: someone fills a year of work into Tabby, one line at a time, cut to the beat. It ships in English, Japanese and Chinese, each in a different theme.

How long, and how much talking

	Time	My messages	Tokens	Cost at API prices*	Versions thrown away
Tabby 1.2, plan to release	about 1 day (Oct 22 night → Oct 23 evening)	58	888M	~$316	0 (fixed in review rounds)
Lock-in short: plan, 3 versions, 2 more languages, posting	about 3.5 hours	45	207M	~$55	2
The whole project so far (since Oct 5)	19 days	546	2.5B	~$909

* I worked this out from the token counts in Claude Code's logs, priced at Opus API list prices. I'm on Claude Max, a flat monthly plan, so this isn't what I paid. It's what the same work would cost through the API. Most of those tokens are Claude re-reading the project, which is billed at the cheap cached rate.

For scale, 58 messages is about one long chat with a friend.

What came out of it (so far)

141 users on the Chrome and Firefox stores, 19 days after the first line of code. Rating 5.0 from 3 reviews.
3.4K views and 6.7 hours of watch time on YouTube.
About $6 of API-priced AI time per user so far ($909 ÷ 141).
On the short, one message from me every ~5 minutes (45 in 3.5 hours). Claude did the rest.

It's early, and these are small numbers. But this is one person, and the "team" is a chat window.

How I actually work with it

I say what I want like I'd say it to a person. "Make a version in Japanese and Chinese, different themes, and a more positive hook." No specs.
It plans first, and I approve the plan. Early on it changed my website before I'd seen the plan. Now there's a rule in its memory file: show the plan, wait for my OK, then build.
It shows me, not tells me. Screenshots, a 2-second demo clip, a page with the options drawn side by side. I can judge a picture in five seconds.
It reviews itself before I see it. For the big parts, I let a second Claude review the first one's work and score it. They went back and forth until it hit 9–10/10. One night I said "review it to 10/10, then build it" and went to sleep. In the morning it was done.

Where it got me wrong, and how we found out

1. "The fonts don't match the design."
I noticed every theme looked slightly off. Claude compared each screen against the design, one by one, and found that the app's font had never loaded. Not in any theme, not since day one. Chrome's own default style was quietly winning.

Who found it: I did, by looking. All the automatic tests had passed.
Fix: one rule, the same morning.
Lesson: tests check that things work, not that they look right. Look at it yourself.

2. A button was cut off in Vietnamese.
It looked fine in English. In Vietnamese the third button fell off the edge.

Who found it: I did.
Fix: Claude fixed the button. It also added a check that opens every screen at phone width in all 12 languages and fails if anything sticks out.
Lesson: one bug report becomes a test, so the same bug can't come back.

3. The short: it made an ad. I wanted a vibe.
I showed it a trending TikTok. Its first two versions filmed the whole app, with lots of lines popping in at once. They were accurate, and nobody could read them on a phone.

Why it got it wrong: it was trying to show off the product. The trend only works when you see one line being typed, close up, and the app stays in the background.
How I fixed it: I sent one screenshot of a video with 7k likes and said "like this, never the whole dashboard". I also asked it to write that down as a rule.
Result: version 3 got it right, and the Japanese and Chinese versions needed no changes from me.

4. The music was the wrong song.
It found the trending sound on TikTok. That turned out to be a sped-up re-upload, not the original.

Who found it: I did. It just sounded off.
Fix: I sent YouTube links to the originals. It re-measured the beat and moved every cut onto the new beats. One version still had the drop 0.2 s early, and Claude caught that itself on review.

5. It said too much.
An early cut had a caption: "so I locked in". I said: show, don't tell. Now the only words on screen are a browser tab title at the start and the link at the end.

What I'd tell anyone trying this

Your job becomes taste and saying no. Most of my 58 messages were "no, because…" or "yes, do it".
Make it show you a small demo before it builds the big thing. A 2-second clip saves an hour of wrong renders.
When it gets something wrong, ask it to write the lesson down. Then you only have to say it once.
Look at the result yourself. Every important bug here was found by a human looking, not by a test.
Count the cost in your time, not only in dollars. 103 messages from me covered a release and four videos.

Tabby is free with no account: https://tabby.taewoo.me/?s=devto

If you work with an AI agent too, how do you stop it from building the wrong thing?

Payment Integrations in Two Days with Claude Code

taewoo — Wed, 21 Oct 2026 17:10:53 +0000

Adding a new payment provider used to take me about a week. Over the last five integrations at a payments company, it took one to two days each, and reviewers found fewer missing cases. The AI didn't get smarter in between. I changed the order of the work, and I stopped letting the agent that wrote the code also judge it.

This post is for engineers who integrate third-party APIs, payments or not, and wonder how far to trust an AI coding agent. You'll get the five steps I use, the rule that decides what to build first, and the one bias that makes AI review useless if you don't break it.

The week was never spent on typing

Most of an integration week goes into reading and checking, not writing code.

Think of a restaurant taking on a new supplier. Cooking is quick. The slow part is learning the supplier's catalogue, deciding what happens when a delivery is late or wrong, and making sure nobody pays for the same crate twice.

A payment integration is the same: read the provider's docs, map their payment statuses to yours, list what can go wrong (duplicate webhooks, unknown statuses, timeouts), write the code and tests, then explain it all to a reviewer who has never seen this provider.

Before you read on, guess which step I now spend the most time on. It's the first one, before any code exists.

Five steps: script, fixtures, build, fresh review, check

The rule: I decide what "correct" means before the agent starts, and a different agent checks the result.

[UPLOAD IMAGE HERE: /Users/taewoo/hustle/profiles/x-images/01-workflow-5-steps.png]

Script (me). I write the scenarios and the goals: concrete checks the finished code must pass. Each goal calls the code and compares the result against a fixture, or calls the provider's sandbox when there is one. I also rank the risks low, medium and high. High is anything that loses or doubles money: status mapping, the idempotency key (the ID that makes a repeated request safe to apply twice), and whether polling stops at the right moment.
Fixtures (Claude Code). A fixture is a saved example response from the provider. If the provider has a sandbox, the agent calls it and saves the real JSON; I can use that same JSON to test before integrating anything. If there's no sandbox, the agent fetches the docs and builds fixtures from them.
Build (Claude Code). High-risk logic gets written first, while everyone is still paying attention. Familiar parts just follow our existing conventions. The phase isn't done until every goal passes.
Review (a fresh agent). A new session gets only the diff and the goals. More on why below.
Check (me). A skill exports two things: a map of every critical decision in the code, and JSON requests so I can re-test the API in one pass. I read the map, not the whole diff.

Engineers call these reusable instructions skills: saved recipes Claude Code loads for one kind of task. The risk map in step 5 is one of them.

Decide the scary cases before the agent does

The most valuable rules are the ones written before any code: what happens when something unexpected arrives.

My favourite example: an unknown status becomes pending, plus an alert. Payment providers add statuses without telling you. If the code guesses, it might mark an unpaid order as paid, or a paid order as failed. Parking it as pending loses nothing, and the alert means a human looks at it the same day.

I learned this one from a code review, not from an AI. The new code met a status it didn't recognise, raised an error, caught it and carried on. That looked harmless. But further down, a shared rule said: if a payment's status hasn't changed by the end of processing, mark it failed. So every unknown status quietly became a failed payment. Payments that might have gone through were recorded as failed, the success rate dropped, and nobody could tell why, because "failed" hid the real cause. The fix was to stop guessing: park it as pending, alert the team, and let a human check.

An AI agent will make the same kind of choice, and happily: it invents a reasonable-looking default. Reasonable-looking is exactly the problem, because nobody questions it in review. Writing the rule into the script first means the agent implements my decision instead of making its own.

For engineers: what a risk list in the script looks like

A trimmed example of the shape (not a real provider):

## Risks
- HIGH  status mapping: unknown status → pending + alert, never paid/failed
- HIGH  idempotency key: one key per payout, reused on every retry
- HIGH  polling: stop on a final status or after N attempts, then alert
- MED   amount format: provider sends minor units (×100)
- LOW   response field names: follow existing adapter conventions

## Goals
- webhook "SUCCESS" fixture → payment paid, exactly once on replay
- webhook with unknown status → payment pending, alert sent
- payout retried after timeout → provider sees the same idempotency key

Each goal is a test that runs against a fixture, or against the sandbox when there is one.

The agent that wrote the code shouldn't review it

Ask the same session to review its own work and it mostly agrees with itself. It remembers why it made each choice, so it reads the code through those reasons.

So review is a new agent with no memory of the build. It gets two things: the diff and the goals. It has to work out from scratch whether the code does what the goals say. In my experience this catches gaps well, because it reads the code the way a new teammate would.

Where the agent still goes wrong

Left alone, the agent tends to build more than you need, and "more" can quietly delete what you had.

The override that skipped the safety checks. The project already had a shared base class for provider adapters, and the method we needed was already there. The agent created a subclass anyway and overrode that method for no real reason. The override skipped checks the base class had collected from earlier incidents. Every new test passed, because the tests only covered the new provider. That's why my script now says "familiar parts follow conventions" and why the risk map lists every override.

Lists that jumped and drifted. In Tabby, my browser extension, I asked the agent to render only the rows on screen, so the dashboard stays fast with 5,000 saved links. It worked: the dashboard went from about 4 seconds to 0.14 seconds. But the generated code started at the wrong scroll position and counted one margin twice, so rows slowly drifted. The end-to-end tests caught both.

Both bugs passed the agent's own checks. Both were caught by something it didn't control: a review that knew the history, or a test written beforehand.

What it costs, and the rules I keep

The speed comes with an upfront bill: the script and goals take real time, and skipping them is how you lose money.

Money paths get human eyes: signature checks, amount conversion, idempotency and any database migration.
No secrets or customer data in prompts. Sandbox keys only.
Goals before code. If I can't say what correct means, the agent can't either.
Don't let the agent over-engineer. Reuse what exists; an unexplained override is a review flag.
Docs-based fixtures are a guess. Without a sandbox, the exported JSON is how I check the guess against the real API.

The alternative is writing it all by hand. That's the right call for a one-off integration with no repeated pattern, or when you can't review the result properly. It's the wrong call when a new provider arrives every few weeks and the same risks apply each time.

A note on the numbers: "about a week" and "1–2 days" are my own before-and-after for five integrations at work, from starting the ticket to merging the PR. They're not a controlled experiment, and the providers differed in complexity.

Takeaways

Write the goals and the risky rules (like "unknown status → pending + alert") before the agent writes code.
Build high-risk logic first; let familiar parts follow existing conventions.
Review with a fresh agent that sees only the diff and the goals, never the session that wrote the code.

If you integrate payment providers and do it differently, or think I've got a rule wrong, email me at tainh.work@gmail.com. I'll correct the post.

Originally published on taewoo.me.

I force-quit Chrome with 29 tabs open. Chrome restored 0. Tabby restored all 29.

taewoo — Fri, 16 Oct 2026 07:48:04 +0000

I had 29 tabs open. I force-quit Chrome instantly (a SIGKILL, the same as a real crash), with no chance to save anything. Chrome sometimes offers "Restore" after a crash. This time, when I reopened it, it restored nothing.

Tabby brought back all 29 tabs in one click.

That's because Tabby keeps its own copy of your open windows, on your device, and updates it as your tabs change. You don't have to remember to save anything.

Tabby is a free tab manager I made for Chrome and Firefox, and version 1.1 is out today. Getting here meant fixing three launch-week mistakes. The worst one: just having Gmail open quietly stopped Tabby's quick backups, because of a timer trap any app can fall into.

Free, no account. Coming from Toby? Your collections import in one click. Unlike OneTab, it saves without you clicking: Add to Chrome · Add to Firefox

Three things I got wrong in launch week

1. With Gmail open, the quick backup never ran

No tabs were lost. But for an app whose one promise is you won't lose anything, this one hurt.

Tabby takes a quick backup about 30 seconds after your tabs change. Gmail changes its tab title every time mail arrives: "(3) Inbox", then "(4) Inbox". Tabby counted each title change as "your tabs changed" and restarted the 30-second wait. With Gmail open, the wait never ended. Slack and other chat apps did the same. Only the slower 10-minute backup kept running.

The cause is a quiet Chrome detail: setting a timer with a name that's already taken replaces the old one, deadline and all.

// Before: every tab change replaced the pending timer and pushed it back.
await browser.alarms.create('snapshot-soon', { delayInMinutes: 0.5 });

// After: only start a timer if none is already waiting.

Title, favicon and audio changes also no longer count as "tabs changed". A test now opens a page whose title changes every second and checks that the quick backup still happens.

The lesson: a timer that restarts on every event never fires if the events never stop. That's a debounce with no maximum wait. A backup needs a deadline that new events can't push back: start the timer once, and let later changes join it.

2. I came back after a break and couldn't use my own app

1.0 explained its features but never showed how to use them. So 1.1 adds a one-minute hands-on tour in a practice browser, so your real tabs are never touched. It points at one thing to click at a time and tells you clearly when you've done it.

The lesson: explaining a feature isn't the same as showing someone where to click.

3. Google rejected the update over five words

My store description named five of the new color themes: Tokyo Night, Rosé Pine, Gruvbox, Aurora and Linen. Those names belong to other open-source projects, and Google flagged the line as "keyword stuffing". One plain line, "Eight color themes, light or dark", fixed it.

The lesson for extension authors: keep other projects' names out of your store text and screenshots.

What's new in 1.1, in 30 seconds

Bring it back. This is how the 29 tabs came back. Closed a window by mistake, or crashed? Closed windows are kept for 14 days. One click restores them.
Close tabs without fear. Save a tab to Later and a ✓ appears on it, so you know it's safe to close.
Sleep. Tabs you aren't using give their memory back but stay in your tab bar. Tabby reads your computer's free memory before and after, so the number it shows is measured, not estimated.
Close the copies. Same page open four times? One click closes the extras, with Undo.
⌘K (Ctrl+K) finds any saved or open tab as you type.

Try it

Coming from Toby? No account needed, and your collections import in one click. Using OneTab? Your list imports in one click too.

Free for good, not a trial: saved tabs, collections and spaces (unlimited), Bring it back, Sleep, ⌘K and closing copies. Pro is optional (details below).

What it can see: your open tabs' titles and addresses, so it can save and restore them. It can't read what's on your pages, and nothing leaves your computer: no account, no analytics.

👉 Add to Chrome · Add to Firefox

What's the most tabs you've ever lost at once, and what did you do about it? Tell me in the comments. (I have 34 open right now. Yes, I know.)

Pro details, so there are no surprises: $4/month or $29/year. Five more themes, switching windows between more than 5 spaces, and Tidy up straight into collections. New users get a 14-day Pro trial, no card needed.

I built Tabby, a privacy-first Chrome extension to tame tab chaos

taewoo — Thu, 08 Oct 2026 12:30:34 +0000

Disclosure: this is a promotional post. Tabby is my own extension. It's free, with an optional Pro tier coming later.

The problem

You know the feeling: 60+ tabs open, half from a bug you fixed last week, half from a project you'll "get back to". You don't close them because closing feels like losing them.

I wanted a tool that makes closing tabs feel safe. So I built Tabby.

What it does

🗂 Spaces: switch projects, not windows

Each space keeps its own open tabs. Switch spaces and your window swaps to that project's tabs, while the old ones are saved automatically. Pinned tabs (mail, chat) stay in every space, and tabs reopen unloaded, so even a 100-tab project switches instantly.

⌨️ Tidy up in a minute

Go through your open tabs one at a time, oldest first:

Key	Action
`K`	Keep
`X`	Close
`S`	Save to Inbox
`Z`	Undo

Duplicates and links you've already saved are flagged while you decide.

🔍 ⌘K / Ctrl+K search

One search box for saved links, collections and open tabs. It stays fast with thousands of links.

✂️ Smart titles

fix: retry webhooks · Pull Request #4821 · GitHub becomes fix: retry webhooks · #4821. Small thing, but your saved lists become readable.

🛟 Never lose a tab

Automatic session backups, undo on every delete, a restorable Trash, and export to JSON or bookmarks anytime.

Privacy by design

No account. No tracking. No ads. Your tabs and links are stored only on your device and never sent anywhere.

Coming from Toby or OneTab?

Tabby imports Toby JSON exports, OneTab lists and browser bookmarks from Settings.

How it's built

Try it

👉 Tabby on the Chrome Web Store

It's v1.0, my first published extension, so feedback, bug reports and feature ideas are very welcome in the comments.

Design patterns aren't a catalog — they're a way to predict where change will hurt

taewoo — Thu, 10 Sep 2026 16:51:56 +0000

Most design pattern content stops at "here's what a Factory is." That's fine for a quiz, but it doesn't help you when you're staring at a real codebase deciding how to structure the fifth integration you've onboarded this year.

I spent a recent afternoon deliberately drilling on pattern recognition — not memorizing names, but learning to ask the right question before writing code. This post is the distilled version, applied to a problem a lot of backend engineers eventually hit: onboarding a new external partner whose rules, data formats, and failure modes don't quite match the ones you already built for.

The specific partners here are placeholders. The shape of the problem is real, and you don't need a finance background to follow it — swap "PSP" for "payment provider," "shipping carrier," or "auth provider" and the same reasoning applies.

The setup

Imagine you're integrating with three outside partners — call them Partner A, Partner B, and Partner C. Each one has its own quirks:

Each requires some kind of upfront check before you're allowed to proceed — but the pass/fail rules differ.
Each wants identity or ID data in a different format.
Each exposes a completely different API — different endpoint names, different field names, and a different way of signing requests.
Each needs different things to happen afterward: a log entry, a notification to your ops team, a cache update. None of that is exotic — it's the everyday reality of "we support multiple vendors now." The naive approach is one big service class with a long case statement branching on partner name. It works fine at first. It stops working the moment you onboard Partner D and discover that adding one new check means touching a 150-line method that three other partners also depend on.

The questions that actually matter

Before reaching for a pattern name, here's the mental shift that made the real difference for me: a pattern isn't defined by how many steps there are, or whether there's a conditional. It's defined by what changes independently, and who owns the interface.

Three questions I now ask myself before writing the code:

Can this step stop the next one from running? If yes, you're looking at a chain, not just a sequence.
Did I design this interface myself, or am I adapting to one that already exists? If the shape came from someone else's API, you're translating (Adapter). If you invented the interface so several implementations can be swapped in, you're choosing behavior (Strategy).
When this step finishes, do several independent things react without needing to agree with each other — or is exactly one thing supposed to happen? Independent, uncoordinated reactions is Observer. Picking exactly one behavior out of several is Strategy — even if, confusingly, the code that does the picking looks a lot like a Factory. That third question is the one I got wrong the most, so it's worth sitting with for a second. A conditional that picks between objects doesn't tell you the pattern. What the object does next does.

With that in mind, here's how the four steps of the flow actually map out.

Mapping the flow, step by step

Steps 1 & 2 — the upfront checks → Chain of Responsibility

Both checks can halt everything downstream. The first check fails → stop, skip the second check, never call the partner's API. The second check fails → stop, never call the API. That veto power over the rest of the flow is the defining trait of Chain of Responsibility: each step is independent, and any one of them can end the whole thing.

class FirstCheck
  def call(context)
    return context.fail!(:first_check) unless passes?(context)
    context
  end
end

class SecondCheck
  def call(context)
    return context.fail!(:second_check) unless passes?(context)
    context
  end
end

CHAIN = [FirstCheck.new, SecondCheck.new]
CHAIN.each { |check| context = check.call(context); break if context.failed? }

It's easy to confuse this with Template Method, which also runs a fixed sequence of steps. The difference is authority: Template Method is one class where a subclass fills in the steps, but no individual step gets to cancel the whole flow. If your steps can independently veto everything after them, that's the tell for Chain of Responsibility.

Step 3 — calling the partner's API → Adapter, with Strategy hiding inside it

Each partner's API is a shape they defined, not you. Different field names, different endpoints — that's the textbook case for Adapter: translate a shape you don't control into the one your own application wants to depend on.

class PartnerAAdapter
  def create_account(params)
    # translate params to Partner A's field names, call their endpoint
  end
end

But how you sign the request — one scheme vs. another — is a separate decision, sitting one layer inside the adapter. You designed that interface yourself, and more than one implementation can be swapped in at runtime. That's Strategy, even though it physically lives inside an Adapter.

class HmacSigner
  def sign(payload); end
end

class PartnerAAdapter
  def initialize(signer: HmacSigner.new)
    @signer = signer
  end
end

The lesson here: a single step in a flow can need two patterns stacked on top of each other. Don't force one pattern to cover a whole step just because it's "step 3" — ask the diagnostic question separately for the outer shape (talking to the partner) and the inner behavior (how you sign).

Step 4 — what happens afterward → Observer

Logging, notifying ops, updating a cache — three independent reactions to "the account was created," and none of them need to know the others exist, and none of them are chosen over the others.

class AccountCreatedBroadcaster
  LISTENERS = [AuditLogger.new, OpsNotifier.new, CacheUpdater.new]

  def self.broadcast(event)
    LISTENERS.each { |listener| listener.call(event) }
  end
end

This is the one most often confused with Strategy, and the confusion isn't really about "how many branches run" — it's about coordination. Strategy picks one behavior for a task. Observer runs all reactions to an event, with zero coordination between them. Counting branches is a symptom, not the cause.

What this actually cost me to learn

I want to be honest about the parts I got wrong, because the mistakes taught me more than the correct answers did.

I reached for Builder any time I saw "multiple steps" — even when the steps were really a validation chain that could halt midway, nothing like a builder object with .set_x methods. I reached for Factory any time I saw a conditional picking an object, even when the object being picked was really doing Strategy's job and the conditional was incidental. I reached for Adapter for two interfaces I'd designed myself from scratch, when there was nothing to translate — that was Strategy the whole time.

The fix wasn't memorizing more examples. It was swapping "what does this look like" for "what changes independently, and who owns the interface." That question works on code I haven't seen yet, which is really the whole point of learning a pattern in the first place.

Where this goes next

This is the first post in a series working through everyday infrastructure problems as they actually show up in backend systems — idempotency, race conditions, deadlocks, and reconciliation are next. Same approach every time: not "here's the definition," but "here's the messy case where the textbook answer didn't quite fit, and what I had to work out instead."

If your codebase is turning into a wall of case statements every time you onboard something new, a pattern name isn't the fix by itself. The three questions above are what actually help you find the seam before you write the code.

Originally published at taewoo.me.

Starting here

taewoo — Tue, 25 Aug 2026 03:25:31 +0000

I work on backend systems, mostly payment infrastructure — integrating with payment
partners, handling things like a single HMAC signature or one reconciliation line
that looks small but isn't. Get it wrong and it's not a typo, it's real money gone.

A lot of that work happens alongside AI now. It writes code faster than I do. But it
doesn't know how a specific PSP actually behaves in production until it breaks —
usually at the worst time, while the next feature is already due. That part is
still mine.

This isn't a place where I play industry expert — I'm not, and that's not the point.
It's where I write down what's actually true: what I understand, what I don't, and
the parts I still check by hand no matter how confident the AI sounds.

If you're working at that same edge — using AI to move faster while still being the
one who answers for it when it breaks — some of this might be useful. No big
promises. Just writing it down, regularly, and seeing where it goes.