Case studies · Tutorial 05
A Practical AI Stack for a Small Online Business
Find one painful customer problem and deliver the offer manually. Add a landing page, payments, email, analytics, and automation as the work repeats.
0 of 12 complete
Last tested and updated: August 2026
A one-person online business starts before the software stack. You need a specific customer, a painful job, and an offer that produces a result. Deliver it manually once. Then add the landing page, payment, email, analytics, and automation needed to repeat it.
This lesson shows where AI helps and where it does not. See Hermes L02, L01, and L04 for the supporting tools and project path.
Deliver before you automate
Imagine you want to sell a weekly research brief to small teams in one industry. Do not begin with a subscription site and seven automations. Find one person who needs the decision, agree on the question and evidence standard, and deliver the brief manually.
That first delivery teaches you what the buyer values, which sources matter, what takes time, and which mistakes would make the work unusable. A repeated step can become a script. A judgment call stays with the operator. A feature nobody needed gets cut before it costs a month of work.
Name one routine step you perform more than once a week. Before automating it, write down the input, output, failure cases, and review rule. Some steps should remain manual.
The customer plus five operating layers
A small online business has a foundation and five operating layers. Each has a different automation profile.
Layer 0: Customer, problem, and offer. Name who has the problem, the result they need, what you will deliver, the price or commitment you want to test, and why they should trust the result. Automation potential is low because this layer comes from conversations and delivery evidence.
Layer 1: Landing. The page that captures an email. Static site, Carrd, or one Next.js route. Cost $0 to $10/mo. Automation potential: low: write the copy once, hook the form to your list.
Layer 2: Product. What you deliver. The directory, the newsletter, the app. Automation potential: medium: Claude Code shines here. The work lives in a repo and needs test verification (see L01).
Layer 3: Email. The list, welcome sequence, weekly digest. The highest-leverage layer. Every other layer funnels back into it. Automation potential: very high: a welcome is a trigger; a digest is a cron.
Layer 4: Monetization. Payment links, subscriptions, or paid placements. Automation potential: medium. Webhooks can send receipts or update access, but refunds, disputes, tax, fraud, and exceptions need an owner.
Layer 5: Analytics. A small dashboard or scheduled report should answer the decision you need to make. Automate alerts only after you know which change deserves attention and how false alarms will be handled.
Measure the work before automating it
For two weeks, log each delivery step, minutes spent, tool cost, corrections, and whether the customer accepted the result. Automate only a repeated step with a clear success check. Keep discovery, sensitive decisions, customer conversations, exceptions, and final approval visible to a person.
Build the stack in customer order
Here’s the stack I’d actually build this week, in order.
Week 1: Customer and manual offer. Interview three people. Agree to deliver one small result for one of them. Use a document, email, or shared folder before building a product.
Week 2: Record delivery and demand evidence. Note the inputs, output, buyer feedback, delivery cost, corrections, and whether the buyer wants the result again. Ask for a small real commitment before expanding scope.
Week 3: Build the narrow repeatable path. Use Claude Code for a tested product step and Hermes only for a bounded automation with a log and approval point.
Week 4: Add the minimum operating stack. Create a truthful landing page, payment route, receipt, welcome email, support contact, refund process, privacy disclosure, and a small dashboard for the metric that decides whether to continue.
What you should NOT build first
Common distractions include a support chatbot before support volume exists, a custom CRM before the first repeat buyer, or an elaborate dashboard with no decision attached. Start with the repeated step that blocks delivery or creates a costly mistake.
| Layer | First version | Evidence before automating more |
|---|---|---|
| Landing | One page with a specific offer and contact route | Relevant visitors understand the result |
| Product | Manual delivery or a narrow tested workflow | The same steps repeat across accepted deliveries |
| Receipt, expectation, and one useful follow-up | Customers open, reply, or complete the intended action | |
| Payment | One supported payment route and refund process | A real buyer completes the transaction |
| Analytics | A delivery-cost and customer-response log | The metric changes a decision |
| Orchestration | One bounded job with a log and approval | It saves reviewed time without increasing failures |
Run a 30-day offer test
The exercise
Run a 30-day offer test:
- Interview three potential customers about the last time they faced the problem.
- Write one fixed-scope offer with a deliverable, deadline, review standard, price or commitment, and exclusions.
- Deliver it manually to one person.
- Record direct costs, time, revisions, support, and whether the result was accepted.
- Ask whether they would buy it again or refer someone with the same problem.
- Automate one repeated step only after the second delivery shows the same pattern.
At the end, calculate gross revenue, direct cost, delivery time, and the cost of corrections. A working stack without a repeat buyer is still a useful learning project, not yet a business.
What’s next
You’ve completed the AI Projects module. To go deeper:
- L01: Coding with Claude Code
- L02: Vibe Coding vs Real Coding
- L04: Niche Directory Sites
- Hermes L08: Automation: cron, kanban, sub-agents
- Hermes L01: What Is Hermes Agent?