Prompt: Write a realistic American novel about an indie developer in Silicon Valley

Example output

This prompt produced a complete novel: Nights and Weekends. Read it first to see what the instructions below turn into.

You are a long-form novelist who specializes in realistic business fiction, internet startup stories, and accessible commercial fiction. You also have a working knowledge of indie software development, app design, software engineering, marketing, user acquisition, and sustainable monetization.

Use GitHub Spec Kit's specification-driven workflow to create a full-length novel of approximately 100,000 to 125,000 words, written in idiomatic contemporary American English and set in and around a small Silicon Valley town in California.

Do not begin drafting Chapter 1 as soon as you receive this prompt. Complete the following stages in order:

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.analyze
/speckit.implement
/speckit.converge

If the current environment does not support these commands, treat them as mandatory creative-development stages and produce the corresponding Markdown files.

1. Project goal

The novel follows an ordinary software developer who uses nights and weekends to become an independent developer.

The protagonist begins by noticing a real, specific problem. Over time, they conduct customer research, define a target market, choose a technical approach, build an MVP, launch it, search for their first users, set prices, experiment with content and community marketing, improve their app-store presence, respond to feedback, study product data, hit a growth plateau, endure a failed product or major false start, face pressure on their personal finances, and eventually find a business turning point. By the end, they have built a small software company that produces dependable income, though neither the business nor the protagonist's life is perfect.

The novel must work on three levels:

1. As fiction, it should have memorable characters, conflict, suspense, planted clues, setbacks, reversals, hope, and strong reasons to keep reading.
2. As a practical story, it should show the full path from identifying a problem and building a product to finding customers and earning revenue.
3. As an emotional story, it should encourage ordinary developers to begin with a side project without promising overnight wealth or minimizing failure, luck, privilege, timing, and the cost of sustained effort.

2. Creative constitution

The following rules have the highest priority. Every later decision, plotline, and chapter must follow them.

1. Write in natural, contemporary American English. Dialogue must sound like people who live and work in the United States, with differences in voice based on age, region, class, profession, personality, and cultural background.
2. Keep the prose accessible to a general adult reader who has no specialized knowledge of software or business. Accessible does not mean childish, cute, or simplistic.
3. Use clear, concrete sentences and specific sensory detail. Avoid obscure vocabulary, empty inspiration, internet jargon, startup clichés, and long lectures.
4. Business knowledge must emerge through choices, actions, arguments, tradeoffs, and consequences. The novel must never read like a tutorial with fictional scenes pasted between lessons.
5. The protagonist may not solve the central problem through a lottery win, a mysterious investor, an unexplained viral spike, or another unearned rescue.
6. Success must come from several factors working together: sound judgment about customer needs, product quality, consistent marketing, iteration, help from other people, timing, and some luck.
7. Failure must carry real costs, such as lost time, foregone career opportunities, reduced income, strained relationships, damaged health, shaken confidence, refunds, churn, or lost trust.
8. The protagonist may make serious mistakes. Those mistakes must change how they understand the problem, and later actions must test that new understanding.
9. Supporting characters must have goals, loyalties, pressures, blind spots, and lives of their own. They may not exist only to advise, obstruct, praise, or rescue the protagonist.
10. Do not disparage salaried employment, venture-backed startups, large companies, team-based entrepreneurship, or other career paths. Indie development is one legitimate choice, not the only enlightened one.
11. Do not invent inside information about real companies. Do not imply that the protagonist's financial results can be easily copied by every reader.
12. Maintain continuity in character ages, dates, seasons, geography, employment terms, product capabilities, user counts, pricing, revenue, costs, taxes, and cause and effect.
13. Portray Silicon Valley as a real place where people commute, raise families, struggle with housing costs, worry about health insurance, change jobs, and live outside the startup bubble. Do not reduce it to venture capital, hoodies, and pitch decks.
14. The cast should plausibly reflect the Bay Area's social and cultural range. Give every major character an individual history and voice; do not use identity as shorthand or turn characters into demographic symbols.
15. Treat American legal, financial, and workplace realities seriously when they affect the plot. These may include at-will employment, employer intellectual-property and moonlighting clauses, health insurance, California and federal taxes, business registration, payment processing, privacy obligations, and app-platform rules. Verify details before relying on them.
16. Use U.S. dollars, American date and time conventions in ordinary prose, U.S. customary units where a character would naturally use them, and metric units where American technical practice calls for them.

3. Story world

Build a coherent, near-realistic version of contemporary Silicon Valley. The default setting is a fictional small town in Santa Clara County or on the Peninsula, within commuting distance of Mountain View and Palo Alto. The town may draw on places such as Los Altos, Campbell, Mountain View, Sunnyvale, and Redwood City, but it must have its own name, geography, local businesses, and civic identity.

Real cities, highways, transit systems, weather patterns, and regional pressures may appear when useful. Companies, employers, apps, social networks, and products may be fictional. If real platforms are used, their rules and economics must be accurately represented for the stated year.

At minimum, establish:

• The protagonist's family background, education, work history, financial position, professional limits, and central personality flaw.
• The specific incident that pushes the protagonist toward indie development.
• A clear, credible user problem grounded in ordinary life or work.
• A core app that begins as a narrow MVP and evolves over time.
• Coworkers; a spouse, partner, relative, or close friend; early users; fellow developers; a competitor; and at least one collaborator or business partner.
• Long-running tension among work, family, health, housing, income, immigration or residency status if relevant, and the product.
• The indie-developer community, the target-customer community, the market, and the competition.
• One business-growth arc, one personal-growth arc, and at least two major relationship arcs.
• Foreshadowing that carries across the book: misread evidence, an unkept promise, a hidden conflict, a technical shortcut, a contractual risk, or another unresolved issue.

The story may not move in a straight line from "build" to "launch" to "profit." It must include at least:

• One mistaken reading of customer demand.
• One episode of uncontrolled scope growth.
• One launch that draws almost no users.
• One marketing win that produces attention but few or no paying customers.
• One major change prompted by feedback from an actual user.
• One technical, security, legal, or platform risk.
• One cash-flow crisis or difficult career decision.
• One broken relationship or serious loss of trust.
• One severe setback after a brief period of success.
• One important breakthrough earned through long accumulation rather than a single lucky event.
• An ending that feels earned and hopeful but not perfectly resolved.

4. Practical content

Show the following methods naturally through decisions and consequences. Make clear when each method works, when it does not, and what it costs.

• Finding a problem worth solving in daily life or at work.
• Interviewing potential customers without leading them.
• Distinguishing "That sounds useful" from willingness to pay.
• Defining a target customer and a core use case.
• Controlling MVP scope.
• Choosing a technical approach and estimating maintenance burden.
• Setting a price, trial policy, free tier, and paid plans.
• Finding the first 10, 100, and 1,000 users.
• Using content, communities, direct outreach, partnerships, app-store discovery, search, and word of mouth.
• Tracking acquisition, activation, retention, conversion, churn, support volume, and revenue.
• Handling refunds, negative reviews, customer support, bugs, outages, and feature requests.
• Accounting for hosting, software tools, contractors, payment fees, marketplace commissions, taxes, insurance, and the founder's time.
• Deciding whether to continue, pivot, narrow the product, sell it, maintain it quietly, or shut it down.
• Balancing a full-time job, family or relationships, health, and side-project work.
• Carrying code, distribution, professional credibility, customer knowledge, and judgment from one failed attempt into the next.

Do not pile up terminology. Important business lessons should usually follow this dramatic pattern:

A problem appears
→ a character interprets it
→ the character takes a specific action
→ data or human feedback arrives
→ the action carries a cost
→ the character revises their understanding

Do not make the protagonist correct every time. A clean metric may conceal the wrong behavior; an emotional customer story may matter more than a dashboard; a theoretically good tactic may fail because of timing, trust, reach, or execution.

When the plot depends on a real platform rule, fee, software version, tax requirement, employment law, privacy obligation, or market statistic, verify it with a reliable source. Record the source and the date checked in research.md. If a fact is likely to change, state the period in which it applies. If it cannot be confirmed, use a clearly fictional platform or institution instead of inventing a fact.

5. Length and structure

The target length is 100,000 to 125,000 English words, excluding planning files and appendices.

Recommended structure:

• 5 or 6 parts.
• 55 to 70 chapters.
• Roughly 1,600 to 2,300 words per chapter, with deliberate variation when the scene requires it.
• Each part has its own objective, dominant conflict, climax, and unresolved pressure that carries forward.
• Every chapter must advance the plot, a relationship, the protagonist's inner arc, or the business. Most chapters should advance more than one.
• Most chapter endings should introduce a consequential question, choice, risk, discovery, or reversal. Do not manufacture a false cliffhanger at the end of every chapter.
• Alternate pressure and relief. Avoid long sequences made entirely of meetings, coding sessions, analytics reviews, or explanations.

The first three chapters must quickly establish:

1. The protagonist's immediate real-world problem.
2. A problem that might become a viable product opportunity.
3. A personal reason the protagonist cannot simply ignore it.
4. What the protagonist stands to lose by trying and by doing nothing.

6. Spec Kit deliverables

Stage 1: constitution

Create .specify/memory/constitution.md. Record all non-negotiable creative principles, American-English language standards, realism requirements, research rules, and continuity constraints.

Also create novel/constitution.md as a readable project copy if the workflow allows it.

Stage 2: specify

Create novel/spec.md with at least:

• A one-sentence premise.
• Themes and the central dramatic question.
• Intended readership.
• Intended reading experience.
• Setting and social world.
• Major characters.
• The protagonist's external goal, internal need, and fatal flaw.
• The core product and its target customers.
• Main sources of conflict.
• The intended ending.
• Functional requirements.
• Nonfunctional requirements.
• Testable acceptance criteria.
• A clear list of material the novel will not include.

Stage 3: clarify

Identify no more than five ambiguities that could substantially change the novel. Do not ask the user questions. Resolve each ambiguity internally and record it in novel/clarifications.md using the format specified in Section 9.

If no stronger choice emerges from the story's needs, use these defaults:

• The story takes place in the present day in a fictional small town in Silicon Valley, California.
• The protagonist is an ordinary software developer in their late twenties to mid-thirties with several years of professional experience.
• The protagonist holds a full-time job and builds the product on nights and weekends.
• The product is a focused app or small SaaS product that solves a specific problem for a narrow customer group.
• The protagonist has limited savings, no wealthy family safety net, and no privileged access to investors.
• The ending brings sustainable income and greater control over time, not billionaire status.
• The tone is realistic, warm, restrained, occasionally funny, and driven in part by business suspense.

Stage 4: plan

Create:

• novel/plan.md: the overall creative plan.
• novel/world-bible.md: geography, local culture, institutions, workplaces, and social environment.
• novel/characters.md: character profiles, relationships, distinctive voices, contradictions, and arcs.
• novel/product-bible.md: the app's features, technical architecture, release history, operational risks, and business model.
• novel/business-ledger.md: dated user counts, prices, revenue, refunds, costs, conversion rates, churn, taxes, and cash flow.
• novel/timeline.md: the master chronology, including ages, seasons, work events, product releases, and relationship events.
• novel/foreshadowing.md: planted clues, intended payoff chapters, actual payoff chapters, and current status.
• novel/research.md: technical, business, legal, geographic, and platform facts that require verification, with dated sources.
• novel/chapter-outline.md: a part-by-part and chapter-by-chapter outline.

For every chapter, the outline must specify:

• Date or time period and location.
• Point-of-view character.
• Chapter objective.
• Main conflict.
• Important actions and decisions.
• Practical business or product knowledge embedded in the action.
• Emotional movement.
• Foreshadowing planted or paid off.
• The force that pulls the reader into the next chapter.
• Estimated word count.

Stage 5: tasks

Break the work into executable tasks. The order must include at least:

1. Complete the story-development documents.
2. Check character logic, product logic, American setting details, and business realism.
3. Draft the novel one part at a time.
4. Run a continuity check after each part.
5. Check that practical knowledge is dramatized rather than explained as a lesson.
6. Verify business figures, technical claims, legal details, and platform facts.
7. Revise pacing, dialogue, character voice, and repeated material.
8. Audit every major setup and payoff.
9. Standardize American English and complete the final prose edit.

Every task must have an identifier, dependencies, inputs, outputs, and a definition of done.

Stage 6: analyze

Before drafting the novel, compare the constitution, specification, plan, and task list. Check for:

• Conflicting character motivations.
• Timeline and travel errors.
• Contradictory product features.
• Implausible user, revenue, tax, or cost figures.
• Employment, intellectual-property, privacy, or platform issues ignored by the plot.
• Plot events that do not support the themes.
• Repetitive chapters.
• Reversals without setup.
• Exposition that feels like a business textbook.
• Missing production or revision tasks.

Fix the relevant documents before drafting. Do not proceed until the story is internally workable.

Stage 7: implement

Do not attempt to place the entire novel in a single chat response. Draft 2 to 4 chapters per batch and save each chapter to its own file.

Before each batch, read the relevant planning documents, timeline, business ledger, product state, and summary of prior chapters. After each batch, update:

• Total word count.
• Current character states.
• Product version and capabilities.
• User and revenue figures.
• Foreshadowing planted and paid off.
• Unresolved conflicts.
• Goals for the next batch.

Unless explicitly requested, do not add a narrator's summary of "what this chapter teaches." Let readers understand the lesson through action and outcome.

Stage 8: converge

At the end of each part and again after the full draft, compare the manuscript against the constitution, specification, plan, and tasks.

Confirm:

• The plot is complete and causally coherent.
• Character growth is believable.
• Business decisions are useful to observe without becoming universal prescriptions.
• Technology, dates, product features, and financial figures remain consistent.
• Major setups receive satisfying payoffs.
• The book does not become a diary of tasks or a disguised tutorial.
• The story gives developers realistic motivation, practical perspective, and an honest sense of cost.

7. Prohibited shortcuts

• Do not write the protagonist as an all-purpose genius.
• Do not use repeated coincidences to solve central problems.
• Do not replace character development with speeches.
• Do not list marketing terms or programming steps for pages at a time.
• Do not promise that effort guarantees success.
• Do not soften the cost of failure to make the book more inspirational.
• Do not make every supporting character agree with the protagonist.
• Do not sustain misery for most of the novel and then manufacture sudden wealth at the end.
• Do not skip specification, planning, research, or review stages.
• Do not repeat scenes, arguments, or lessons to reach the target word count.
• Do not use startup culture as exotic scenery. Show the ordinary systems and people beneath it.
• Do not force every American character into the same casual, sarcastic voice.

8. Fully autonomous execution

This is a complete creative-production task that does not require user participation.

From the moment this prompt is received, continue through:

constitution
→ specify
→ clarify
→ plan
→ tasks
→ analyze
→ implement
→ converge
→ assemble the manuscript
→ final quality review

Do not wait for approval at any stage. Do not ask the user questions, offer a menu of story options, or ask whether to continue.

You are authorized to make the following creative and project-file decisions independently:

• Choose the novel's title.
• Choose all fictional character names, ages, careers, histories, and relationships.
• Name and design the fictional Silicon Valley town.
• Choose the exact year and local social context.
• Choose the product category.
• Choose the technical stack, marketing channels, and business model.
• Resolve ordinary ambiguities.
• Adjust the number of parts, chapters, and words per chapter while remaining within the final acceptance criteria.
• Revise the outline, chronology, product plan, and character relationships.
• Rewrite chapters that fail the quality standard.
• Research and verify factual claims.
• Create, read, and modify files inside the project directory.
• Assemble and polish the final manuscript.

Do not stop unless an unrecoverable system failure prevents further work.

When uncertain, decide in this order:

1. Follow the creative constitution.
2. Protect realism, narrative momentum, and continuity.
3. Choose the option that best matches real business behavior and American life.
4. Choose the option that creates credible conflict and character growth.
5. Use the defaults in this prompt.
6. If several options remain equally viable, choose the strongest one and continue.

Record all consequential assumptions in novel/assumptions.md. Do not pause to seek confirmation.

9. Internal clarification rules

The clarify stage is an internal decision-making exercise, not a user interview.

For each material ambiguity, write the following in novel/clarifications.md:

• Ambiguity.
• Plausible options.
• Final decision.
• Reason for the decision.
• Effect on the story.

Default assumptions:

• The story is set in the present day in a fictional small town in Silicon Valley.
• The protagonist is 28 to 35 years old.
• The protagonist is a competent but unexceptional software developer who is willing to learn.
• The protagonist has a full-time job and develops the product during evenings and weekends.
• The product is a small app or SaaS tool for a specific customer group with a concrete problem.
• The protagonist has limited capital and no influential family background.
• The ending is a sustainable small software business and greater freedom of choice, not sudden wealth.
• The book is realistic, warm, restrained, funny in places, and propelled by both personal and business suspense.

10. File organization

Do not place the complete manuscript in chat. Write it continuously to workspace files.

Use this directory structure unless the environment requires a minor variation:

novel/
├── README.md
├── constitution.md
├── spec.md
├── clarifications.md
├── assumptions.md
├── plan.md
├── tasks.md
├── world-bible.md
├── characters.md
├── product-bible.md
├── business-ledger.md
├── timeline.md
├── foreshadowing.md
├── research.md
├── chapter-outline.md
├── progress.md
├── quality-report.md
├── volumes/
│   ├── volume-01/
│   │   ├── chapter-001.md
│   │   ├── chapter-002.md
│   │   └── ...
│   ├── volume-02/
│   └── ...
└── final/
    ├── full-novel.md
    ├── synopsis.md
    └── practical-lessons.md

Save every chapter separately and use three-digit chapter numbers.

Never overwrite, skip, or silently discard a completed chapter. When revising a chapter, preserve the correct final version and update the relevant character file, timeline, product bible, business ledger, progress log, and foreshadowing tracker.

11. Continuous drafting loop

Repeat the following cycle until the manuscript is complete:

1. Read the constitution, chapter outline, and current progress log.
2. Check the characters, product state, business figures, location, and chronology needed for the next chapters.
3. Draft 2 to 4 consecutive chapters.
4. Save each chapter in the correct directory.
5. Check word count, dramatic movement, character behavior, dialogue, business figures, and foreshadowing.
6. Fix the problems found.
7. Update novel/progress.md.
8. Begin the next batch immediately without waiting for a user response.

At minimum, novel/progress.md must record:

• Completed chapters.
• Current manuscript word count.
• Current state of each major character.
• Current product version and features.
• User count, revenue, costs, taxes, and cash position.
• Foreshadowing planted.
• Foreshadowing paid off.
• Unresolved conflicts.
• Objectives for the next batch.
• Result of the most recent quality check.

If work is interrupted by context compression, session recovery, or another nonfatal event, first read novel/progress.md, novel/timeline.md, novel/characters.md, and the three most recent chapters. Resume from the interruption point. Do not restart or rewrite completed work from scratch.

12. Automatic quality checks

After every chapter, check:

• Did the chapter advance the plot, a relationship, the inner arc, or the business?
• Did a meaningful action, result, discovery, or change occur?
• Did the chapter repeat an earlier explanation or emotional beat?
• Is the American English natural, specific, and consistent with the viewpoint character?
• Does the ending create honest forward movement?

After every part, check:

• Are character motivations consistent while still capable of change?
• Does every major turn have adequate setup?
• Are product capabilities and release dates consistent?
• Are user counts, revenue, costs, taxes, workload, and cash flow plausible?
• Are Silicon Valley geography, commutes, housing, employment conditions, and daily life believable?
• Is practical knowledge embedded in drama?
• Does any section feel like a tutorial or founder diary?
• Are planned setups developing at the right pace?
• Does the part have its own climax and a meaningful partial resolution?

Fix ordinary problems immediately. Do not report them and wait for instructions.

13. Definition of complete

The task is complete only when all of the following are true:

• The finished manuscript is between 100,000 and 125,000 English words.
• It contains 55 to 70 complete chapters.
• Every chapter is saved in its own file.
• The plot has a complete beginning, development, climax, and ending.
• The protagonist undergoes believable personal change.
• The product passes through problem discovery, research, building, launch, marketing, monetization, failure, adaptation, and sustainable operation.
• Technology, user counts, revenue, expenses, taxes, cash flow, geography, and chronology are internally consistent.
• Every major character reaches a clear endpoint, even if some parts of their life remain unresolved.
• All important foreshadowing has been paid off.
• The full manuscript has been checked for repeated material.
• Dialogue, pacing, point of view, and American English have received a final edit.
• novel/quality-report.md is complete.
• All chapters have been assembled in the correct order in novel/final/full-novel.md.
• novel/final/synopsis.md and novel/final/practical-lessons.md are complete.

If the manuscript is under 100,000 words, do not pad it with repeated scenes or advice. Add meaningful complications, relationship developments, customer situations, business problems, and consequences.

14. Final response

During production, provide only brief progress updates. Do not present an intermediate artifact as the completed task. Do not say, "If you'd like, I can continue," and do not require the user to send "continue."

Keep working until the manuscript meets every acceptance criterion.

Only then provide a final completion report containing:

• The novel's title.
• Final word count.
• Total number of chapters.
• The title of each part.
• Paths to the main deliverables.
• The conclusion of the quality review.
• A synopsis of no more than 200 words.

Begin now with the creative constitution and continue through delivery of the complete novel. Do not ask questions, wait for approval, or stop early.