Build your own app directory.

Build an app directory inspired by How To Vibecode It. Use your own name, design assets and researched entries. This is a staged implementation specification, not a promise to reproduce this service or its private dataset in one attempt.

1. Scope and setup
Inspect the repository first. Use Next.js App Router, React and a PostgreSQL database for accounts, submissions and votes. Keep reviewed catalogue entries in data/apps/*.json. Use a supported Node.js runtime and one package manager. Document actual setup commands, environment variables and numbered migrations. Keep provider secrets on the server. Start with three clearly labelled example entries; do not invent a large catalogue, traffic or testimonials.

2. Content model
Each app needs a stable slug, name, domain, category, factual tagline, verdict (yes, kinda, no), verdict summary, prerequisites, limited DIY scope, estimate, lost capabilities, why people still pay, researched alternatives and dated pricing sources. Implementation guidance belongs in prompt, skills.stack/security/marketing/agentSkills string arrays, and proInstructions. Preserve that shape when importing an existing catalogue. Keep build verification separate from an editorial feasibility verdict.

3. Useful first slice
Server-render a searchable, keyboard-accessible list and one complete detail page. Readers should understand the workflow, replacement limits and ongoing costs before copying anything. Detail pages need a scoped prompt, phased roadmap, relevant skill references, copy buttons and an AGENTS.md download generated from the same fields. Link skill sources by HTTPS and treat their contents as optional external instructions. Do not claim that a skill installs dependencies or grants API access.

4. Accounts, suggestions and moderation
Use an established authentication library configured for the chosen hosting environment. Add a submission form that accepts ordinary fields or valid catalogue JSON. Suggestions stay pending until an authorized administrator reviews them. Persist votes with explicit uniqueness rules and transactional updates. Enforce server-side authorization, input bounds, safe redirects and origin checks. Implement rate limiting at the deployment boundary. Avoid claiming that a visitor counter proves someone built an app.

5. Search and answer visibility
Give each indexable page a descriptive H1, unique title and summary, self-canonical HTTPS URL and useful internal links. Render actual guide text and links on the server. Add truthful WebSite, Organization, WebPage, ItemList and BreadcrumbList structured data where appropriate. Never invent review stars, author credentials, dates or unsupported actions. Keep structured answers consistent with visible text; no rich-result guarantee. Publish a sitemap of public canonical pages and robots.txt. Use noindex for private/utility/filtered duplicates and authentication for private records. Exclude downloads and pending entries from the sitemap.

6. Honest presentation
Use responsive cards, readable typography, visible focus states and reduced-motion support. Show only real counts from stored data, explain what a vote means, and label source/verification dates. If displaying sponsorships, mark paid links appropriately and separate promotion from editorial verdicts. Do not copy this site's commercial terms, competition or prize promises into a new product by default.

7. Delivery sequence and acceptance
First complete listing to guide to copy/download without authentication. Then add database migrations, sign-in, pending submissions, moderation and voting. Demonstrate invalid JSON errors, duplicate voting, cross-account access rejection, rejected submissions, expired sessions, database failure and export/restore. Check narrow and wide layouts, keyboard navigation, empty states and source-visible content. Record checks actually performed, unresolved issues and setup the owner still needs. Ask for authorization before deployment, paid services or sending messages.

The directory's source repository and dataset are private. This prompt describes an approach for your own project; it does not grant access to or relicense those materials.