From Database Schema to Production Deploy: Backend Prompts That Let You Ship Without a Tech Lead
A solo developer building a backend has a specific kind of problem: there is no one to review the schema design at 11 p.m., no one to catch the missing --no-cache-dir in the Dockerfile, no one to ask whether the N+1 query will hurt at 10k rows. The tech lead is you, and you are tired.
This roundup is a working set of prompts for exactly that situation. Not "generate a CRUD app" fluff, but prompts that produce artifacts you can actually deploy: migrations, connection pooling configs, health checks, CI pipelines, and rollback plans. The focus is on three stacks — FastAPI, Django, and Node.js — and the goal is to move from a database schema to a production deploy with as few blind spots as possible.
Each prompt below follows the same shape: what it is for, why it works, and a ready-to-paste example. Treat them as a checklist, not a magic wand — you still review the output, but you review it like a senior engineer would, with a concrete list of things to verify.
1. Schema-first design: turn a feature description into a normalized schema
For: the very first step, before any framework code exists.
Why it works: LLMs are strong at relational modeling when you force constraints and normalization rules explicitly. Without them, you get a flat table with a data JSONB column and a prayer.
You are a senior database engineer. Design a PostgreSQL schema for: [feature].
Rules:
- 3NF unless you justify denormalization in a comment
- every FK gets an ON DELETE policy and an index
- timestamps as timestamptz, never timestamp
- money as numeric(12,2), never float
- list every unique constraint and explain the business rule behind it
Output: DDL + a short table of indexes with the query each index serves.
Check on review: that ON DELETE policies match your domain (a CASCADE on users is almost always a bug), and that every index has a named query behind it — indexes without queries are just write overhead.
2. Migration review: catch the destructive change before it ships
For: any Alembic or Django migration generated automatically.
Why it works: auto-generated migrations are the single most common source of production incidents for solo devs — a DROP COLUMN on a table with live traffic does not care that you were in a hurry.
Here is a migration file: [paste]. Review it for production safety.
For each operation report: locks taken, estimated duration on a 1M-row table,
and whether it is reversible.
Flag: column drops, type changes, NOT NULL additions without defaults,
and index creation without CONCURRENTLY.
Suggest a zero-downtime alternative for each flagged item.
Example finding: ALTER TABLE ... ADD COLUMN x int NOT NULL rewrites the table and takes an ACCESS EXCLUSIVE lock. The safe pattern is: add nullable, backfill in batches, then add the constraint with NOT VALID and VALIDATE CONSTRAINT.
3. FastAPI dependency graph audit
For: FastAPI projects where Depends() chains have grown past two levels.
Why it works: FastAPI resolves dependencies per request, and a poorly structured graph means your DB session opens three times per call. Asking the model to draw the graph exposes it.
Here are my FastAPI dependencies: [paste].
1. Draw the dependency tree per endpoint as an indented list.
2. Mark any dependency instantiated more than once per request.
3. Show which are sync (run in threadpool) vs async.
4. Rewrite the graph so the DB session is created once and injected.
Result to expect: a flattened graph with a single get_db at the top and yield-based cleanup — the pattern documented in FastAPI's official dependencies guide.
4. Async safety check for FastAPI handlers
For: the classic bug where an async def handler calls a blocking library and stalls the whole event loop.
Review these handlers for blocking calls inside async functions: [paste].
Flag: requests, time.sleep, sync ORM calls, file I/O, and CPU-heavy loops.
For each, give the fix: await an async client, run_in_threadpool, or a background task.
Why it matters: one blocking requests.get() in an async route can serialize your entire service under load. This prompt catches it before your first traffic spike does.
5. Django ORM: find the N+1 before the query log does
For: Django views and serializers that look fine and perform terribly.
Here are my models and a view: [paste].
Identify every N+1 query. For each, show the ORM call that causes it
and the fix using select_related / prefetch_related / Prefetch with to_attr.
Then estimate query count for a list of 100 objects before and after.
Check: select_related for FK and one-to-one, prefetch_related for many-to-many and reverse FK — mixing them up is a common mistake that silently keeps the N+1.
6. Django settings split for environments
For: projects still running one settings.py with DEBUG = True somewhere in git history.
Split this settings file into base / dev / prod: [paste].
Prod must: read secrets from env, set DEBUG=False, configure ALLOWED_HOSTS,
SECURE_* headers, and logging to stdout.
List every setting whose default is unsafe in production.
Verify against: Django's official deployment checklist — it is short and covers exactly these items.
7. Node.js: connection pool sizing for Postgres
For: Express or Fastify services using pg or an ORM.
My service runs [N] instances, each with pool max [M], against Postgres max_connections=[C].
1. Is the pool math safe? Show the formula.
2. Recommend pool size per instance and idleTimeoutMillis.
3. Explain what happens under a traffic spike with the current numbers.
Rule of thumb to sanity-check the answer: total connections across all instances must stay well under max_connections, leaving headroom for migrations and admin sessions.
8. Node.js: graceful shutdown that actually drains
For: containers that get SIGTERM and drop in-flight requests.
Write a graceful shutdown handler for this Node service: [paste].
Requirements: stop accepting new connections, wait for in-flight requests,
close DB pool, exit after a timeout. Include the Kubernetes-relevant signals.
Why: Kubernetes sends SIGTERM, waits terminationGracePeriodSeconds, then SIGKILL. If your handler does not finish inside that window, requests die mid-flight.
9. Dockerfile review for all three stacks
For: before the first deploy and before every dependency bump.
Review this Dockerfile: [paste]. Check: multi-stage build, non-root user,
pinned base image digest, layer order for cache efficiency,
and whether dev dependencies leak into the final image.
Suggest a smaller final image and show the size-relevant changes.
Common win: copying package.json and running install before copying source, so dependency layers cache across code changes.
10. Health and readiness endpoints
For: any service behind a load balancer or orchestrator.
Design /health (liveness) and /ready (readiness) for this service: [stack, deps].
Liveness must not check the DB. Readiness must check DB and downstream deps
with a short timeout. Show the handler code and the failure behavior for each.
Why the split matters: a liveness probe that pings the database will restart your app every time the DB blips — turning a small outage into a restart loop.
11. CI pipeline from zero
For: repos with no automation beyond "it works on my machine".
Write a GitHub Actions workflow for a [FastAPI/Django/Node] project:
lint, type-check, tests against a Postgres service container, build image,
push to registry on main. Cache dependencies. Fail fast on lint.
Verify: that the service container is reachable on localhost with the right env vars — this is the step that most first attempts get wrong.
12. Reverse proxy and TLS config
For: the gap between "container runs" and "users can reach it over HTTPS".
Write an nginx config that proxies to this app: [port, stack].
Include: TLS termination, HTTP->HTTPS redirect, gzip, client_max_body_size,
proxy timeouts, and forwarded headers for the framework to read the real client IP.
Check: for FastAPI/uvicorn use --proxy-headers and --forwarded-allow-ips; for Django set SECURE_PROXY_SSL_HEADER; for Express set trust proxy — otherwise rate limiting keys on the proxy IP.
13. Secrets and environment audit
For: the pre-deploy paranoia pass.
List every secret this project needs based on these files: [paste configs].
For each: where it should live in prod (env, secret manager), rotation approach,
and what breaks if it leaks. Flag any hardcoded value.
Why: an env-var inventory is also your deploy checklist — if a variable is not in the list, the container will start and fail on first request instead of at boot.
14. Rollback plan generation
For: the step everyone skips until the first bad deploy.
Given this deploy (migration + app version), write a rollback plan.
Cover: DB migration reversibility, feature-flag kill switch,
image rollback command, and the order of operations.
Flag any step that is one-way.
Takeaway: irreversible migrations are fine — as long as you know in advance that the rollback is forward-only and write the compensating migration before you need it.
15. Post-deploy smoke test checklist
For: the first ten minutes after release.
Generate a smoke test checklist for this service: [endpoints, deps].
Order by blast radius: auth, core write path, read path, background jobs.
For each check: the exact request, expected status, and what failure means.
Result: a repeatable ten-minute ritual that turns "it seems fine" into evidence.
What this actually changes
The pattern across all fifteen prompts is the same: you are not asking the model to be your tech lead. You are asking it to be the reviewer who never gets tired — the one who asks about lock duration, pool math, and ON DELETE policies every single time. The expertise stays with you; the model just refuses to let you skip the checklist.
Start with prompts 1, 2, and 9. Schema, migrations, and the Dockerfile are where solo projects fail hardest and where review pays off fastest. The rest you add as the project grows. If you want to go deeper into prompt patterns for engineering work, the asibiont.com/blog archive has more roundups on backend and infrastructure workflows.
Comments