Who owns the code, and what happens after go-live?
Ownership and support boundaries should be written—vague promises create lock-in risk.
Custom work should clarify source access, documentation, environments, domains, and database backups. “We paid, so everything is ours” is not always automatic for third-party libraries, hosting accounts, or vendor tooling. Delivery checklists belong in the agreement.
After go-live, separate tracks help: defect fixes (warranty/maintenance), small improvements, and new feature phases. Mixing them into “unlimited free support” creates conflict. Response channels and what is in/out of maintenance are defined per engagement—not as a universal guarantee on this page.
If your team will run it, handover and access matter as much as features. If a partner continues, capacity-based retainers are one common model—not the only one.
We prefer clear information up front over hard promises that ignore your context. Details are set for your project in the proposal and contract.
