wirte a very long promot for me okay lik Write an ...

Question

wirte a very long promot for me okay lik Write an extremely long, exhaustive, deeply detailed technical guide on buidl afills aceld app very long pls

Answer 1

Sure — here’s a polished, very long prompt you can paste into an AI. I’m interpreting “afills aceld app” as a placeholder/app name, so the prompt tells the AI to define unclear requirements rather than silently guessing.

:::writing{variant="document" id="58321"}

MASTER PROMPT — EXTREMELY COMPREHENSIVE TECHNICAL GUIDE FOR BUILDING A PRODUCTION-READY APPLICATION

Act as a world-class principal software engineer, solutions architect, product engineer, UI/UX designer, database architect, DevOps engineer, cloud architect, security engineer, QA engineer, technical writer, and engineering mentor.

Your task is to write an extremely long, exhaustive, deeply technical, practical, production-oriented, step-by-step guide for designing, building, testing, deploying, securing, monitoring, scaling, and maintaining a complete application called “[APP NAME]”.

Do not produce a short tutorial, superficial overview, generic checklist, or simplified proof of concept. Treat this as if you are writing the definitive engineering handbook that a serious development team could use to take the application from an initial idea all the way to a secure production deployment.

The final guide should be comprehensive enough that a competent developer can understand not only what to build, but also:

why each architectural decision is being made;
how all components communicate;
what alternatives exist;
what tradeoffs those alternatives introduce;
how the code should be organized;
how data should be modeled;
how authentication and authorization should work;
how the frontend and backend should communicate;
how failures and edge cases should be handled;
how security should be implemented;
how the application should be tested;
how it should be deployed;
how production should be monitored;
how performance bottlenecks should be diagnosed;
how the architecture should evolve as usage increases;
how technical debt should be managed;
and how another engineering team could maintain the system years later.

1. FIRST UNDERSTAND AND DEFINE THE PRODUCT

Begin by clearly defining what “[APP NAME]” is.

If the description provided by the user is incomplete, ambiguous, misspelled, or technically unclear, do not silently invent critical requirements. Instead, explicitly identify your assumptions.

Create a section called:

Product Definition and Assumptions

Explain:

What the application appears to be.
The primary problem it solves.
The intended users.
The major user personas.
The primary user journeys.
The core value proposition.
The minimum viable product.
Features that should be postponed until after MVP.
Possible future features.
Business requirements.
Functional requirements.
Non-functional requirements.
Performance requirements.
Security requirements.
Reliability requirements.
Availability expectations.
Accessibility requirements.
Privacy considerations.
Data-retention considerations.
Potential compliance requirements.

Create an explicit assumptions table containing:

Assumption	Reason	Risk if Incorrect	How to Validate

Separate confirmed requirements from assumptions.

Never pretend an assumption is a confirmed fact.

2. DEFINE THE USER EXPERIENCE

Describe every major user journey.

For each journey, explain:

starting state;
user objective;
screens involved;
actions available;
validation;
loading states;
success states;
empty states;
partial-success states;
error states;
authorization failures;
network failures;
session expiration;
retry behavior;
destructive actions;
confirmations;
accessibility behavior;
mobile behavior;
desktop behavior.

Provide detailed flows such as:

Visitor → Landing Page → Sign Up → Verification → Onboarding → Dashboard → Core Action → Confirmation → History

and:

Existing User → Sign In → Dashboard → Feature → API Request → Processing → Result → Persistence → Notification

Include alternate and failure paths.

3. REQUIREMENTS SPECIFICATION

Create a formal requirements specification.

Divide requirements into:

Functional Requirements

Use identifiers such as:

FR-001
FR-002
FR-003

For every requirement provide:

description;
priority;
dependencies;
acceptance criteria;
expected user behavior;
expected system behavior;
failure behavior.

Non-Functional Requirements

Use identifiers such as:

NFR-001
NFR-002

Cover:

performance;
scalability;
reliability;
maintainability;
observability;
security;
privacy;
accessibility;
portability;
testability;
disaster recovery.

4. TECHNOLOGY STACK

Recommend a complete modern technology stack.

Discuss appropriate options for:

Frontend

Consider technologies such as:

React;
Next.js;
TypeScript;
modern CSS;
Tailwind CSS where appropriate;
component libraries;
state management;
server state management;
forms;
validation;
accessibility tooling.

Explain exactly why the selected frontend stack is appropriate.

Backend

Evaluate suitable technologies such as:

Node.js;
TypeScript;
NestJS;
Express;
Fastify;
Next.js server capabilities;
Python;
FastAPI;
Django;
Go;
other reasonable alternatives.

Select one primary approach and explain the reasoning.

Database

Compare appropriate database technologies such as:

PostgreSQL;
MySQL;
SQLite;
MongoDB;
Redis;
document databases;
key-value databases.

Explain why the recommended primary database matches the application's access patterns.

Infrastructure

Discuss:

hosting;
containers;
Docker;
managed databases;
object storage;
CDNs;
DNS;
reverse proxies;
load balancers;
serverless platforms;
traditional servers;
container orchestration;
cloud services.

Do not select technology merely because it is popular.

For every major technology decision include:

Chosen option
Why it fits
Alternatives considered
Advantages
Disadvantages
When the decision should be reconsidered

5. HIGH-LEVEL SYSTEM ARCHITECTURE

Explain the architecture from the highest level first.

Include a textual architecture diagram similar to:

User
↓
Browser / Mobile Client
↓
CDN / Edge
↓
Frontend
↓
API Layer
↓
Authentication / Authorization
↓
Business Logic
↓
Database / Cache / Queue / Object Storage
↓
External Services

Then describe every component individually.

Explain:

responsibilities;
boundaries;
dependencies;
communication protocols;
synchronous operations;
asynchronous operations;
failure boundaries;
scaling characteristics.

Discuss whether the application should begin as:

a modular monolith;
traditional monolith;
serverless application;
service-oriented architecture;
microservices architecture.

Avoid recommending microservices merely for sophistication.

Explain when splitting services becomes justified.

6. REQUEST LIFECYCLE

Pick several important user actions and trace them from beginning to end.

For example:

User clicks “Create”
→ frontend validates input
→ frontend constructs request
→ authentication credentials are attached
→ request reaches API
→ middleware runs
→ authentication is verified
→ authorization is evaluated
→ payload is validated
→ business logic executes
→ transaction begins
→ database is modified
→ side effects are scheduled
→ transaction commits
→ response is created
→ frontend receives response
→ local/server state is updated
→ UI displays success

Explain what happens when every major stage fails.

7. PROJECT STRUCTURE

Provide a complete recommended repository structure.

For example:

/apps
/packages
/frontend
/backend
/components
/features
/hooks
/lib
/services
/api
/database
/migrations
/tests
/scripts
/config
/public
/docs
/infrastructure
/.github

Adapt the structure to the selected stack.

Explain the responsibility of every major directory.

Explain:

where business logic belongs;
where database queries belong;
where API controllers belong;
where validation belongs;
where shared types belong;
where UI components belong;
where feature-specific components belong;
where tests belong;
where configuration belongs.

Include naming conventions.

8. DEVELOPMENT ENVIRONMENT

Explain exactly how to set up development from a clean computer.

Cover:

runtime installation;
package manager;
Git;
repository initialization;
environment variables;
local database;
Docker if appropriate;
dependency installation;
development server;
database migrations;
database seeds;
test execution;
linting;
formatting;
type checking.

Show example commands.

Explain what every command accomplishes.

Provide:

.env.example

but NEVER place real secrets inside examples.

Explain which values are public and which must remain secret.

9. DATABASE DESIGN

Create a detailed relational data model.

Identify all major entities.

For every table provide:

table name;
purpose;
columns;
data types;
primary key;
foreign keys;
unique constraints;
nullability;
defaults;
indexes;
timestamps;
deletion strategy.

Explain relationships.

Include examples such as:

users
accounts
sessions
profiles
organizations
memberships
projects
items
activity_logs
notifications

but adapt them to the actual application.

Provide example SQL or ORM schemas.

Explain why each relationship exists.

10. DATABASE INDEXING

Do not merely say “add indexes.”

Explain:

primary indexes;
unique indexes;
foreign-key indexes;
composite indexes;
partial indexes where appropriate;
sorting indexes;
search indexes.

For important queries, show which index supports the query.

Explain how over-indexing increases storage and write cost.

Explain how to inspect query plans.

Discuss:

EXPLAIN
EXPLAIN ANALYZE

and how to identify:

sequential scans;
expensive joins;
poor selectivity;
unnecessary sorting;
missing indexes.

11. DATABASE MIGRATIONS

Explain a safe migration strategy.

Cover:

development migrations;
staging migrations;
production migrations;
rollbacks;
backward-compatible schema changes;
large-table migrations;
adding non-null columns;
removing columns safely;
renaming fields;
data backfills.

Explain expand-and-contract migrations.

Explain why production schema changes must be treated carefully.

12. TRANSACTIONS AND DATA CONSISTENCY

Identify operations requiring transactions.

Explain:

atomicity;
consistency;
isolation;
durability;
transaction boundaries;
rollback behavior;
race conditions;
optimistic concurrency;
pessimistic locking;
deadlocks.

Provide realistic examples.

Discuss idempotency for operations that may be retried.

13. API DESIGN

Design the complete API.

If REST is selected, define conventions for:

GET
POST
PUT
PATCH
DELETE

For each endpoint provide:

route;
method;
authentication requirements;
authorization requirements;
path parameters;
query parameters;
request schema;
response schema;
status codes;
errors;
pagination behavior;
rate limits where relevant.

For example:

POST /api/v1/items

Request:

json
{
  "name": "Example"
}

Response:

json
{
  "id": "generated-id",
  "name": "Example",
  "createdAt": "timestamp"
}

Explain why the API is designed this way.

14. API VERSIONING

Explain:

whether versioning is necessary initially;
URL versioning;
header versioning;
backward compatibility;
deprecation;
migration strategies.

15. VALIDATION

Explain validation at multiple boundaries.

Cover:

client-side validation;
server-side validation;
database constraints.

Make clear that client-side validation improves UX but cannot be trusted for security.

Show schemas using the chosen validation library.

Cover:

strings;
numbers;
emails;
URLs;
dates;
enums;
nested structures;
arrays;
optional fields;
file uploads.

Explain normalization and sanitization where appropriate.

16. AUTHENTICATION

Design authentication carefully.

Compare:

session cookies;
JWTs;
OAuth;
OpenID Connect;
passwordless authentication;
magic links;
social login.

Choose an approach based on the application.

Explain the complete login flow.

Cover:

registration;
email verification;
login;
logout;
session creation;
session validation;
session expiration;
session revocation;
password reset;
account recovery;
changing email;
changing password.

17. PASSWORD SECURITY

If passwords are used, explain:

secure hashing;
Argon2id or another appropriate password hashing algorithm;
salts;
password policies;
breached-password considerations;
brute-force protection;
reset tokens.

Never store plaintext passwords.

Never log passwords.

Never send passwords back to clients.

18. COOKIE SECURITY

If cookie-based sessions are used, explain:

HttpOnly;
Secure;
SameSite;
expiration;
domain;
path;
rotation;
CSRF implications.

19. AUTHORIZATION

Clearly distinguish authentication from authorization.

Design roles and permissions.

Possible examples:

Owner
Administrator
Manager
Member
Viewer

Create a permission matrix.

Explain:

role-based access control;
resource ownership;
organization membership;
server-side enforcement;
object-level authorization.

Never rely on hiding a button in the frontend as an authorization mechanism.

Provide examples of secure permission checks.

20. MULTI-TENANCY

If applicable, explain how organizations/workspaces/accounts are isolated.

Cover:

tenant identifiers;
database filtering;
membership;
authorization;
cross-tenant data leakage;
unique constraints;
testing tenant isolation.

Explain the risks of forgetting tenant filters.

21. FRONTEND ARCHITECTURE

Explain frontend architecture deeply.

Cover:

routing;
layouts;
pages;
reusable components;
feature modules;
server components if applicable;
client components;
hooks;
utilities;
state;
forms;
API clients;
error boundaries;
loading states;
suspense where appropriate.

Explain what belongs on the server versus client.

22. COMPONENT DESIGN

Define component categories:

primitives;
reusable UI components;
layout components;
domain components;
page components.

Explain component APIs.

Discuss:

props;
composition;
accessibility;
reusability;
avoiding enormous components;
avoiding premature abstraction.

Provide realistic component examples.

23. DESIGN SYSTEM

Create a lightweight design system.

Define:

typography;
spacing;
border radius;
shadows;
icons;
form controls;
buttons;
cards;
dialogs;
navigation;
alerts;
tables;
badges;
dropdowns;
tooltips;
skeleton loaders;
empty states.

Explain consistent design tokens.

24. RESPONSIVE DESIGN

Explain layouts for:

mobile;
tablet;
laptop;
desktop;
wide screens.

Discuss touch targets, navigation changes, tables on small screens, responsive forms, dialogs, sidebars, and dashboards.

25. ACCESSIBILITY

Target WCAG 2.2 AA where appropriate.

Cover:

semantic HTML;
keyboard navigation;
focus management;
labels;
ARIA;
contrast;
screen readers;
reduced motion;
error messages;
dialogs;
menus;
forms.

Explain common accessibility mistakes.

26. FORMS

Explain robust form architecture.

Cover:

initial state;
validation;
touched state;
dirty state;
submitting state;
success state;
field-level errors;
form-level errors;
server validation;
optimistic updates;
duplicate submissions.

Show implementation examples.

27. STATE MANAGEMENT

Separate:

local UI state;
global client state;
server state;
URL state;
persisted state.

Explain when each belongs where.

Avoid putting everything in global state.

Explain caching and invalidation.

28. ERROR HANDLING

Create a unified error strategy.

Define categories:

ValidationError
AuthenticationError
AuthorizationError
NotFoundError
ConflictError
RateLimitError
ExternalServiceError
InternalError

Explain:

HTTP mapping;
internal logging;
user-facing messages;
error identifiers;
retry behavior.

Never expose:

stack traces;
SQL queries;
credentials;
internal infrastructure details.

29. LOGGING

Design structured logging.

Include useful fields such as:

timestamp
level
requestId
userId
organizationId
route
method
statusCode
durationMs
errorCode

Explain what should never be logged:

passwords;
access tokens;
session tokens;
sensitive personal information unless strictly necessary;
payment details;
private secrets.

30. SECURITY THREAT MODEL

Create a dedicated threat model.

Identify:

protected assets;
actors;
trust boundaries;
entry points;
likely attack paths.

Consider:

SQL injection;
XSS;
CSRF;
SSRF;
broken access control;
insecure direct object references;
credential stuffing;
brute force;
session theft;
token leakage;
file upload attacks;
path traversal;
malicious redirects;
dependency compromise;
supply-chain attacks;
denial of service;
privilege escalation;
data leakage.

For every relevant threat explain:

Threat
Attack scenario
Impact
Likelihood
Mitigation
Testing method

31. SECRET MANAGEMENT

Explain how to manage:

database credentials;
API keys;
encryption keys;
OAuth credentials;
webhook secrets.

Never hard-code secrets.

Explain:

environment variables;
managed secret stores;
secret rotation;
least privilege;
accidental Git exposure;
scanning repositories for secrets.

32. SECURITY HEADERS

Discuss appropriate headers such as:

Content-Security-Policy;
Strict-Transport-Security;
X-Content-Type-Options;
Referrer-Policy;
Permissions-Policy.

Explain what each protects against.

33. RATE LIMITING

Explain rate limiting for:

login;
signup;
password reset;
expensive searches;
public APIs;
uploads;
sensitive actions.

Discuss:

IP-based limits;
account-based limits;
distributed limits;
burst limits;
sustained limits.

Explain limitations of IP-only rate limiting.

34. FILE UPLOADS

If uploads exist, cover:

allowed types;
maximum size;
MIME verification;
extension verification;
randomized storage names;
object storage;
signed URLs;
malware scanning where appropriate;
metadata stripping;
image processing;
authorization;
private versus public files.

Do not trust filenames or client-provided MIME types.

35. EXTERNAL INTEGRATIONS

For each external provider explain:

purpose;
API authentication;
timeouts;
retries;
rate limits;
error handling;
observability;
fallback behavior;
idempotency.

Assume external services can fail.

36. WEBHOOKS

If webhooks are used, explain:

signature verification;
timestamp verification;
replay protection;
idempotency;
asynchronous processing;
retry behavior;
event storage.

Provide pseudocode or implementation examples.

37. BACKGROUND JOBS

Identify work that should happen asynchronously.

Examples:

email;
notifications;
report generation;
media processing;
synchronization;
cleanup;
analytics.

Explain:

queues;
workers;
retries;
exponential backoff;
dead-letter queues;
job uniqueness;
idempotency.

38. CACHING

Explain where caching is appropriate.

Discuss:

browser cache;
CDN cache;
application cache;
Redis;
database query caching;
computed results.

Explain cache keys.

Explain TTL.

Explain invalidation.

Explain why cache invalidation is difficult.

Do not recommend caching everything.

39. PERFORMANCE

Create a performance plan.

Frontend:

bundle size;
code splitting;
lazy loading;
image optimization;
font loading;
caching;
rendering performance;
unnecessary rerenders.

Backend:

response latency;
connection pooling;
N+1 queries;
serialization;
expensive computations;
external API latency.

Database:

indexes;
query plans;
joins;
pagination;
locking;
connection limits.

40. PAGINATION

Compare:

offset pagination;
cursor pagination.

Explain when each should be used.

Provide implementation examples.

Explain stable sorting and deterministic cursors.

41. SEARCH

If search exists, explain progression from:

simple database search

to:

full-text search

to:

dedicated search infrastructure

only when justified.

Cover:

indexing;
ranking;
filters;
sorting;
pagination;
typo tolerance if needed.

42. REAL-TIME FUNCTIONALITY

If applicable, compare:

polling;
long polling;
Server-Sent Events;
WebSockets.

Explain connection lifecycle.

Cover:

authentication;
authorization;
reconnects;
dropped connections;
message ordering;
scaling;
fan-out.

43. EMAIL

If the application sends emails, define:

verification;
password reset;
notifications;
invitations;
transactional messages.

Discuss:

queues;
templates;
retries;
unsubscribe rules where applicable;
bounce handling;
SPF;
DKIM;
DMARC;
deliverability.

44. NOTIFICATIONS

Design:

in-app notifications;
email notifications;
optional push notifications.

Explain:

notification preferences;
read/unread status;
batching;
deduplication;
frequency control.

45. TESTING STRATEGY

Create a complete testing pyramid.

Cover:

Unit Tests

Test isolated business logic.

Integration Tests

Test:

database operations;
repositories;
API handlers;
authentication;
authorization.

End-to-End Tests

Test critical user journeys.

Security Tests

Test:

authorization boundaries;
invalid tokens;
tenant isolation;
injection;
malicious input.

Performance Tests

Explain:

baseline;
load testing;
stress testing;
soak testing.

46. TEST CASES

Write concrete test scenarios.

For each major feature include:

Happy path
Validation failure
Unauthorized request
Forbidden request
Missing resource
Duplicate operation
Network failure
Database failure
Concurrent modification
Unexpected server failure

Include representative test code.

47. TEST DATA

Explain:

factories;
fixtures;
database reset;
isolated tests;
deterministic data;
seed data.

Never use real sensitive production data casually in development or tests.

48. CODE QUALITY

Configure:

TypeScript strictness if using TypeScript;
ESLint;
formatting;
pre-commit checks;
linting;
tests;
type checking.

Explain why each exists.

49. GIT WORKFLOW

Describe a practical Git strategy.

Cover:

branches;
pull requests;
commits;
code reviews;
merge strategy;
release tags;
hotfixes.

Provide examples of strong commit messages.

50. CODE REVIEW

Create a review checklist covering:

correctness;
architecture;
readability;
tests;
security;
authorization;
performance;
migrations;
accessibility;
logging;
backwards compatibility.

51. CI PIPELINE

Design continuous integration.

Example stages:

Install
→ Lint
→ Type Check
→ Unit Tests
→ Integration Tests
→ Build
→ Security Checks
→ Artifact Creation

Provide a realistic CI configuration.

Explain caching and reproducibility.

52. CD PIPELINE

Explain deployment automation.

Describe:

Commit
→ Pull Request
→ CI
→ Merge
→ Build
→ Staging
→ Validation
→ Production

Explain:

deployment approvals;
rollback;
migration order;
environment configuration;
smoke tests.

53. DOCKER

If appropriate, provide:

Dockerfile;
.dockerignore;
development configuration;
production configuration.

Explain:

multi-stage builds;
image size;
non-root users;
dependency caching;
health checks.

54. ENVIRONMENTS

Define:

Development
Testing
Preview
Staging
Production

Explain differences between them.

Keep configuration differences explicit.

Avoid making staging unnecessarily different from production.

55. DEPLOYMENT

Provide a complete deployment walkthrough.

Explain:

Infrastructure creation.
Database provisioning.
Environment configuration.
Secret configuration.
Application build.
Migration execution.
Application deployment.
DNS.
TLS.
Health verification.
Smoke testing.
Monitoring.

56. DNS AND HTTPS

Explain:

domains;
DNS records;
certificates;
TLS;
redirects;
canonical domains;
CDN configuration.

Require HTTPS in production.

57. HEALTH CHECKS

Design endpoints such as:

/health

/ready

Explain the difference between:

liveness;
readiness.

Do not expose sensitive infrastructure details.

58. OBSERVABILITY

Design the observability stack around:

Logs

Structured event records.

Metrics

Examples:

request rate
error rate
latency
CPU
memory
database connections
queue depth
cache hit rate

Traces

Explain distributed tracing where useful.

Connect all three using request/correlation IDs.

59. MONITORING AND ALERTING

Define useful alerts.

Examples:

elevated error rate;
high p95 latency;
database connection exhaustion;
queue backlog;
failed background jobs;
low disk space;
certificate expiration;
repeated authentication failures.

Avoid alerts that generate constant noise.

Explain severity levels.

60. SERVICE LEVEL OBJECTIVES

Explain:

SLI
SLO
SLA

Provide example service objectives.

Discuss:

availability;
latency;
error rates;
error budgets.

61. BACKUPS

Create a database backup strategy.

Cover:

automated backups;
retention;
encryption;
point-in-time recovery;
restore testing;
off-site considerations.

Emphasize that an untested backup is not a reliable recovery plan.

62. DISASTER RECOVERY

Describe scenarios such as:

database corruption;
accidental deletion;
cloud-region outage;
broken deployment;
credential compromise;
external provider outage.

For each explain:

Detection
Containment
Recovery
Verification
Postmortem

Define example:

RPO
RTO

63. SCALING STRATEGY

Explain how architecture should evolve at:

100 users
1,000 users
10,000 users
100,000 users
1,000,000+ users

Do not claim exact thresholds universally apply.

Explain likely bottlenecks.

Discuss:

vertical scaling;
horizontal scaling;
load balancing;
caching;
read replicas;
connection pooling;
queues;
partitioning;
sharding;
service decomposition.

Explain when NOT to introduce complexity.

64. COST MANAGEMENT

Estimate major cost categories:

compute;
database;
storage;
bandwidth;
CDN;
email;
monitoring;
backups;
third-party APIs.

Provide strategies for keeping an MVP inexpensive without making it impossible to scale later.

65. PRIVACY

Discuss:

data minimization;
purpose limitation;
retention;
deletion;
export;
consent where appropriate;
access controls;
logging considerations.

Avoid making unsupported claims of legal compliance.

If legal compliance matters, clearly distinguish engineering guidance from legal advice.

66. ANALYTICS

Design privacy-conscious product analytics.

Define events such as:

user_signed_up
onboarding_completed
item_created
feature_used
subscription_started

For every event define:

trigger;
properties;
purpose.

Avoid collecting unnecessary sensitive information.

67. FEATURE FLAGS

Explain:

gradual rollout;
beta features;
experiments;
emergency disabling.

Explain how flags should be removed after they are no longer needed.

68. ADMIN SYSTEM

If appropriate, design an administrative interface.

Cover:

account lookup;
user management;
organization management;
support tooling;
audit trails;
feature controls.

Apply stricter authorization to administrative functions.

Never create hidden insecure “admin shortcuts.”

69. AUDIT LOGGING

For sensitive applications, define auditable events.

Examples:

role changed
member invited
member removed
account deleted
security setting changed
data exported

Store:

actor;
action;
resource;
timestamp;
relevant metadata.

Avoid storing secrets in audit records.

70. IMPLEMENTATION ROADMAP

Create a realistic implementation sequence.

Example:

Phase 0 — Discovery
Phase 1 — Repository Setup
Phase 2 — Database Foundation
Phase 3 — Authentication
Phase 4 — Core Backend
Phase 5 — Core Frontend
Phase 6 — Main Product Workflow
Phase 7 — Testing
Phase 8 — Security Hardening
Phase 9 — Deployment
Phase 10 — Monitoring
Phase 11 — Beta
Phase 12 — Production Launch

For every phase provide:

objectives;
tasks;
dependencies;
deliverables;
acceptance criteria;
major risks.

71. BUILD THE APPLICATION STEP BY STEP

This section must be particularly detailed.

Do not simply say:

“Create the frontend.”

Instead show:

Exact files to create.
Commands to run.
Dependencies to install.
Configuration to add.
Code to write.
How the code works.
How to test it.
Expected output.
Common errors.
How to debug those errors.

Progress incrementally.

At the end of each major milestone, provide a checkpoint such as:

Checkpoint: Authentication Foundation Complete

Then explain exactly what should work before continuing.

72. CODE EXAMPLES

Provide production-quality code examples.

Code should be:

typed where applicable;
readable;
modular;
secure;
validated;
error-aware;
realistic.

Avoid unexplained pseudo-code when actual code would be useful.

For every substantial example explain:

filename;
purpose;
dependencies;
inputs;
outputs;
security implications;
important design decisions.

73. DO NOT HIDE IMPORTANT IMPLEMENTATION DETAILS

Do not use phrases like:

“Implement authentication here.”

“Add database logic.”

“Configure security.”

“Set up deployment.”

without actually explaining how.

If a topic is too large to fully implement in one code listing, break it into smaller steps.

74. COMMON MISTAKES

After every major section include:

Common Mistakes

Explain mistakes a beginner or intermediate engineer may make.

Examples:

trusting frontend authorization;
storing secrets in source code;
failing to validate API payloads;
missing database indexes;
performing slow work inside HTTP requests;
logging credentials;
ignoring race conditions;
adding unnecessary microservices;
skipping backups;
failing to test restore procedures.

75. DEBUGGING GUIDE

Create a comprehensive debugging section.

Explain how to debug:

frontend rendering errors;
failed API requests;
CORS issues;
authentication failures;
authorization failures;
expired sessions;
database connection errors;
migration failures;
slow queries;
failed background jobs;
deployment failures;
environment-variable mistakes;
production-only bugs.

Teach a systematic debugging method:

Observe
→ Reproduce
→ Isolate
→ Form hypothesis
→ Test hypothesis
→ Fix
→ Verify
→ Add regression test

76. PRODUCTION READINESS CHECKLIST

Create a detailed checklist.

Include categories:

Product

[ ] Core flows complete
[ ] Error states complete
[ ] Empty states complete

Security

[ ] Authentication reviewed
[ ] Authorization reviewed
[ ] Secrets secured
[ ] Rate limits configured
[ ] Security headers configured

Database

[ ] Migrations tested
[ ] Indexes reviewed
[ ] Backups enabled
[ ] Restore tested

Reliability

[ ] Health checks configured
[ ] Timeouts configured
[ ] Retry policies reviewed

Observability

[ ] Logs available
[ ] Metrics available
[ ] Alerts configured

Testing

[ ] Unit tests passing
[ ] Integration tests passing
[ ] Critical E2E tests passing

Deployment

[ ] Production environment configured
[ ] TLS enabled
[ ] Rollback procedure documented

Expand this checklist significantly.

77. LAUNCH PLAN

Explain how to launch safely.

Possible progression:

Internal testing
→ Development environment
→ Staging
→ Private alpha
→ Limited beta
→ Gradual rollout
→ General availability

Explain what should be measured at every stage.

78. POST-LAUNCH OPERATIONS

Explain what happens after launch.

Cover:

incident response;
customer support;
bug triage;
security updates;
dependency updates;
database maintenance;
cost monitoring;
performance monitoring;
capacity planning.

79. INCIDENT RESPONSE

Define a lightweight incident process.

Cover:

Detection
→ Triage
→ Severity assignment
→ Containment
→ Mitigation
→ Recovery
→ Communication
→ Postmortem

Explain severity levels.

Explain blameless postmortems focused on improving systems and processes.

80. MAINTENANCE PLAN

Explain:

Daily tasks
Weekly tasks
Monthly tasks
Quarterly tasks

Include:

dependency updates;
security patches;
backup verification;
performance review;
access review;
cost review;
alert review;
technical debt.

81. TECHNICAL DEBT

Explain how to identify and prioritize technical debt.

Categorize debt:

architectural;
security;
testing;
documentation;
performance;
dependency;
infrastructure.

Explain when refactoring is justified.

82. DOCUMENTATION

Specify documentation the repository should contain:

README.md
ARCHITECTURE.md
CONTRIBUTING.md
SECURITY.md
DEPLOYMENT.md
RUNBOOK.md
API documentation
Database documentation

Provide example structures for each.

83. DEVELOPER ONBOARDING

Explain how a new engineer should become productive.

Create a first-day workflow:

Clone repository
→ Install dependencies
→ Configure environment
→ Start database
→ Run migrations
→ Seed data
→ Start application
→ Run tests
→ Make small change

Aim for reproducible onboarding.

84. ARCHITECTURE DECISION RECORDS

Explain ADRs.

Provide an example:

ADR-001: Select PostgreSQL

Status: Accepted

Context:
...

Decision:
...

Alternatives:
...

Consequences:
...

Use ADRs for important architectural decisions.

85. FUTURE ARCHITECTURE

Describe how the system might evolve without prematurely implementing complexity.

Discuss potential future adoption of:

Redis;
queues;
read replicas;
dedicated search;
object storage;
WebSockets;
service decomposition;
data warehouses;
analytics pipelines;
multi-region deployment.

For every technology explain the trigger that would justify adding it.

86. ALTERNATIVE ARCHITECTURES

Provide at least three reasonable architectures:

Architecture A — Simple MVP

Optimize for:

speed;
simplicity;
low operational overhead.

Architecture B — Growth Stage

Optimize for:

moderate traffic;
team collaboration;
stronger reliability.

Architecture C — Large Scale

Optimize for:

high traffic;
stronger isolation;
sophisticated infrastructure.

Compare them in a table:

Area	MVP	Growth	Large Scale
Frontend
Backend
Database
Cache
Queue
Deployment
Monitoring
Complexity
Cost

Then recommend which architecture should actually be built first.

87. TRADEOFF ANALYSIS

For every important architectural decision, explicitly discuss tradeoffs.

Examples:

REST vs GraphQL
SQL vs NoSQL
Sessions vs JWT
Monolith vs microservices
Serverless vs containers
Polling vs WebSockets
Offset vs cursor pagination
Managed services vs self-hosting

Avoid claiming one technology is universally superior.

88. SECURITY REVIEW BEFORE LAUNCH

Perform a final adversarial review.

Ask questions such as:

Can one user access another user's resource by changing an ID?

Can a normal user invoke an admin endpoint directly?

Can an attacker submit unexpected fields?

Can an attacker upload dangerous content?

Can repeated requests create duplicate transactions?

Can a leaked URL reveal private information?

Can authentication tokens appear in logs?

Can password reset links be replayed?

Can a malicious site trigger sensitive requests?

Can one tenant access another tenant's records?

Then explain mitigations.

89. PERFORMANCE REVIEW BEFORE LAUNCH

Review:

largest frontend bundles;
slowest API endpoints;
most expensive queries;
external API latency;
caching;
image sizes;
database connection usage;
background queue performance.

Provide tools and techniques for investigating each.

90. FINAL REPOSITORY EXAMPLE

At the end, show what the completed repository could look like.

For example:

text
app/
├── apps/
│   ├── web/
│   └── api/
├── packages/
│   ├── database/
│   ├── validation/
│   ├── ui/
│   └── config/
├── infrastructure/
├── scripts/
├── docs/
├── tests/
├── .github/
├── .env.example
├── package.json
└── README.md

Expand this based on the actual architecture.

91. COMPLETE USER JOURNEY TRACE

Choose the most important feature and trace it through the entire stack.

For example:

User action
→ UI component
→ form validation
→ API client
→ HTTP request
→ middleware
→ authentication
→ authorization
→ server validation
→ service layer
→ database transaction
→ database indexes
→ asynchronous events
→ response
→ cache invalidation
→ frontend state update
→ UI feedback
→ analytics
→ logs
→ metrics

Explain every stage.

92. FAILURE JOURNEY TRACE

Trace the same feature when things fail.

Consider:

invalid input;
expired authentication;
unauthorized access;
database timeout;
deadlock;
external provider outage;
worker failure;
duplicate request;
client disconnect.

Explain how the application should behave in every case.

93. “FROM ZERO TO PRODUCTION” COMMAND SEQUENCE

Finish with a concise but complete command-oriented walkthrough.

Example structure:

bash
# Create project
...

# Install dependencies
...

# Configure database
...

# Run migrations
...

# Start development
...

# Run tests
...

# Build production
...

# Deploy
...

Adapt all commands to the chosen technology stack.

Do not include fake commands that would not work with the selected tooling.

94. FINAL ENGINEERING CHECK

Conclude by answering:

What are the five most important architectural decisions?
What are the five largest security risks?
What are the five largest reliability risks?
What are the five likely performance bottlenecks?
What should absolutely be completed before launch?
What can safely wait until after launch?
What should NOT be built prematurely?
What assumptions still require validation?
What metrics indicate the application is healthy?
What signs indicate the architecture needs to evolve?

DEPTH REQUIREMENTS

The guide must be extremely detailed.

Do not artificially shorten the response.

Prefer detailed explanations over superficial statements.

For major concepts, explain:

What it is.
Why it matters.
How it works.
How it applies to this application.
How to implement it.
How to test it.
What can go wrong.
How to debug it.
Security implications.
Performance implications.
Scaling implications.
Alternatives.
Tradeoffs.

CODE REQUIREMENTS

Whenever code is provided:

identify the filename;
use consistent architecture;
use the same technology choices throughout the guide;
avoid changing frameworks halfway through;
use secure defaults;
validate untrusted input;
handle expected failures;
avoid hard-coded secrets;
use environment variables appropriately;
provide meaningful names;
explain non-obvious logic.

When modifying a previously introduced file, clearly show whether the code is:

the complete replacement file;
or only the new section being added.

Do not leave ambiguous fragments that a developer cannot place correctly.

ACCURACY REQUIREMENTS

Do not invent library APIs.

Do not claim a feature exists in a framework unless reasonably certain.

If version-specific behavior matters, explicitly state which version or version range the guide assumes.

When information could have changed recently, recommend checking the official documentation rather than presenting uncertain information as fact.

Prefer official documentation for framework-specific technical facts.

Clearly distinguish:

Confirmed behavior

from:

Recommendation

from:

Assumption

SECURITY REQUIREMENTS

Treat all user input as untrusted.

Treat the network as untrusted.

Perform authorization on the server.

Use parameterized database queries or a safe ORM.

Protect credentials.

Use HTTPS in production.

Apply least privilege.

Validate uploaded files.

Protect sensitive endpoints against abuse.

Never place secrets in client-side bundles.

Never expose private environment variables.

Never rely solely on frontend validation.

Never log passwords, tokens, or private secrets.

Never suggest disabling important security controls merely to make development easier.

ENGINEERING PHILOSOPHY

Favor:

clarity over cleverness;

simple architecture over unnecessary complexity;

managed infrastructure over unnecessary operational burden for small teams;

secure defaults over convenience;

explicit validation over assumptions;

observability over guessing;

incremental scalability over premature distributed systems;

maintainable code over impressive-looking abstractions.

Do not introduce Kubernetes, Kafka, microservices, event sourcing, CQRS, distributed databases, or similarly complex infrastructure unless there is a concrete requirement that justifies it.

When sophisticated technology might become useful later, explain the trigger for adopting it rather than immediately adding it.

TEACHING STYLE

Write as though teaching an intelligent developer who wants to understand the system deeply.

Do not assume unexplained jargon.

When introducing an important technical term, explain it.

Use:

headings;
subheadings;
tables;
diagrams;
numbered procedures;
code blocks;
configuration examples;
SQL examples;
request/response examples;
decision matrices;
checklists;
debugging notes;
warnings;
implementation checkpoints.

Use concrete examples instead of vague statements.

IMPORTANT: DO NOT GIVE ME ONLY AN OUTLINE

The final response must contain the actual technical guide.

Do NOT respond with only:

a table of contents;
an outline;
a list of topics;
a high-level architecture;
a project plan.

The table of contents should be followed by the actual detailed content.

If the complete guide is too large for a single response, divide it into logically numbered parts while maintaining continuity.

Use:

Part 1 — Product and Architecture
Part 2 — Project Setup and Database
Part 3 — Backend and APIs
Part 4 — Authentication and Security
Part 5 — Frontend and UX
Part 6 — Testing
Part 7 — Infrastructure and Deployment
Part 8 — Observability and Reliability
Part 9 — Scaling and Operations
Part 10 — Final Production Implementation

At the end of each part, state exactly where the next part should continue.

Do not restart the architecture or change technology choices between parts unless you explicitly explain why a decision changed.

INPUTS

Use the following project information:

Application name: [APP NAME]

Application idea:
[DESCRIBE THE APPLICATION]

Target users:
[DESCRIBE USERS]

Core features:
[LIST FEATURES]

Platforms:
[WEB / IOS / ANDROID / DESKTOP / OTHER]

Preferred frontend technology:
[OPTIONAL]

Preferred backend technology:
[OPTIONAL]

Preferred database:
[OPTIONAL]

Preferred hosting/cloud:
[OPTIONAL]

Authentication requirements:
[OPTIONAL]

External integrations:
[OPTIONAL]

Expected initial users:
[NUMBER]

Expected future scale:
[NUMBER]

Budget constraints:
[OPTIONAL]

Team size and experience:
[OPTIONAL]

Special security/privacy requirements:
[OPTIONAL]

Additional requirements:
[ADD ANYTHING ELSE]

If an optional input is missing, make a reasonable recommendation and clearly label it as a recommendation.

BEGIN

Now create the complete, extremely long, deeply detailed, technically rigorous zero-to-production engineering guide for “[APP NAME]”.

Begin with:

Executive Summary
Product Definition
Assumptions
Requirements
User Personas
User Journeys
Architecture
Technology Decisions
Repository Structure
Local Development Setup

Then continue through the entire implementation, security, testing, deployment, observability, scaling, disaster recovery, maintenance, and production-readiness process described above.

Do not skip difficult sections.

Do not replace implementation details with “etc.”

Do not repeatedly summarize instead of implementing.

Whenever there is a choice between a vague statement and a concrete example, prefer the concrete example.

The objective is to produce something closer to a complete engineering handbook, architecture specification, implementation tutorial, security guide, deployment manual, and production runbook combined into one document than a normal coding tutorial.

Start now. :::

Replace [APP NAME], [DESCRIBE THE APPLICATION], and the other placeholders with your actual app details before using it.

Question

Réponse

MASTER PROMPT — EXTREMELY COMPREHENSIVE TECHNICAL GUIDE FOR BUILDING A PRODUCTION-READY APPLICATION

1. FIRST UNDERSTAND AND DEFINE THE PRODUCT

Product Definition and Assumptions

2. DEFINE THE USER EXPERIENCE

3. REQUIREMENTS SPECIFICATION

Functional Requirements

Non-Functional Requirements

4. TECHNOLOGY STACK

Frontend

Backend

Database

Infrastructure

5. HIGH-LEVEL SYSTEM ARCHITECTURE

6. REQUEST LIFECYCLE

7. PROJECT STRUCTURE

8. DEVELOPMENT ENVIRONMENT

9. DATABASE DESIGN

10. DATABASE INDEXING

11. DATABASE MIGRATIONS

12. TRANSACTIONS AND DATA CONSISTENCY

13. API DESIGN

14. API VERSIONING

15. VALIDATION

16. AUTHENTICATION

17. PASSWORD SECURITY

18. COOKIE SECURITY

19. AUTHORIZATION

20. MULTI-TENANCY

21. FRONTEND ARCHITECTURE

22. COMPONENT DESIGN

23. DESIGN SYSTEM

24. RESPONSIVE DESIGN

25. ACCESSIBILITY

26. FORMS

27. STATE MANAGEMENT

28. ERROR HANDLING

29. LOGGING

30. SECURITY THREAT MODEL

31. SECRET MANAGEMENT

32. SECURITY HEADERS

33. RATE LIMITING

34. FILE UPLOADS

35. EXTERNAL INTEGRATIONS

36. WEBHOOKS

37. BACKGROUND JOBS

38. CACHING

39. PERFORMANCE

40. PAGINATION

41. SEARCH

42. REAL-TIME FUNCTIONALITY

43. EMAIL

44. NOTIFICATIONS

45. TESTING STRATEGY

Unit Tests

Integration Tests

End-to-End Tests

Security Tests

Performance Tests

46. TEST CASES

47. TEST DATA

48. CODE QUALITY

49. GIT WORKFLOW

50. CODE REVIEW

51. CI PIPELINE

52. CD PIPELINE

53. DOCKER

54. ENVIRONMENTS

55. DEPLOYMENT

56. DNS AND HTTPS

57. HEALTH CHECKS

58. OBSERVABILITY

Logs

Metrics

Traces

59. MONITORING AND ALERTING

60. SERVICE LEVEL OBJECTIVES

61. BACKUPS

62. DISASTER RECOVERY