A custom system can become important very quickly. It may hold bookings, payments, patient records, customer dues, stock, or the next job staff must handle.
That creates a second question after “Does it work?” The question is “Can the business keep control when something changes?”
Your records stay yours
The business owns the records and files supplied to or created through its system. Continued access should not depend on renewing support.
That does not mean every tool or third-party service becomes the customer's property. It means the business can receive its own records in a useful format.
Ownership should be written into the quote and handover. It should not be a promise discovered only after someone asks to leave.
An export must be usable
A screenshot is not an export. A locked report is not an export. A useful export keeps the records, dates, stable IDs, and relationships needed to understand the work.
For covered Kaiku Labs SYSTEM and APP work, the standard calls for machine-readable files such as CSV or JSON, original uploaded files, and a simple field guide.
The handover should also list what is not included. An export can preserve records without automatically importing them into a completely different product.
A backup is only a copy
Backups matter because live data can be deleted, corrupted, overwritten, or made unavailable by an account or provider problem.
The Kaiku Labs standard for covered hosted work calls for automated backup at least once every 24 hours, 30-day rolling retention, and storage separate from the live data.
This is a standard for covered projects, not a claim that every website needs a database. A static site with no customer records needs a different, smaller plan.
Recovery is the real test
A backup that has never been restored is an assumption. Before launch, covered work should pass a restore drill using the documented recovery route.
The drill should record the backup used, steps taken, time required, result, failures, and repair. A failed drill blocks launch or needs a written exception and fallback.
Kaiku Labs should say a recovery was tested successfully only when that exact project has a proof log. The standard itself is not proof of a completed restore.
Accounts and access need names
The owner should know which accounts run the domain, hosting, database, email, analytics, and payments. The right people should have access before an emergency.
Passwords should not live in a chat thread. Access should be limited to named people, and removal should be part of staff or vendor exit.
A one-page handover note should explain the system in plain words: what it does, where records live, who to contact, how to export, and what to do first when it fails.
Support must have an edge
Monthly support should state what it covers: keeping the agreed version running, fixing defects, checking backups, or making small changes.
New screens, new workflows, large migrations, and third-party charges are new work. Naming that boundary protects both the buyer and the builder.
When support ends, the exit should include a final export, required files, account handover, known issues, and a date for deletion of working copies held by Kaiku Labs.
Questions to ask before launch
Who owns the records? What can be exported? How often is it backed up? Has recovery been tested? Which accounts belong to the business? What happens when support ends?
If those answers are vague, the system is not ready for important records. They are part of the product, not paperwork added after it.
See the SYSTEM starting point → Read the build-or-buy test →