我把一人數碼產品生意畫在一頁上:背後的系統
I Mapped My Entire One-Person Business on One Page — Here's the System
作者把一人數碼產品生意的架構與訂單流程整理成一頁互動地圖,呈現讀者如何成為買家,以及各環節如何運作和可能出問題。地圖揭示單一 Outlook 收件箱、手動核對 NOWPayments 付款及靜態目錄約 15 件產品的限制;地圖由 AI 起草,再由作者逐項對照實際系統核實。
I Mapped My Entire One-Person Business on One Page — Here's the System
I run a small digital-products store by myself. No servers, no staff, no investors — just me, a stack of free tiers, and a set of automations I set up months ago and have been trusting ever since.
Here's the thing I couldn't honestly answer until recently: if you asked me to show you how the whole business fits together — how a stranger on the internet becomes a person holding one of my files — I would have had to wave my hands. The pieces live on five different platforms. dev.to brings in readers. A static page on Cloudflare Pages is the storefront. NOWPayments collects the money through one hosted link per product. An Outlook inbox handles receipts and support. The products themselves are PDFs and ZIPs sitting in local folders.
I knew every piece. I had just never seen the whole thing at once. Neither had anyone else — which is a polite way of saying the system's documentation was "it's all in my head," and my head had never actually assembled it in one place.
One page, two views
So I mapped it. The result is a single page with two views of the same business.
The architecture view is four horizontal lanes. Acquisition: dev.to articles in three languages and a free sample pack that trades 20 of my 100 phrase chunks for an email address. Storefront: the one-page catalogue — eight products and three services — plus three landing pages, one per Thai consulate, for my visa guide. Payments: the NOWPayments links and the custody wallet they settle into. Fulfilment & support: one inbox, one operator (me, AI-assisted), and delivery by email within 24 hours.
Every box on the map is clickable. Clicking it tells you what the component does, what it runs on, and — this turned out to be the important part — where it can break.
The flow view walks a single order through six steps: Discover, Evaluate, Pay, Prove, Verify & deliver, Support & upsell. The full clickable version lives on my site (tobywater.pages.dev); it's the actual sample I now show potential clients, drawn from the real store, so every box can be checked against the live thing.
I expected the map to be a tidy summary of what I already knew. Instead, three boxes started staring back at me.
Problem 1: One inbox is my entire fulfilment department
Every order receipt, every sample request, every support question lands in a single Outlook alias: toby.water@outlook.com. There is no queue system, no second mailbox, no fallback. If that account ever locks me out, orders don't bounce — they silently stall, and buyers experience it as a store that took their money and vanished.
I won't pretend I solved this. What I did was stop letting it be invisible. The weakness is now written on the map, in the box, where I have to look at it. Around it I've put the two mitigations that honestly exist: the public alias is separate from my login identity, so the address I print everywhere isn't the credential that matters, and an automated watch polls the unread mail every five minutes so nothing sits unseen for hours. Real redundancy is still on the to-do list. The difference the map made is that it's a known item on a list, instead of a surprise waiting for a bad day.
Problem 2: There's no webhook — reconciliation is me
NOWPayments settles a payment, and then… nothing pings my side of the fence. There is no webhook, no order database, no automatic "payment received, ship it" trigger. The join key between a payment and a person is an email: the buyer forwards their receipt to my inbox, and I match it against the payment record by hand before sending the files.
Drawn as a diagram, that's a dashed arrow labelled "buyer emails receipt" doing the job an API should do. It looks primitive because it is. At my current volume it's also deliberate — manual matching costs minutes a week, and the receipt email opens a human support thread from minute one, which a faceless download portal wouldn't. But I handle it with rules, not vibes: buyer email is required at checkout precisely so the match is possible, and if a receipt doesn't match a payment, I ask for the transaction ID instead of guessing.
The map's real contribution here: when order volume grows, I now know exactly which arrow gets automated first, instead of vaguely feeling that "fulfilment should probably be automated someday."
Problem 3: The catalogue has a ceiling, and I can count it
The entire store is one static HTML page, deployed as a single zip upload. At eight products and three services, that's a feature — the whole business is one artefact I can redeploy in a minute. The map forced me to write down what I'd been avoiding quantifying: this does not survive past roughly fifteen products. Beyond that, a hand-edited page becomes the bottleneck and the store needs a generator.
So I did the counterintuitive thing and shrank the catalogue. A cross-audience bundle I'd been carrying — products for English learners bundled with products for sellers — underperformed and added exactly the kind of page bulk that brings the ceiling closer. It's gone; the catalogue now sells per-audience only. The generator is deferred, but deferred knowingly, with a number attached.
A note on method, because it matters
The map was drafted by AI from my system notes, then checked by me — every box, every arrow — against the real setup, line by line. That second step is not optional garnish. Language models produce plausible diagrams: confidently drawn boxes for components that don't exist, arrows pointing in the direction that reads well rather than the direction data actually flows, a database materialising because diagrams are supposed to have one. For your own system you can catch every one of those — but only by reading, not by generating. A map nobody verified is decoration. A map somebody verified is an audit you can see.
Steal the exercise
If you run a small product and couldn't draw its whole system on one page from memory, that gap is worth an afternoon. Mine turned a vague sense of "it's fine, mostly" into three specific, written-down weaknesses — one mitigated, one deliberately manual with rules, one deferred with a number on it.
If you'd rather not do the drawing yourself, this is a service I sell as Codebase Maps (tobywater.pages.dev): your codebase or system, AI-drafted and human-checked line by line, delivered as one self-contained clickable HTML file, in three tiers from $39 to $279 depending on depth. Questions welcome by email — it goes to the famous single inbox, which is polled every five minutes.
Disclosure: this post, like the map it describes, was produced with AI assistance and reviewed by me line by line — which is rather the point of the article.
來源:DEV Community · dev.to