API versioning strategy defined

Adding versioning after external consumers exist is extremely expensive: every client integration must be migrated simultaneously or you must maintain two incompatible surfaces indefinitely. Without a versioning strategy, the first breaking change — adding a required field, renaming a resource, changing a status code — breaks all callers with no migration path. ISO-25010:2011 maintainability.modifiability and compatibility.interoperability are both undermined: the API cannot evolve without breaking the contract.

Add a /v1/ prefix to all API routes now, before you have external consumers. In Next.js App Router this is a directory move:

app/api/v1/users/route.ts
app/api/v1/billing/route.ts

Update all same-repo fetch calls to use the versioned paths. Document the versioning scheme in your README: one paragraph naming the strategy (URL versioning), the current version, and what triggers a version bump (breaking changes). When a v2 becomes necessary, serve v1 from the old directory during a documented deprecation window. The cost of adding this prefix now is one rename operation; the cost of adding it later is a coordinated migration across every consumer.