Taewon Kwon

The problem

The owner had tried Toast Payroll and dropped it. Her CPA already handled tax filing, so the tool added cost without value, and it couldn't bend to her rules for tips, overtime and other pay axes. Underneath that was trust: she didn't want her staff's wage data sitting with another vendor.

What I built

• A web app layered on her existing Google Sheets: a dashboard, a payroll run that takes her POS export as a CSV, a publish step, and an employee roster.
• Gross pay per employee lands in her Sheet, which she sends to her CPA. The Sheet lives in her own Google account, so no payroll vendor holds her data.
• Features that came from watching real pay runs: salaried staff (fixed gross, hours still tracked, shifts over 10 hours flagged), undo last publish, safe re-runs, and detection of unknown names in raw POS exports.

Key decisions

1. Stopped the math at gross pay. Each employee's withholding arrangement was too specific to automate reliably, so net pay, cash bonuses and tips stay with the owner.
2. Said no to a per-employee tax-rate field. It would have looked automated while hiding judgment calls.
3. Investigated a mismatch instead of patching it. Past periods didn't match her old summary sheet. Tracing the raw CSVs showed the app was right and the gaps were her deliberate adjustments, like zeroing tips for trainees. Those stayed her call rather than hard-coded rules.

Could it be a product?

• Narrowed positioning after finding a competitor already offered generic CSV import: the wedge became customization around each restaurant's own exports and house rules.
• Designed an architecture where all payroll math runs in the browser and writes to the restaurant's own Sheet, so the server never holds wage data.
• Cut pricing from three tiers to one flat implementation fee, and set a decision rule before starting: continue only with 2–3 signed clients from a one-month NYC sprint.
• Ran discovery with the original client and cold-called restaurants sourced from a community job board. The first 15 dials produced one interested lead, and the discovery meeting removed the CPA-side value I had assumed.

Outcome

The tool runs the client's weekly payroll. I paused productization in September 2026, before committing a month to the sprint, because the evidence didn't show enough value to justify it.

The problem

A long-established distributor of zippers and apparel materials, running on decades-old relationships with older client companies. The goal was to win younger buyers through search and maps instead of relying on those relationships alone, and to get inventory out of paper.

What I delivered

• Website and discoverability: a new site, email migration, Google SEO and Naver Place registration, live since mid-September.
• Inventory system: the company's first digital one. A Korean-language kiosk app on an Android tablet on the warehouse floor, a web dashboard for the office, and a Supabase backend.
• Sample book: two binders that show physical zipper samples by product line.
• Business cards as part of the rebrand.

Key decisions

1. A four-button kiosk for warehouse staff, backed by an append-only transaction ledger, so every stock movement is recorded and auditable without asking staff to learn software.
2. A controlled cutover. Froze orders for a Friday afternoon and a full Saturday to sweep the data, then required the system to run live for at least a week before I left, so errors surfaced while I could still fix them.
3. Basics before content. Launched the site with maps and base SEO only and deferred a blog pipeline. Scrapped a printed catalogue and kept the physical rebrand to cards and the sample book.
4. Designed the sample book in-house to protect the budget. Manufacturing took most of it, so I designed every page and the binder; the manufacturer recreated from my files. I showed five directions, the client team picked on taste, the manufacturer checked feasibility, and the final version combined the strongest parts of all five.

Outcome

All four deliverables were handed over by October 2026, with the inventory system cut over from paper in September.

The problem

I worked a Korean apparel brand's booth at Coterie, a wholesale fashion trade show in NYC, and heard the owner's frustrations during and after it. Staff log buyer interest on paper: name, company, what was discussed, items and quantities. After the show, turning those notes into orders is manual follow-up with no visibility into who has looked or responded. That brand became my design partner.

The reframe

1. The first version was a broad B2B platform for Korean brands selling abroad, with catalogues, deal links, order confirmations, invoices and payments.
2. I stripped the money out and narrowed it to digital line sheets that work at the show and after it. Invoicing went behind a feature flag rather than being deleted.
3. I reframed "show mode" from a buyer-facing catalogue into an internal lead-capture tool. The products are already on the booth's racks, so buyers don't need a catalogue; the team needs a faster way to record interest.
4. That reframe showed most of the post-show flow already existed. The new build was small: notes on buyer records, a capture form that saves drafts locally so a flaky show-floor connection loses nothing, and a "submitted" status on deal links.

What I built

• Show-mode lead capture on a laptop, where each record becomes a reusable buyer.
• Post-show deal links for a captured buyer or a new one.
• Deal-link tracking on the dashboard: created, opened, submitted.
• An order confirmation generator that turns a submission into a formatted document.

Next.js on Vercel · Supabase (Postgres, auth, row-level security, signed-URL storage) · Drizzle migrations

Outcome

I demoed a working version loaded with the partner's real catalogue in September 2026, a week before their next show. The owner agreed it was a good tool and that live use at shows would need more features. I put it on hiatus rather than build them: the gap is real, but running it properly needs full-time attention I can't give it right now.

The problem

Built for the Korean market. Star averages are noisy and know nothing about your taste, while the recommendations people actually trust are buried in group chats. Gomi made the unit of content a place someone you trust vouched for, and built discovery on that social graph, on a map.

What I built

• A Flutter app for iOS with Kakao Maps: map-first discovery plus social food logging.
• A data model of users, places deduplicated against the map provider, vouches with photos and notes, saved collections and follows.
• Shipped as a closed TestFlight beta to 15 testers in summer 2026.

Hardest problems

• Double cold start. It's a social product and a content product at once, so a new user with no follows and no nearby posts sees an empty app.
• Place canonicalization. The same restaurant entered several ways splits its vouches and breaks the feed.

How I built it

• A canonical doc set: one project-state file as the single source of truth, a deferred-issues log where every parked item has an explicit revisit trigger, and design tokens for consistency without a designer.
• Reusable session templates: a starter that forces a read-back of current state before any work, and a closeout that writes targeted updates back into those docs.
• AI-assisted coding with diff review on every change, and AI for architecture and planning.