"We are done when it works" sounds reasonable until three people define "works" differently — and launch day becomes an argument in group chat.
For custom web products serving Philippine SMEs, done must be written down before go-live: acceptance criteria, rollback triggers, and who owns what after deployment. Without that, you either never ship or ship something nobody supports.
Done is not "no bugs anywhere"
Perfect software does not exist. Done means agreed critical paths are solid for the business risk you are taking — payments, bookings, data integrity, permissions — with known minor issues logged and scheduled.
Define done in tiers:
- Launch blockers — must pass or you do not go live
- Launch with workaround — acceptable if documented and staff trained
- Post-launch — fix in week one or phase two; does not delay cutover
Without tiers, every cosmetic bug becomes a moral crisis.
Acceptance criteria: write scenarios, not adjectives
Replace "booking module works" with testable scenarios:
- Customer completes booking with GCash; staff sees confirmed record within 60 seconds
- Staff can cancel booking; customer receives notification; slot becomes available
- User without finance role cannot export payment report
- Duplicate form submission does not create duplicate charge
Each scenario should have expected result and who signs off — usually the operational owner, not only IT.
We align these during QA phase in our software development process; the same discipline applies whether we built it or you are accepting from another vendor.
Who tests, and with what data
Developers test code paths. Your team tests reality — the weird customer, the partial payment, the staff member who skips steps.
Assign testers by role:
- Frontline staff run daily workflows
- Finance verifies totals and exports
- Owner or manager verifies reports match trust level needed for decisions
Use sanitized production-like data where possible. Testing only on "John Doe / 123 Main St" misses the encoding issues in real Filipino names and addresses.
Environments: know what "staging" proves
Staging should mirror production closely — same integrations in test mode at minimum, same permission model, realistic data volume if performance matters.
Clarify:
- What was verified on staging vs only on production after deploy
- What requires a controlled production test (small real payment)
- When staging diverged and what risk that leaves
"No time for staging" is a launch risk acceptance you should make explicitly.
Rollback: when to pull the plug
Define rollback before launch adrenaline hits:
- Triggers — payment failures above X%, data corruption, auth broken for all staff, security exposure
- Procedure — revert release, enable maintenance page, restore database snapshot
- Decision maker — one named person authorized to call rollback
- Communication — staff script, customer message template
Rollback is not failure. Shipping without a rollback plan is negligence.
Ownership after go-live
Software is not furniture. Done includes who keeps it running:
- Bug fixes — vendor SLA or internal dev; response times
- Hosting and domains — who pays, who has credentials
- Integrations — who updates API keys when providers change
- Backups and restores — who monitors, who executes restore
- Security updates — framework patches, dependency updates
- Feature requests — how they enter backlog; change control
Philippine SMEs often assume the agency owns everything forever. Clarify retainer, hourly, or handoff to internal staff.
Sign-off, docs, and the first two weeks
Hold a short acceptance meeting: scenarios passed or deferred, rollback acknowledged, ownership documented. Email summary afterward — verbal "okay na" does not survive the first production incident.
Keep an admin guide for top ten tasks, a known-issues list, and a credential inventory (secured, not emailed).
Done includes hypercare
Acceptance does not end at deploy. Agree:
- Hypercare period — faster response, daily check-ins
- Metrics review at day 7 and day 14
- Process for promoting deferred items to phase two with scope impact
Many projects are "done" on paper and fail in adoption because nobody watched week one friction.
Define done before you need to argue about it
If launch is approaching and acceptance still means different things to different people, reach out. We will help you write scenarios, rollback rules, and ownership lines — or review what a vendor delivered against criteria that protect your business. For projects scoped with clear launch boundaries from the start, see custom systems & web applications.
