Skip to main content

Technical stack choices align with PRD constraints

ab-001547 · goal-alignment.technical-alignment.stack-aligns-with-prd-constraints
Severity: highactive

Why it matters

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.

Severity rationale

High because stack constraint violations discovered after development require partial rewrites to fix and may introduce compliance or contractual risk if the violated constraint was regulatory.

Remediation

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.

Detection

  • ID: goal-alignment.technical-alignment.stack-aligns-with-prd-constraints
  • Severity: high
  • What to look for: Enumerate every relevant item. Review the PRD for any explicit technical constraints, stack requirements, or technology preferences. Common examples: "must use PostgreSQL", "must be deployable to AWS", "must support mobile browsers", "must use the existing Node.js backend", "must not use paid third-party services", "must support offline mode". Then verify the actual detected stack against these constraints.
  • Pass criteria: At least 1 of the following conditions is met. All explicit technical constraints in the PRD are satisfied by the actual technology choices. No constraint is violated.
  • Fail criteria: One or more explicit PRD technical constraints are not satisfied. Examples: PRD required PostgreSQL but the codebase uses SQLite; PRD required self-hosted deployment but the codebase is tightly coupled to a managed platform with vendor lock-in; PRD required no paid third-party dependencies but the codebase uses commercial services.
  • Skip (N/A) when: The PRD contains no explicit technical constraints, stack requirements, or technology preferences. Signal: PRD is purely a feature/behavioral specification with no mention of technology choices.
  • Detail on fail: Name the violated constraints. Example: "PRD explicitly requires 'no external API dependencies for core features' but codebase integrates with OpenAI API for the primary search feature." Max 500 chars.
  • Remediation: Technical constraint violations are among the most costly to fix late in development. Check package.json dependencies and src/ configuration files for compliance. Assess the effort required to bring the implementation into compliance with each constraint. If a constraint is genuinely impractical to meet now, document the deviation explicitly in your project notes and evaluate whether the original constraint should be revised.

External references

Taxons

History