Technical stack choices align with PRD constraints

Technical constraint violations discovered late are among the most expensive defects to fix. If your PRD required PostgreSQL for compliance reasons and the AI chose SQLite, or if it required a self-hosted deployment and the codebase is locked to a managed platform, you face a rewrite — not a refactor. Vendor lock-in violations against explicit PRD constraints can also carry legal and contractual consequences, particularly in enterprise or regulated environments. ISO 25010:2011 portability measures exactly this: whether the system operates within its specified technical environment.

Review your package.json and deployment configuration files against each explicit PRD constraint. For database violations, check prisma/schema.prisma or drizzle.config.ts for the provider:

// prisma/schema.prisma
datasource db {
  provider = "postgresql" // Verify this matches your PRD constraint
  url      = env("DATABASE_URL")
}

For deployment constraints, inspect vercel.json, Dockerfile, or fly.toml for managed-service dependencies. If a constraint genuinely cannot be met with the current implementation, document the deviation explicitly in your project notes and get explicit sign-off before proceeding — do not silently violate a PRD constraint.