AI-assisted coding changes the economics

Software For 10 People

Before LLMs, the minimum useful audience for custom software was maybe 1,000 people. Now it might be 10.

Software For 10 People1
The scale ladder

LLMs are strongest where the software is small, local, and specific.

Personal Notes, Excel, SaaS B2C services.
10 people Friend group, hobby, meetup. LLM sweet spot.
Niche business Works, until code complexity starts compounding.
Enterprise Cross-team coordination, legacy systems, 100M+ lines.
From spreadsheet to enterprise2
Minimum useful audience

The audience needed to justify custom software is collapsing.

Before

Startup software needed a market. SaaS needed many customers. Internal tools needed enough employees to justify the build.

Now

A friend group, household, meetup, or single recurring workflow can be enough reason to build.

10,000 users 1,000 users 100 users 10 users 1 user
The threshold is moving down3
The new build decision

Before: not worth it. Now: maybe build it this weekend.

The real gain is not “30% faster functions.” It is that tiny friction becomes worth solving.

Before AI

Setup, UI, backend, database, deployment, and maintenance often cost more than the problem.

With AI

A rough but useful version can be built fast enough that small tools become rational.

Cost changes what exists3
The claim

Vibe coding scales down better than it scales up.

Downscaling works

Small apps have nearby users, reversible mistakes, simple data, and one person who can still understand the whole system.

Upscaling hurts

Large systems turn generated code into coordination debt, vocabulary drift, hidden coupling, and unreadable issue queues.

The core argument4
Three kinds of vibe coding

The same technique has different risk at different scale.

T
Toy vibing

Fun demos, throwaway prototypes, and experiments where the point is learning or taste.

10
Tiny-tool vibing

Useful, low-risk software for a small group with fast feedback and manual recovery.

E
Enterprise vibing

Dangerous unless the agent is constrained by architecture, domain language, and review.

Scale changes the risk5
Google Sheets is the first casualty

LLMs are not only replacing code. They are replacing tiny shared spreadsheets.

For a few friends, a mini CRUD app can now be easier than maintaining a fragile sheet.

  • Host it on a cheap static platform.
  • Add just enough database or JSON storage.
  • Give your group one clean URL.
  • Keep the workflow shaped exactly like your people.
From spreadsheet to mini app4
Spreadsheet-to-app pipeline

A sheet starts as coordination, then slowly admits it wants to be software.

Person
Status
Next
Mina
yes
bring snacks
Alex
maybe
ask topic
Jin
yes
send link
Rules
formula?
broken filter
Permissions
who edited?
stale row
Meetup RSVP status, owner, note, reminder
Topic queue votes, speaker, links, recap
Clean URL one workflow instead of five sheet conventions
When a sheet becomes an app5
Household, hobby, friend group

Current LLMs are extremely good at basic software for real people you know.

low traffic low risk clear users simple data fast feedback easy to throw away
The useful middle4
Why 10 people works

Even if the whole thing is vibe-coded, the process can stay understandable.

Small surface area

Few screens, few users, few edge cases. You can still explain the app in one conversation.

Fast human feedback

The users are nearby. You can ask what happened, fix it manually, and delete bad ideas.

Low blast radius

If it breaks, nobody loses money, medical data, legal rights, or production operations.

Still inspectable

A motivated person can read the code, understand the data, and know where complexity lives.

Small enough to hold in your head5
Disposable software

Tiny apps do not need to become products. They can die after being useful.

Build for a season

A meetup series, trip, game night, habit sprint, or temporary household routine can deserve software.

Delete without guilt

No roadmap, investors, migration plan, or brand promise. If the group changes, the app can disappear.

Disposable does not mean useless.

Temporary can still be valuable6
My example

Football score tracking moved from Google Sheets to an actual field UI.

A few hours of work created admin controls, game management, and a screen that fits the moment.

football-team-splitter.pages.dev admin mode live scores less sheet friction
Tonight's match
Blue team
3
Red team
2
Example: field-ready utility5
Where it breaks

Full “not even looking at code” vibing is not there yet.

In a big greenfield PMS build, agent-written code can grow faster than anyone's shared understanding.

After a few months
  • Vocabulary drifts between agents, issues, and humans.
  • GitHub issues become hard to read instead of clarifying work.
  • Spaghetti code spreads across unclear boundaries.
  • No one can disentangle complexity by hand anymore.
The lesson
  • LLMs need architectural constraints.
  • Domain language must stay human-owned.
  • Small tools tolerate mess; core systems do not.
  • The human still has to manage complexity.
Complexity compounds silently6
Complexity cliff

The danger is the gap between generated complexity and human understanding.

Month 1: still legible 3 issues
Define reservation states
Add room assignment screen
Decide guest vs company account
Month 2: vocabulary starts drifting 28 issues
Clarify guest / customer / profile naming
Refactor booking service before folio work
Unexpected reservation transition after checkout
Sync room inventory with stay lifecycle events
Normalize account ownership across PMS modules
Agent report: possible duplicate source of truth
Month 3: issue tracker becomes noise 120+ issues
Agent report: mismatch in occupancy sync pipeline adapter boundary
Refactor booking aggregate service provider for multi-folio transition
Clarify guest / customer / profile / account vocabulary collision
Unexpected reservation state transition during inventory reconciliation
Possible duplicate source of truth in stay lifecycle orchestration
Investigate generated migration assumptions for room-unit inventory table
Potential race condition in nightly room availability snapshot reconciler
Agent proposal: create canonical domain abstraction for stay entity hierarchy
The issue tracker stops explaining the system. It becomes part of the system's noise.
Complexity grows faster than the map7
My LLM tier list

Personal ranking for building small software in June 2026.

Claude Fable 5 Most powerful and most expensive. The $20 plan burns too fast; $100 feels viable. With $20, only Sonnet is really usable.
Codex Efficient $20 plan. Much better token budget than Claude for this style of work. This deck was made using Codex.
Gemini Good deal if you need Google storage: 100GB storage plus Gemini Pro makes the plan easy to justify.
Opinionated model economics7
Productivity is area

Great engineers with average agents can still beat average engineers with top agents.

A better LLM helps, but it does not scale to infinity without architecture, domain judgment, and programming experience behind it.

Strong dev
average LLM
Better decomposition, review, and domain choices.
68
54
area = 3672
LLM power needs human leverage8
Suggested tiny stack

Use boring pieces that stay visible to you and to the agent.

Cloudflare Pages free deploy + pages.dev subdomain
Cloudflare SQLite / D1 free database tier
Alpine + htmx simple interactivity
Bun + Drizzle optional structure
Rule of thumb

You probably do not need React. You might not need a database. Object storage, a JSON file, or a tiny SQLite schema may be enough.

  • Small codebase
  • Few dependencies
  • Clear data ownership
  • Easy manual fixes
Keep the stack smaller than the problem6
What LLMs love to overbuild

Most accepted tech is optimized for larger teams than yours.

Usually overkill
  • Heavy SPA architecture for four screens
  • Complex auth when a shared admin link works
  • Microservices before there is one real service
  • Generic platform thinking for one group
Usually enough
  • Server-rendered pages plus small interactions
  • A tiny database or object storage
  • Manual admin flows for rare operations
  • One repository you can still understand
Complexity is the real cost7
Meetup companion

Our Telegram group is already a product spec.

1
Before

RSVPs, topic ideas, questions, and links are scattered across chat.

2
During

The organizer sees attendance, topic queue, and anonymous questions.

3
After

The group gets notes, links, recap, and lightweight history.

RSVP topic voting question box food preferences bring list recaps
Small repeated friction8
Single weekend projects

Good ideas are specific, low-risk, and annoying enough to matter.

S
Tabletop scoring

Score sheets, timers, round history, and printable summaries for board games.

M
Meeting tracker

Agenda, decisions, owners, links, and follow-ups for a small recurring group.

C
Chores board

Rotations, swaps, overdue items, and small household accountability.

G
Group habits

Shared goals, check-ins, streaks, and weekly reflection for friends.

W
Telegram wiki

A clean group knowledge page linked to a bot that can save answers from chat.

A
Avalon helper

Role notes, game setup, and scoring around the existing Resistance / Avalon project.

Weekend-sized tools9
Human judgment still matters

The agent can write code. You still decide what deserves to exist.

  • What is actually useful?
  • What should be stored?
  • What should remain private?
  • What can break safely?
  • What should stay manual?
  • When is the app overbuilt?
Engineer as product thinker, reviewer, operator10
Use the right rigor

Match engineering effort to blast radius.

Good domains
  • Meetups and hobby groups
  • Trip planning and book clubs
  • Small community rituals
  • Personal dashboards
Risky domains
  • Payments and medical information
  • Legal workflows
  • Serious access control
  • Safety-critical systems
Not everything should be vibe-coded11
Vibe coding checklist

Good vibe-coded projects are small enough to recover from.

Good signs
  • One owner can understand the whole app.
  • The data model has a few obvious objects.
  • Mistakes are reversible or manually fixable.
  • The users are close enough to give fast feedback.
  • No compliance, uptime, or security burden.
Bad signs
  • Many teams need to coordinate around it.
  • The domain language is already unclear.
  • It touches shared infrastructure or core data.
  • Incidents would hurt money, trust, or safety.
  • Agents create issues nobody understands.
Use small blast radius as the filter12
Publish the deck

This presentation lives on Cloudflare Pages.

It is static HTML, published as a Pages, built in 2h.

Direct upload

Wrangler uploads the built static folder directly to the existing Pages project.

Public URL

The deck is shareable at software-for-10-people.pages.dev, with preview URLs for each deployment.

Make it shareable12
Build this weekend

Pick a tiny workflow where the users are in your chat history.

1
Find the sheet

Look for a spreadsheet, pinned message, or repeated chat ritual that already acts like a database.

2
Keep it narrow

One workflow, one URL, one owner, and a data model you can explain without opening the code.

3
Ship ugly first

Use the first version to learn the real workflow. Polish only after the group actually uses it.

score tracker chores board meeting follow-ups habit group Telegram wiki
The practical takeaway13
Thesis

Not every useful app needs a market. The future is also tiny apps.

The future is also tiny apps12