Defined scope
Best when the deliverables, inputs, boundaries and acceptance conditions can be described with confidence. The proposal states what is included and how change will be handled.
Commercial clarity before commitment
Price the work that creates the outcome—not a mystery bundle.
GA Applications prices work from an agreed scope, delivery pathway and set of responsibilities. The estimate depends on what must be researched, designed, written, built, connected, migrated, tested and supported. Any amount, payment arrangement or ongoing cost becomes binding only when it appears in an accepted written proposal or agreement.
Clearscope and responsibility
Usefulsystems people can operate
Durableownership after launch
Why it matters
Defined scope
Best when the deliverables, inputs, boundaries and acceptance conditions can be described with confidence. The proposal states what is included and how change will be handled.
CHAPTER 01 / Three pathways
Choose the shape of engagement that matches what is known.
Phased discovery and delivery
Useful when the target is clear but important content, data, integrations or technical constraints must be investigated before the complete build can be responsibly priced.
Ongoing improvement
Suitable for an agreed programme of maintenance, content, optimisation or iterative development. The written arrangement defines priorities, capacity, exclusions and how new work is authorised.
CHAPTER 02 / What shapes an estimate
The visible page is only one part of the effort.
Clarity of scope
Known journeys and acceptance conditions require less contingency than unresolved requirements or competing decision paths.
Content and evidence
The volume, condition and ownership of copy, photography, records, local research and approvals affect both production and review.
Design depth
A shared component system, custom interaction, animation, illustration or immersive experience each carries a different design and testing load.
Systems and data
Integrations, imports, permissions, data quality, error handling and audit needs can be more significant than the number of screens.
Migration and continuity
Existing URLs, search visibility, content, accounts and operational dependencies may need controlled transition rather than simple replacement.
Assurance and support
Accessibility depth, security review, environments, documentation, training and post-launch arrangements are scoped according to risk and need.
CHAPTER 03 / Service comparison
Different services concentrate effort in different places.
Website or redesign
Audience journeys, content structure, visual system, responsive components, search migration, forms and connected follow-up.
CRM or workflow
Record model, process states, permissions, imports, notifications, reporting and adoption by the people using it.
Dashboard
Data availability, definitions, cleaning, refresh behaviour, role views, exceptions and accessible reporting alternatives.
Automation or field system
Triggers, rules, failure states, overrides, connectivity, evidence, device context and specialist responsibilities.
AI assistance
Approved sources, permissions, retrieval, review, logging, failure handling and clear boundaries on actions.
CHAPTER 04 / Included and optional
The proposal should separate the core outcome from selectable additions.
There is no universal inclusion list across every project. The accepted proposal should identify deliverables, review rounds or gates, implementation, testing and handover relevant to that scope. Optional work should be recognisable before it is approved.
Often defined in the core scope
Specified research, information architecture, representative design, agreed build, content treatment, QA and handover outputs.
Common selectable additions
Extended content production, original photography, complex migration, new integrations, extra environments, advanced animation, training or ongoing optimisation.
Explicit exclusions
Unlisted specialist advice, licences, hardware, third-party work, unlimited revisions or ongoing operation should not be assumed.
CHAPTER 05 / External and ongoing costs
Separate project work from services supplied by others.
Hosting, domains, software subscriptions, payment providers, messaging, maps, stock assets, fonts, data services, hardware and specialist providers can carry separate terms or usage charges. Where relevant, the proposal should state whether an item is client-owned, passed through, estimated or paid directly to the supplier.
Ownership
Record whose account holds the service and who controls access, billing and renewal.
Variability
Identify costs affected by traffic, storage, messages, users, transactions, usage or currency.
Dependency
State what website or workflow behaviour depends on that supplier remaining available and compatible.
CHAPTER 06 / From enquiry to estimate
A useful estimate follows enough discovery to define the decision.
1. Describe the target
Explain what should become easier, for whom and why it matters now.
2. Reveal the current state
Share relevant pages, tools, spreadsheets, data, workflows and known constraints.
3. Select a pathway
Decide whether enough is known for a defined scope or whether a discovery phase should resolve uncertainty first.
4. Review the written offer
Check deliverables, assumptions, exclusions, responsibilities, dependencies, payment terms and acceptance conditions together.
CHAPTER 07 / Budget protection
Make trade-offs visible while they are still choices.
A strong scope identifies the smallest coherent release, the features that can follow later and the decisions that could change the cost materially. This gives the project room to sparkle where it creates value without allowing every page, animation or integration to become a separate surprise.
Prioritise journeys
Fund the actions and information people need most before expanding edge cases.
Reuse a system
Invest in components and content structures that can support several related pages or workflows.
Prototype uncertainty
Test complex interaction or integration assumptions before committing the entire build.
Phase responsibly
Keep later phases connected to the architecture while making each approved release useful on its own.
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 02Process
Follow GA Applications' eight-phase path from diagnosis and scope through design, build, launch, handover and measured improvement.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.
Why are there no standard prices on this page?
The services can involve very different content, integrations, migration, risk and support responsibilities. Publishing an unapproved figure would imply a scope that may not match the work. A written estimate follows enough information to define what is included.
Can a project be delivered in phases?
Yes, when each phase has a useful outcome and the later relationship is understood. A discovery or foundation phase can reduce uncertainty before wider implementation is approved.
Are hosting and third-party tools included?
Only if the written proposal says they are. External services may be paid directly by the client, passed through or treated separately, and their supplier terms still apply.
What happens if the scope changes?
The impact should be assessed and agreed before changed work proceeds. The options may include approving additional work, exchanging priorities, deferring the request or retaining the existing scope.
Request a scoped estimate
Show us the target, the current system and the unknowns.
We can then identify whether the next useful step is a defined proposal, a discovery phase or a smaller first release.