I build web apps on Replit and deploy to Railway via GitHub. I often rely on Claude and ChatGPT to scaffold projects. The pain point: moving a working Replit app to Railway can take dozens or even hundreds of prompts to sort out build/runtime mismatches.

Could you share a clear, AI-friendly checklist of what I should tell Claude/ChatGPT at project creation so the codebase is “Railway-ready” from day one? I’m looking for practical do’s/don’ts and an ordered handoff procedure. Specifically:

1. Project scaffolding (files/folders)

• Required or recommended files (e.g., Dockerfile vs. Railway start command, Procfile, package.json scripts, .npmrc, .env.example, railway.json if applicable).

• Files/folders to avoid because they break or complicate Railway builds (e.g., Replit-specific configs, lockfile mismatches, hidden build caches).

• Preferred package manager and lockfile policy (npm/pnpm/yarn; lockfile required?).

2. Runtime & networking

• How the app should bind the port (e.g., process.env.PORT, 0.0.0.0) and anything to avoid (hard-coded ports, host binding).

• Health checks, long-running workers, cron/scheduled jobs—recommended patterns on Railway.

• WebSockets, server-sent events, and timeouts—any limits or settings to be aware of.

3. Build environment

• Default Node/Python/other runtime versions and how to pin them (engines field vs. Docker).

• Monorepo support: how to set the service root and build/run commands per app.

• Native deps: best practice for system packages (use Docker? Nixpacks hints?).

4. Environment & secrets

• Standardize .env.example and variable naming; best way to map to Railway Variables.

• Service discovery for DB/Redis/etc. (e.g., using DATABASE_URL), and preferred migration flow (run on deploy? separate job?).

• Any pitfalls with JSON-encoded secrets or multiline certs/keys.

5. Static assets & storage

• What persists across deploys and what doesn’t (ephemeral filesystem).

• Recommended approach for uploads (object storage) and build-time asset generation.

6. OAuth & callbacks

• Best practice for Google OAuth during dev vs. production (redirect URIs, http/https, domain setup).

• Common mistakes (redirect_uri_mismatch, cookie/session settings) and how to avoid them on Railway.

7. GitHub → Railway handoff order

• The ideal step-by-step sequence when I’m ready to deploy (e.g., commit lockfile → set Railway Variables → provision DB → run migrations → set start command/health check → first deploy → verify logs/health → add custom domain → set OAuth prod callbacks).

• Any recommended preflight checks before the first deploy.

If you have a canonical template (repo or snippet) that embodies these practices, I’d love it. Even better, a short “copy-paste prompt” I can give to Claude/ChatGPT to scaffold a Railway-compatible project (Node/Express + Vite as a common case) would save a lot of trial and error.