Project Engagement Policy
Last updated: 20 June 2026. This policy explains how Nuvyqo normally starts, manages, reviews and hands over digital business solution projects.
1. Discovery and business understanding
Every serious project starts with understanding the business model, users, goals, current systems, data flow, revenue flow, pain points and success criteria. This helps avoid building a system that looks good but does not solve the real operational problem.
2. Scope and milestones
The project scope should define deliverables, pages, modules, dashboards, integrations, database work, automations, deployment tasks, assumptions, exclusions, timeline and payment milestones.
3. Access and credentials
Clients should provide required access through secure channels where possible. Access may include domain/DNS, hosting, Cloudflare, AWS, IIS, database, email, analytics, Search Console, payment gateways or admin panels. Temporary access is preferred where available.
4. Communication and approvals
Nuvyqo normally works through project discussions, written notes, review links, screenshots, test URLs and milestone approvals. Delayed feedback or repeated scope changes can affect the timeline.
5. Revisions and change requests
Reasonable revisions are included when they are within the agreed scope. New modules, major layout changes, extra pages, advanced integrations, new reports or changes after approval may be treated as change requests.
6. Testing and launch
Before launch, Nuvyqo may check page structure, forms, links, mobile layout, speed basics, DNS/SSL, deployment settings, database flows, payment/access logic, reports and critical user journeys depending on project type.
7. Handover
Handover may include source files, deployment notes, admin credentials, DNS/hosting notes, database details, documentation, training notes or maintenance recommendations as agreed in the scope.
8. Maintenance and support
Maintenance is separate unless included in the proposal. Ongoing support may cover fixes, backups guidance, SEO checks, content changes, monitoring, database health, reports, cloud support or automation improvements.
9. Project closure
A project is considered complete when agreed deliverables are shared, deployed or approved. Further updates after closure may be handled through a new task, support plan or improvement phase.