KOJA Paper Box + KDB

01·The problem

The business lived in six places at once

KOJA Paper Box sells Korean and Japanese stationery to people in the US, Canada and the UK. There are three of us. Silas runs fulfillment and customer support, and I design and build the tools we run on.

When orders took off, the business lived in six places at once. Shopify had the orders. A Google Sheet had the money. A Korean supplier's website had the stock. Customer email sat in a shared inbox. Tasks lived in Discord. Nobody could answer "are we making money?" or "did anyone reply to her?" without opening all six.

02·The solution

KDB: one dashboard for the whole business

KDB, the KOJA Dashboard, is where the business actually runs. I designed the first version and shipped it the same week.

• Money at a glance. Revenue and profit by two-week sprint, expenses, and the partner payout split.
• Orders and fulfillment. Every Shopify order, synced hourly, with a globe of where they go.
• A catalogue that talks to suppliers. Paste a Korean supplier's page and AI drafts the listing. Stock is watched daily.
• Support as a board. Every customer email becomes a case with a reply timer.
• The team's home. Tasks, a calendar, a blog planner and a wiki.

03·Research and process

My teammates were my research

There was no research phase, because research never stopped. Silas and SonWoo use KDB all day, so every tab came from a real moment: a teammate hits a wall in Discord, I turn it into a spec, and the fix usually ships the same day. I ran working sessions with the team, watched where each person actually worked (Silas lives in Shopify), and tuned every rule against real orders instead of guesses.

I work spec first. Every change starts as a short written intent: the problem, what done looks like, what is out of scope. Then I build it with Claude Code, review the diff and the live result, and ship. Every release gets a version and a plain-language changelog, and nothing goes to production without my review.

That loop is why shipping almost every day felt calm instead of chaotic. It also meant I could explore several solutions in parallel and throw away the weak ones cheaply. The Sales mix chart went from request to live in one morning. Grouping by brand, by type and by product were all on the table. I picked by type, then tuned the rules against every real order until nothing important landed in Other.

04·Design

Designing AI features people can trust

Most of KDB's hardest design problems were about AI and automation doing real work on a live store. My rule was simple: the machine can do the tedious part, but a person always sees what it did and owns anything a customer will see.

• Pull a shop page. Paste a Korean supplier's page and every product lands with its photos, translated names, options and a KOJA SKU. Many of those listings are images only, so Claude reads the description images and writes the specs. Nothing goes to the store until someone reviews it and presses push, and it always lands as a draft.
• Voice as a prompt. I wrote the KOJA voice as a reusable prompt layer: who we sound like, the words we never use, before and after examples, and a checklist for catching machine-sounding writing. Product copy, support replies and blog posts all draw on the same file, so a voice change lands everywhere at once.
• Drafts, never sends. The AI drafts support replies and blog posts. A human sends the email and publishes the post. That is a product rule, not a setting.
• Dry run first. Anything that changes a live listing, like adding a size to a product, runs as a preview that lists exactly what will change. The real run only happens after a yes.
• Warn before overwriting people. Silas edits listings directly in Shopify. When a push would have replaced her photos, we changed the product: pulling now mirrors Shopify one to one, keeps anything local greyed out instead of deleting it, and never stores a photo twice.

Automation you can see

Our supplier kept selling out. One popular planner sold out overnight and we had already oversold it. So I designed a stock watch: tick a product and KDB reads the supplier's stock once a day and the moment someone buys it, then sets our Shopify stock by a rule the team agreed on. Sold out there means zero here. One or two left means we list one. Otherwise we cap at six.

The design work was in making the agent legible. Every variant shows what the supplier has left next to what we list, and when it last looked. A variant it can't confidently match says "not matched" and is left alone rather than guessed. A sell-out pings its own Discord channel. And a person can always override it: untick the watch and the stock is yours again.

Workflow tools for a small team

Support was the part that hurt most. Mail came in faster than we could track it. The support board turns every customer email into a case, threads replies onto it, and gives each case a 12-hour timer that pauses while we wait on the customer. Moving a case to Solved now asks how it was solved, so the next person to open it knows what happened. Newsletters and review alerts stay out: only real customer folders become cases.

One system, not a pile of screens

With a new feature most days, consistency had to be designed in rather than policed. KDB has one set of patterns and reuses them: tables that fit their box with columns you can drag to resize, a save lock with a progress bar so nobody double-submits, one card style for tasks and cases, light and dark themes from the same tokens, and deep links so a shared URL opens the exact product.

The documentation is part of the system too. Three living docs sit next to the code: what it is for, how it is built, and an API reference. A test fails when the API and its reference drift apart, so the doc the AI reads is always true.

05·Testing and iterations

Real use kept changing the design

Shipping almost every day meant the team tested every change on the live store. These are the ones that changed the product the most.

1. 01

   Pushing a product erased a teammate's photos

   What we saw

   Silas edits listings directly in Shopify. A push from KDB replaced her photos with older ones, because I had designed for people inside the tool.

   What changed

   Pulling now mirrors Shopify one to one, keeps anything local greyed out instead of deleting it, and warns before any push overwrites someone's work.

2. 02

   We oversold a planner overnight

   What we saw

   A popular planner sold out at the supplier while we kept selling it.

   What changed

   The stock watch: it checks the supplier daily and on every sale, sets our stock by a rule the team agreed on, shows its work on every variant, and skips anything it can't match.

3. 03

   Small orders looked profitable and weren't

   What we saw

   A small item at a 50% margin looked great, but took 15 minutes to pack. We were paying ourselves about $12 an hour.

   What changed

   Every product now carries its packing time, priced at an hourly rate, so the margins on screen are the real ones. It changed what we stock.

4. 04

   Solved cases lost their story

   What we saw

   A case moved to Solved and the next person had no idea what had happened.

   What changed

   Moving a case to Solved now asks how it was solved.

5. 05

   The spreadsheet became the bottleneck

   What we saw

   The Google Sheet was the right first database, because the team already lived there. By September it couldn't keep up.

   What changed

   In one day I moved every dataset to Postgres and kept the sheet as a read-only mirror. Nobody had to change how they worked.

06·Building it

From a spreadsheet to a real product

KDB started on June 22 as a single web page on top of our Google Sheet: orders, expenses, and the profit split between partners. Three months later it is a real product with a database, accounts, and seven integrations.

The shape today:

• One page, one API. The whole interface is a single page that loads fast and works on a phone. Behind it sit a dozen serverless functions on Vercel, grouped by job: data, products, support, blog, wiki, sync. The hosting plan once capped us at 12 functions, so related actions share an endpoint instead of each getting their own.
• Postgres as the source of truth. Neon Postgres holds every row: orders, expenses, payouts, tasks, support cases, products, variants and settings. Photos live in Vercel Blob, with Google Drive as the long-term archive. The schema creates itself on first run, so a fresh copy of the site sets itself up.
• Real accounts. Personal logins with admin and member roles, plus a separate robot login that can use the API but can never administer it.

The integrations

Most of KDB's value is in what it connects. Each integration exists because someone was copying something by hand.

• Shopify. Orders sync every hour and on demand. Products go both ways: pushed as drafts, pulled back one to one, photos included. Stock is written straight to the store, and a Shopify webhook tells us the moment an order lands.
• Korean suppliers. The pull tool reads supplier pages, prices them with our markup and today's exchange rate, and the stock watch checks them daily.
• Claude. Translation, reading image-only product descriptions, and drafting copy in the KOJA voice.
• Zoho Mail. Customer email becomes support cases every ten minutes, and replies thread onto the right case.
• Discord. New cases, customer replies, timers about to run out and supplier sell-outs each ping the right person or channel.
• Meta. One button pulls the day's ad spend so the profit numbers are real.
• Google. The old sheet stays as a readable mirror and Drive keeps every product photo.

07·Results

A three-person team running a $20k+ a month store

KDB holds up the whole business: 596 orders through the dashboard, shipped to six countries, with three people doing the work of a fulfillment, support and ops team. Support has a timer on every case, stock follows the supplier on its own, and the profit numbers include our own time.

08·What's next

Where agents come in next

KDB was designed so an agent could use it the way a teammate does, and one already does. Claude works the live dashboard over the same API the page uses: it files tasks, checks supplier stock, writes blog drafts and plans product changes. It does that as the robot login, with no admin rights, reading an API reference that a test keeps honest.

The guardrails I designed for people turned out to be exactly what agents need:

• Dry run, then confirm. Anything that changes the store shows its plan first.
• Draft, never send. An agent can write to a customer. Only a person sends it.
• Say what gets overwritten. Before touching work a teammate did by hand, list what would be replaced or lost, and wait.
• Leave it alone when unsure. An unmatched variant is skipped, not guessed.

The next agents are the ones the team keeps asking for in Discord. A support agent that drafts a reply into each new case with the order already looked up, for a person to edit and send. A restock agent that watches sell-outs and sales speed and proposes what to reorder. A listing agent that turns a supplier link into a finished, reviewed Shopify listing. And a Monday brief that reads the whole business and says what changed. The hard part of each is not the model. It is designing where the human steps in, and making every step the agent took easy to see and undo.

09·Final thoughts

What I learned

• Guardrails for people are guardrails for agents. Dry runs, drafts that a person sends, and warnings before overwriting someone's work were designed for a team of three. They turned out to be exactly what an AI agent needs to work safely on a live store.
• The user isn't always inside your tool. The photo overwrite taught me to start every change with "who else edits this, and where?"
• A cost model is a design decision. One missing line, our own time, changed what we sell.

What I would do differently

• Put our own time into the cost of every order from day one. It put real stress on the team before we caught it.
• Name the rules out loud earlier. Product categories started as keyword rules I tuned against real orders. It works, but a category field on each product would have been clearer to the team from day one.
• Measure support, not just sales. We track revenue to the cent. We should have tracked time to first reply from the start.

Role and collaborators

I'm one of KOJA's three partners. I designed KDB end to end: working sessions with the team, flows, interaction design, visual design, the AI behaviours and their guardrails, and the product decisions. I directed the build with Claude Code as my engineering partner and shipped to production myself. Silas and SonWoo were my users, testers and harshest critics, which is exactly what a tool like this needs.

Stack: Vercel serverless functions, Neon Postgres, Vercel Blob, the Shopify Admin API and webhooks, the Claude API, Zoho Mail, the Meta Marketing API, Google Sheets and Drive, and Discord.