Indie Dev with AI: Build, Ship, Monetize Solo

The question "will AI take my job" no longer fits this story. Siddiq and Zhang at UCLA Anderson followed 49,610 freelancers and 2.26 million contracts on Upwork from January 2021 to March 2026, and what they found was not a change in whether the work exists but a change in how you get chosen: the weight clients put on human-capital signals fell 7.8% while the weight on price rose 1.1%, and contract counts fell 7.0%. Verified credentials, work history, portfolio and client ratings all lost their power to predict who wins the contract, and the decline is steeper the more recent you look, at -10.1% on signals and +1.8% on price over the most recent four quarters. At the same time the supply side is moving the other way: Upwork reports that the freelance share of skilled US knowledge workers went from 28% to 38% in a single year, with 58% of full-time employees considering the switch. Two paradoxes sit at the center. First, experience is a shield in employment and not in contract work, because Stanford finds employment for workers aged 22 to 25 in AI-exposed occupations about 19% lower with no comparable gap for the experienced, while an Organization Science study of freelancers finds the drop largest among the most experienced. A company hires a role; a client buys a deliverable. Second, the work has not disappeared, the middle has: Management Science reports postings most open to automation down 21%, with the jobs that remain more complex and better paid. The article uses only peer-reviewed papers, preprints and official platform research, each checked against the publisher itself, flags Upwork as an interested party, corrects the widely repeated claim that its February release reported a 44% hourly premium (it does not mention one), and carries the researchers own caveats, including Stanford stating that some of the timing is driven by factors other than AI. Three forecasts come with confidence labels and falsification conditions, and the closing chapter on what to do is labeled speculation.

The most common failure in indie development is "I built it but no one uses it." But the real bottleneck isn't building skill—it's marketing. "Build something good and they'll come" is a fantasy. Build in Public to gather prospects before you build; get the first 10 by hand from people near you (do things that don't scale); find the first 100 by contributing where they gather (communities, social media) so they discover you; and create steady traffic with SEO/AEO/LLMO. This article lays out that order—using AI as your prep hand—from an indie developer's point of view.

The biggest reason indie projects never get finished is "over-building." Piling on feature after feature makes it complex, and it vanishes before it ever launches. The one way to avoid that is to narrow the smallest product that conveys value—the MVP—to a single feature and ship it as fast as possible. This article explains, from the point of view of an indie developer who makes AI their partner, the right way to see an MVP, scope decisions for cutting features, two routes to build fastest with AI (vibe coding where you write no code, and the hands-on AI-editor route), judging "finished," and getting one person to use it after launch.

Many indie developers stall at "I built it, but how do I earn, and what do I charge?" This article covers, from a solo developer's point of view, how to choose a monetization model (free / one-time / subscription / freemium / ads / donations), value-based pricing that starts from "the value the customer gains" rather than cost or competitors, the Free→Pro→Business three-tier plan and the annual-discount playbook, how to land your first paying users, and unit economics that fold in AI costs such as API tokens. It goes deep on the "grow" phase of the hub article, the AI indie development roadmap.

Now that AI has a hand that writes code, one person can build a product and ship it. But the information is scattered by stage, so it is easy to get lost about where to start. This article is a full map (roadmap) from idea to design to implementation to launch to monetization, organizing solo development into five phases (Decide, Prepare, Build, Ship, Grow) and, for each stage, showing what to do and which tools to use, then sending you to a dedicated guide for the parts that need a deeper dive. It guides you along two lanes: a Beginner route where you barely write code, and a Hands-on route where you write code in an AI editor, so following whichever fits gets you to something that works without detours. It gathers spec-driven development, AI app builders, Claude Code and Cursor, wiring in AI features (API, RAG, gateway), deploy, SEO/AEO traffic, monetization, cost management, and five pitfalls of solo dev with AI onto one page, with links into the existing hands-on guides.

You built on OpenAI, then wanted to try Claude and compare Gemini — and lost hours to the different SDKs, formats, and error handling per provider. An LLM gateway (AI gateway / LLM proxy) is a relay you slot between your app and the providers: it exposes one OpenAI-compatible API to reach every model and takes over the cross-cutting chores — fallback, cost tracking, virtual keys, caching, rate limiting, and observability. This guide covers why you need one, what a gateway really is, the three types (self-hosted proxy = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), how to choose among LiteLLM, OpenRouter, and the Vercel AI SDK, minimal setup code that only swaps the endpoint, and the limits — a hop of latency, the gateway as a new failure point, fees (OpenRouter charges 5.5% on purchases), feature loss, and privacy.

The "Permission Mode" selector next to the prompt box in Claude Code (cycled with Shift+Tab) sets how often Claude pauses to ask permission before editing a file or running a command. This guide covers what permission modes are (the oversight-vs-autonomy tradeoff; with v2.1.283 or later, terminal and VS Code sessions start in Auto on every plan (earlier, only on Pro, Max, and Team), while claude -p and the Agent SDK start in Manual; protected paths like .git and .claude are never auto-approved outside bypass), the five selector modes (Manual = default, reads only auto-approved; Accept edits = acceptEdits, auto-approves edits and common filesystem commands such as mkdir, rm, and mv inside your working dir; Plan = plan, explores and proposes a plan without editing; Auto = auto, a separate classifier blocks dangerous actions while running everything else without prompts; Bypass permissions = bypassPermissions, nearly everything with no checks, isolated environments only) plus a sixth, dontAsk, which never appears in the Shift+Tab cycle and is set by flag or in settings, how to switch (Shift+Tab cycles Manual, Accept edits, and Plan, with Bypass and Auto joining after Plan when available; the --permission-mode flag; and defaultMode in settings, where auto and bypassPermissions don't take effect from project settings), auto mode in depth (the classifier's allow/block defaults, available by default on Team and Enterprise unless an admin turns it off, supported models Opus 4.6+, Sonnet 4.6+, or Fable, conversational boundaries honored as block signals, and the 3-consecutive / 20-total block fallback), which mode to use when and safety (bypass has no prompt-injection protection so it's isolated-only; Auto is the right answer for everyday prompt fatigue; hooks still run in bypass; with bypass available in a terminal, plan mode doesn't stop edits), and how permission mode relates to the effort setting (permission mode = how much it asks, effort = how hard it thinks). Based on the official docs and the desktop app's UI as of October 5, 2026.

That "Effort" slider next to the model name in Claude Code — the Faster-to-Smarter dial — sets how much work (thinking, tool calls, and response text) the AI puts into each reply. This guide covers what effort is; the slider's 5 levels and labels (the API has 5 levels, low to max; the slider reads Low, Medium, High, Extra, Max, where "Extra" = xhigh and the top effort is "Max"); what persists (low–xhigh are saved per model when you confirm with Enter, Max is session-only); model support and auto-downgrade (xhigh needs a relatively recent model such as Fable 5.1, Opus 5.5, or Sonnet 5.5; Opus 4.6 and Sonnet 4.6 have no xhigh and downgrade to high; Haiku 4.5 has no effort control; Claude Code's default varies by model: medium on Opus 5.5 and Sonnet 5.5, high on Fable 5.1); how to set it (/effort slider and direct values, /effort auto, /model, --effort, the CLAUDE_CODE_EFFORT_LEVEL env var as highest priority, the modelSettings and effortLevel settings, and skill/subagent frontmatter); a quick-reference table; an in-depth look at Ultracode (not an effort step but an on/off switch that works at any level and has Claude build multi-agent dynamic workflows on its own; limited to xhigh-capable models; turned on with /effort ultracode, the Tab key, or "ultracode": true in settings; when to use it, cost cautions, and what changed in v2.1.284); and related features (ultrathink, /fast). Based on official docs (as of September 2026) and the live UI.

Claude Code hooks are user-defined shell commands that run automatically at specific points in Claude Code's lifecycle, making "this must always happen" real and deterministic without relying on the LLM's judgment. The classic events are nine—SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStop, SessionEnd, PreCompact—of which PreToolUse and others can block (stopping protected-file edits or dangerous commands). You configure them in settings.json under the "hooks" key as event name -> matcher -> type + command. The I/O contract: a hook receives JSON on stdin (session_id, tool_input, etc.) and returns via exit code 0 (success) / 2 (block, with stderr passed back to Claude) or structured JSON (continue, decision:block, permissionDecision: deny/allow/ask). The key principle is "hooks can tighten but not loosen restrictions" (deny always wins, blocks even under bypassPermissions; a plugin mod can override this in some setups). Classic use cases: auto-format after edits (PostToolUse + Edit|Write), protect critical files, stop dangerous commands, re-inject context (SessionStart), notifications/audit logging, and test-before-stop (Stop). On security, hooks run arbitrary shell commands with your privileges, so only configure trusted ones and validate/quote inputs; in interactive sessions, settings-file hooks do not run until you trust the folder (a safety feature), and direct edits to settings files are normally picked up automatically. Based on the official documentation, anchored on the nine classic events and the I/O contract.

Working in Claude Code, you suddenly see "You've hit your session limit · resets 3:45pm" and stop cold. This is not an error or a bug: it is how subscription usage limits work. The official error reference lists four versions — session (the rolling 5-hour window), weekly (the weekly window), and Opus and Sonnet (caps for one model family) — and because session and weekly limits are shared by all models, switching models does not bring access back. This article explains what the four messages mean and how the wording changed from the older "Claude usage limit reached. Your limit will reset at …", the four biggest consumption drivers (model choice, context size, long continuous sessions, subagents/MCP), five moves when you hit the cap (switch models for an Opus/Sonnet cap, trim context with /compact so the next window lasts, wait for the reset — automatic from v2.1.234 — switch to pay-as-you-go API, or use /usage-credits or upgrade), how to see what is left (/usage, the status line, Settings → Usage), look-alike messages that are not your plan limit (Server is temporarily limiting requests, spend limit), and how subscription limits differ from API limits — based on the official documentation. Exact allowance numbers change over time, so the article avoids asserting them.

In an era where AI writes the code, the higher-value skill is shifting from "writing code" to "writing the spec" — and the practice that captures it is spec-driven development (SDD). SDD puts the spec at the center of the project as the source of truth, and an AI agent derives the design, breakdown, and implementation from it instead of coding right away. The key is that each step leaves a document (often Markdown) that the next step reads. This beginner-friendly guide covers what SDD is (the spec is canonical; code is a derivative), why it matters now (it prevents vibe coding's "three-month wall" of technical debt and requirements drift at the design stage), the basic four steps (Specify → Plan → Tasks → Implement), the main tools (GitHub Spec Kit with 140,000+ stars and 30-plus supported agents, AWS Kiro with its Requirements → Design → Tasks flow and Auto router, plus BMAD, OpenSpec, Tessl, Google Antigravity, and Cursor), when to use it versus vibe coding (a hybrid: vibe to explore, spec-driven to ship, with mandatory human review), and how to try it today. In the AI age, the people who rise are those who can define precisely what to build, not those who write code fastest.

Going outside is hard, talking to people is tough, you are not working right now — even so, the chance to turn "from home, without meeting anyone, at your own pace" into income has genuinely widened with AI. This audience-specific guide lays out, as honestly and gently as possible, the first step for someone who is a hikikomori (a withdrawn recluse) or NEET to earn from home, from zero, using AI. It promises up front not to say "anyone can easily make thousands a month" (usually a lie or sales bait) and writes the realistic difficulty, time, and cautions openly. It covers why AI x working from home fits (done with no face-to-face, easy to start from zero, at your own pace — AI lowers the wall as a partner), the three honest truths (you will not earn right away and a first goal is your first few dollars; AI is an amplifier of effort not magic, anything times zero is zero; those who continue, not the smart ones, get results), ways to earn with no talking to people (writing, transcription/subtitles, AI image assets, data tidying, translation checking, digital products — pick one first), the first step today (touch a free AI, pick one field, make one practice piece — make before earning), how to stack small wins (portfolio, one low-pay job, build ratings, raise rate/volume — collect wins not amounts, the first job is worth most), how to keep going and protect your mind (do not compare, break it small, it is OK to rest, drop perfectionism, do not carry it alone — employment support and consultation services), and cautions on scams/hype, the risk of leaving it to AI, and taxes/dependents (avoid pay-first offers, legitimate crowdsourcing sites are basically free to join and list on, check official info). It is not "anyone, easily," but a step you can take truly exists — get back "I can do this too," one at a time.