01 — Diagnose
Client inputs: goals, current frustrations, existing material and access available for review. GA output: a problem map, audience view and initial opportunities. Gate: agreement on the target and priority—not on a visual style.
A visible delivery path
Know what happens next—and what each decision unlocks.
GA Applications uses an eight-phase delivery path: diagnose, scope, research, prototype, build, test, launch and improve. The detail changes by project, but the principle stays consistent: inputs, outputs, responsibilities and approval gates are made visible so that creative ambition can move forward without hiding risk or unfinished decisions.
Clearscope and responsibility
Usefulsystems people can operate
Durableownership after launch
Why it matters
01 — Diagnose
Client inputs: goals, current frustrations, existing material and access available for review. GA output: a problem map, audience view and initial opportunities. Gate: agreement on the target and priority—not on a visual style.
CHAPTER 01 / Phases 01–02
Diagnose the real constraint, then make the scope testable.
The opening phases separate symptoms from causes and turn an ambition into a reviewable piece of work. Existing content, tools, data, dependencies and decision-makers are surfaced early enough to influence the direction.
02 — Scope
Client inputs: priorities, constraints, decision owners and known deadlines. GA output: proposed deliverables, boundaries, dependencies, assumptions and acceptance approach. Gate: written approval of the scope and commercial terms.
CHAPTER 02 / Phases 03–04
Build the evidence and experience before committing the whole system.
Research and prototyping are where content, structure and interaction become inspectable. They reduce the risk of polishing a route that cannot answer the visitor's question or support the team doing the work.
03 — Research and content
Inputs can include approved business material, interviews, analytics and named public sources. Outputs can include content models, source records, search intent, journeys and page outlines. Gate: factual and structural review.
04 — UX and prototype
Inputs include approved priorities and content direction. Outputs can include navigation, wireframes, visual systems and interactive prototypes. Gate: approval of the representative experience and known responsive behaviour.
CHAPTER 03 / Phases 05–06
Construct the approved direction, then challenge it.
Build turns the reviewed model into production behaviour. Quality assurance then tests the result against the agreed journeys, content, accessibility needs, integrations and release conditions—not only against a screenshot.
05 — Build and integration
Outputs may include templates, components, content, forms, data connections and configured workflows. Progress reviews focus on completed slices of the user journey. Gate: feature and content readiness for formal QA.
06 — QA, accessibility and security
Checks cover representative devices, keyboard use, reduced motion, form states, permissions, redirects, metadata, performance and agreed security controls. Gate: documented launch readiness and acceptance of known limitations.
CHAPTER 04 / Phases 07–08
Launch is a controlled transition, not the end of attention.
Release planning covers the move from the existing state to the approved one. Handover makes ownership and operation understandable. Optimisation then responds to observed use, new priorities and explicitly agreed support—not assumptions of indefinite work.
07 — Launch and handover
Outputs can include migration, release checks, access transfer, operating notes, training and a known-issues record. Gate: authority to launch plus confirmation of operational ownership.
08 — Optimisation and support
Inputs are real feedback, measurement and support requests. Outputs depend on the agreed maintenance or improvement arrangement. Gate: each new change is prioritised and authorised before work begins.
CHAPTER 05 / Shared responsibility
Good delivery needs decisions from both sides.
GA Applications
Makes the proposed approach, dependencies, open questions and produced evidence visible; implements the agreed work; and raises material risks encountered within scope.
Client project owner
Coordinates access, factual material, feedback, approvals and the people authorised to make decisions.
Content and data owners
Confirm accuracy, permissions, retention needs and whether supplied information is appropriate for publication or processing.
External specialists
Provide legal, regulatory, electrical, security or other advice where the project requires expertise outside the agreed digital scope.
CHAPTER 06 / Change without confusion
New information is normal. Invisible scope change is not.
When a request changes an approved deliverable, integration, dependency or acceptance condition, it should be recorded before implementation. The impact on sequence, cost, risk and previously approved work can then be considered together.
Clarify
Write the requested change and the reason it matters.
Assess
Identify affected work, dependencies, decisions and testing.
Choose
Approve the change, exchange it for another priority, defer it or keep the existing scope.
Record
Update the agreed reference before the changed work proceeds.
CHAPTER 07 / Evidence at every gate
Progress should be inspectable, not merely reported.
The form of evidence changes with the work: a content model, prototype, test record, working demonstration, source list, redirect map or handover note. The purpose is the same—to make the next approval informed and reduce disagreement about what is complete.
Before build
Problem map, scope, assumptions, source material, journeys and representative prototype.
Before launch
Working release candidate, content approval, test evidence, migration plan and accepted known limitations.
After launch
Access record, operating guidance, support route and measurement appropriate to the agreed project.
Continue through the ga applications system.
Each route answers a different operating question while retaining the same standards for evidence, responsibility and a usable next step.
Route 01
About
See how GA Applications approaches websites, business systems, automation and responsible digital design as one connected project.Route 02Pricing
Understand how scope, content, integrations, risk and support shape a GA Applications estimate without misleading one-size-fits-all packages.Route 03Faq
Direct answers about GA Applications services, delivery, pricing, ownership, SEO, AI, support, locations and independent concepts.Route 04Support
Report an issue, request a controlled change or find the right support path for a GA Applications website or connected system.Route 05Warranty
Understand how a potential defect is distinguished from a change and assessed under the applicable GA Applications agreement and law.Route 06Refunds Cancellations
Understand how a cancellation or refund request is reviewed against completed work, commitments, third-party costs, written terms and law.Route 07Chinkara Maven
Explore Chinkara Maven as GA Applications' guided assistance layer for approved knowledge, clear permissions and human-reviewed action.Questions worth resolving
What to clarify before committing.
Does every project use all eight phases?
The thinking remains, but the amount of work in each phase depends on the project. A focused improvement may move quickly; a migration or connected system may require deeper research, testing and coordination.
When does design begin?
Design thinking begins during diagnosis, but detailed visual and interaction work should follow enough agreement on audience, content, priorities and constraints to make the prototype meaningful.
Can the project change after approval?
Yes. The requested change should be documented and its effect on deliverables, sequence, cost and testing assessed before it is authorised.
What counts as launch approval?
The written project arrangement should identify who may approve launch and the relevant acceptance conditions. Known limitations should be visible rather than silently carried into release.
Phase zero
Bring us the current state and the intended destination.
You do not need to prescribe the technology. Describe what happens today, who is affected, what evidence exists and what a better outcome would look like.