SceneFiend.app — a full consumer product, built solo at team pace

The problem

Actors do not have a shortage of plays. They have a selection problem under deadline.

The material has to fit a specific person — playing age, type, training, what they are trying to prove in that particular room — and it has to be findable in the hour before it is needed. The existing options are a list of the same forty overdone monologues, a search box over a catalogue with no opinion about fit, or a friend who happens to know a play. The part that takes judgment — is this piece right for me, right now, for this audition — is the part nothing helps with.

A general-purpose chatbot answers this badly in a specific way: it will name a play with total confidence, invent a character who is not in it, and cheerfully recommend the most overdone monologue in the American theater. Confidence without sourcing is worse than no answer here, because the actor finds out in the room.

The product decision everything else follows from

SceneFiend widens the field. It does not pick for you.

That sentence is a product constraint with architectural consequences, and it was settled before the recommendation engine was written.

It means the system returns candidates the actor then goes and reads, researches, and judges — with the reasoning shown, so the actor can disagree with it. It means a piece that was chosen by nothing more than a default says so on the card, in those words, instead of manufacturing a personalization story. It means the product's own copy is audited against what the system can actually justify, and language that implies the machine has taste the actor should defer to is treated as a defect.

It is also why the recommendations are grounded in a curated corpus rather than drawn from a model's memory. The model reasons over a candidate set the system controls; anything it proposes from outside that set is labelled as unverified rather than presented as a find. A tool for a craft should make its user better at choosing, not train them to outsource the choice.

What is built

A full consumer application, not a prototype with a demo path.

For actors. Onboarding that reaches a first useful result in under a minute, including a "pick three" taste seed for people the system knows nothing about yet. Scene and monologue requests with tuning for era, tone, and length. Result cards with fit rationale in the actor's own vocabulary — the framing shifts with the training tradition they identify with, because a Meisner-trained actor and a British-classical actor do not want the same sentence about the same speech. A browsable library by playwright, era, cast, and tone. Public, shareable piece pages. A saved book with prep states, due dates, notes, printing, and private share links. History, collections, and a four-tab mobile shell, because these users are on phones.

For operators and expert reviewers. The half of the product no one sees: a curation workbench with review queues and coverage reporting, subject-matter-expert invitations and review packets, source-URL verification, a suggestion and feedback pipeline, health and monitoring dashboards, and internal statistics behind an allowlist. A curated library is an editorial operation. Building only the consumer surface is how a recommendation product ends up with nothing good to recommend.

Underneath. Next.js App Router and TypeScript on Vercel, Postgres, hosted model APIs, Playwright, and GitHub Actions. Roughly 77 routes, 149 components, 372 library modules, and 68 database migrations.

Rights are architecture, not a disclaimer

A product that points actors at plays is a product that handles other people's copyrighted work. That is a legal question, a product question, and a schema question at the same time, so it was settled as one.

Every piece in the library carries a rights posture, and the posture decides what the system will do with it. Metadata-only means SceneFiend describes the piece in its own words and points to where to buy or borrow it; excerpt-linked means a vetted source may show an excerpt and SceneFiend links out rather than copying; full-text-owned means public-domain status, ownership, or written permission has been verified for that specific text and edition; unknown means the row is not public at all.

The posture is enforced where it cannot be argued with. Only metadata-only rows are eligible for the sitemap, for public playwright pages, and for public share links — constants in the code, not a reviewer's habit. Scene text that does pass the gate is served through a SceneFiend-controlled route from an asset store that can be switched off in one move, so a takedown is an action rather than a deployment. Every content surface carries a report path with a rights and DMCA option.

Two consequences are worth naming, because they are the kind of thing that gets discovered late:

• Scene text mostly does not belong in the application repository. A commit is trivially mirrored, forked, cached, and quoted; deleting the file later does not remove it from public history. So the repo holds scene bodies only in a narrow, rights-cleared lane, with the edition, adaptation status, reviewer, review date, rights basis, and permitted display scope recorded beside the file. Everything else lives behind the kill switch.
• AI drafts, humans decide rights. Model-generated metadata and summaries enter a review queue. No automated process is permitted to set a rights posture or publish unreviewed generated content about a work.

None of this is visible to an actor, which is the point. It is also the difference between a library you can grow and one you have to take down.

Trust inside the machine

The interesting failures in an AI product are not outages. They are the times it is confidently, invisibly wrong.

Actor-typed text is never trusted as instruction. Everything a user types — goals, tone constraints, context about the room — is wrapped in isolation blocks inside the prompt, with closing tags neutralized, so a profile field cannot become a command. System-authored fallback copy renders inline, outside those blocks, and the two are never confused.

Empty signals say they are empty. With no profile, no taste history, and no saved work, the prompt renders authored fallbacks that instruct breadth instead of inventing a preference, ranking sliders sit at neutral where they bias nothing and filter nothing, and the first card shows a "working with defaults" marker rather than a fabricated "we chose this for you." All four layers are pinned by deterministic tests that run without a network or a model.

Ranking narrows nothing. Every signal is an additive boost or a soft dampener, never a filter, with diversity caps that hold a single work or author from taking over a result set. The actor's field of candidates gets ordered, not cut.

Spend is a design constraint. Daily request caps per account plus daily and monthly budget ceilings with alert thresholds and per-model cost accounting, all configurable at the environment level. A generation path that can be run by strangers needs a cost ceiling before it needs a launch date.

Grounding and output shape are verified, not hoped for. Structured outputs, versioned prompts, recorded provider and model metadata per result, contract-violation detection, and an evaluation harness with seed prompts, adversarial fixtures, run comparison, and classification of findings — with roughly seventy recorded evaluation artifacts to compare against. You cannot tell whether a prompt change helped without something to diff it against.

How it was actually built

This is the part that generalizes, and it is the reason this project is on this page.

SceneFiend was built by one person, on an AI-native workflow, at a pace I would otherwise associate with a funded early team running product, engineering, QA, documentation, infrastructure, and release planning in parallel. Just over a thousand commits have landed on the main branch since March 2026, referencing more than six hundred distinct tracked issues, against a documentation set of some 488 markdown files that is treated as part of the build rather than a write-up after it.

That pace comes from a purpose-built harness for unattended multi-agent work, not from typing faster:

• One git worktree per lane, with disjoint path ownership declared up front. A lane that needs a new path gets it added before the run starts, rather than explaining the collision afterward.
• A fresh agent invocation per issue, so no single session accumulates the context rot that makes long autonomous runs go strange around hour three.
• Validation owned per issue and again per lane, with file locks around the expensive shared commands so parallel lanes cannot trample each other's builds.
• Branch pushes and draft pull requests — never direct pushes to main. Overnight work arrives as reviewable proposals.
• Sentinel pause files and a supervisor, so a degrading run stops itself instead of producing eight hours of confident damage.
• A planner that reconciles the issue tracker against the lane configuration before a large run, and reports what is unqueued, blocked, or already covered by work in flight.

The honest summary of the leverage: agents are very good at producing volume and indifferent to whether the volume is correct. Everything above exists to convert that into throughput — isolation so parallel work cannot collide, validation gates so nothing lands unverified, and a review surface so a person still says yes. Take the harness away and the same tools produce a large, plausible, unusable mess.

What made the speed safe to trust

Moving this fast is only defensible if the record is good enough that someone else could audit it.

Tested like something strangers will use. More than 7,500 unit and logic tests across roughly 680 files, plus about 120 Playwright end-to-end browser tests, with lint, build, and typecheck run as a gate rather than a habit.

A written record of why, not only what. An append-only decisions log, a blockers register that names what is stuck without stopping unrelated work, a definition of done, route and component ownership maps, and periodic audits — including a contradiction register whose entire job is catching documents that no longer agree with the code. Where a document and the running system disagree, the code wins and the document gets fixed in the same pass.

Infrastructure changed under gates. The move off the original hosted backend onto Postgres and an auth stack with better cost and portability characteristics was run as a branch-isolated program through seventeen QA gates, with rollback criteria written before the work started and production cutover explicitly held back until the last gates clear. The interesting discipline there is the not merging — a migration that passes fifteen of seventeen gates is not done, and calling it done is how a team inherits a silent outage.

Compliance built in early. Versioned terms and privacy acceptance, account data export, email preferences reachable by capability token without an account, opt-in analytics, and a documented security audit. These are cheap to build early and miserable to retrofit during somebody's review.

The venture work

The software is half the job. The other half is deciding what is worth building and when to hold the line.

A corpus strategy, not a scraping plan. The recommendation engine works over three deliberate knowledge layers — a curated corpus with verified metadata, a structured representation of acting traditions and how each one talks about text, and a progressively built actor profile. The middle layer is the one a competitor cannot buy: it is domain expertise about how ten different training lineages describe the same work, and it exists because the founder is a working actor, not because it was scraped.

Content policy written before publication, and allowed to constrain the product. The public library is metadata-only by decision. That is a smaller, slower, less impressive product than a full-text database, and it is the version that can still be operating in three years.

A beta posture chosen on purpose. Waitlist, a cohort cap, no pricing displayed, and a public landing page that stays indexable while access opens carefully. Pricing and packaging are named as decisions ahead of the first priced conversation rather than guessed at now. The point of a small beta is to learn what is worth charging for before charging for it.

Segment work done as analysis, not enthusiasm. Candidate markets — acting studios, class cohorts, workshop coordinators — get evaluated against what the application actually is today, including an explicit list of what not to build for each one. A segment evaluation that ends in "not yet, and here is the sequence that would change that" is worth more than one that ends in a roadmap.

What this demonstrates

On the application side: a complete consumer product with authentication, personalization, structured model output grounded in a controlled corpus, a rights model enforced in code, a kill switch, an editorial operations layer, evaluation infrastructure, cost ceilings, and a release path — built, deployed, and running.

On the venture side: a position specific enough to constrain the architecture, a content policy that limits the product on purpose, gates that decide when to widen access, and a written record someone else could audit.

And on the question everyone is actually asking about AI-assisted development: it is real, it is large, and it is entirely dependent on the scaffolding around it. The speed came from isolation, validation, and review discipline — from building the factory, not from trusting the output. A founder with a sharp domain insight no longer has to choose between a shallow no-code mockup and a twelve-month engineering build. What they still need is someone who will make the unglamorous decisions — rights, evaluation, cost, gates — while the thing is being built, rather than after it is too late to change them.