Engagement frameworks

How we structure case studies

This page publishes our framework rather than customer success stories. It sets out what we record at the start of an engagement, what we measure during it, and what a written case study would contain.

We think the framework is more useful during an evaluation than an unverifiable percentage would be. It also shows exactly which numbers we would be committing to defend.

These are engagement frameworks, not customer success stories

Nothing on this page describes an actual client, project or result. No figures are published because none have been authorised for publication and no illustrative number would be honest. Verified client case studies will be published only with appropriate client permission, identifying who authorised publication and the period covered.

Framework 01

Mobile engineering engagement

What a write-up of an Android engagement would contain, and the metric types that would normally be tracked. Values are omitted because none have been authorised.

Framework 01

Android application delivery

Structure used for a native Android build or takeover, from the problem statement through to what is monitored after release.

Challenge: The commercial problem stated in business terms — what the application must let users do, and what currently prevents it. Recorded before any technical decision is made.
Scope: The deliverables agreed in the statement of work: features, platforms, integrations, and explicitly what is excluded.
Architecture: Layering, state handling, persistence model, background execution strategy, and the integration contract with the backend. Written down and agreed before implementation.
Reliability considerations: Behaviour under constrained conditions: process death, dropped connectivity, aggressive battery management, low memory and older API levels.
Measurement: The event schema: event names, firing conditions, parameters, values, deduplication rules, and which events are conversions rather than diagnostics.
Metrics normally tracked: Crash-free sessions and users; ANR rate; cold and warm start time; jank and frame timing; install-to-first-action completion; retention by cohort; Play Console vitals against the platform's thresholds.
Reporting: What was released, when, at what rollout percentage, what regressed, and what was done about it.

Framework 02

Performance advertising engagement

What an advertising write-up would contain. Note that the advertiser setup row is a factual record of roles, not a marketing statement — it is the part reviewers and clients most often need.

Framework 02

Google Ads programme

Structure used for a Google Ads engagement, covering the commercial objective, the account and role setup, the measurement basis and the reporting.

Objectives: What the advertising is for, expressed as an action the business values, with the acceptable cost of that action agreed in advance.
Advertiser setup: Who the advertiser is (the business being promoted), how access was granted, whether a Manager Account link applies, and which billing arrangement applies to the account — direct client billing, or approved agency billing where eligible and agreed.
Account structure: Campaign types selected and why, segmentation, budget allocation and bidding strategy, with the reason each was chosen.
Measurement: Conversion actions and values, the attribution model in use, deduplication, and the known limitations stated rather than left implicit.
Optimisation: Changes made during the period and what each was intended to affect, so a shift in performance can be tied to an action.
Metrics normally tracked: Spend; impressions and impression share; clicks and click-through rate; conversions and conversion rate; cost per conversion; conversion value and return on ad spend where value data is reliable; search term and placement quality.
Reporting: Platform media cost and agency service fee shown separately, traceable to campaigns and dates, with open items and their status.

The advertiser, agency and payer roles referenced above are separate concepts and are described in full on the agency–client relationship page. We do not guarantee any of the metric outcomes listed; they are what would be measured, not what is promised.

Framework 03

Cloud / API engagement

What an infrastructure write-up would contain, weighted toward the operational characteristics that determine whether a system is actually dependable.

Framework 03

Backend and infrastructure delivery

Structure used for a backend build, migration or takeover, from the assessed starting position through to steady-state operation.

Starting position: Assessment of existing services, dependencies, data model, deployment process, backup status and monitoring coverage, with a prioritised risk list.
Scope: Service boundaries, the API contract, and what is explicitly out of scope.
Throughput: Expected and peak request volumes, payload sizes and concurrency, with the load the system is being designed to hold stated up front.
Reliability: Failure modes considered, timeout and retry behaviour, idempotency, graceful degradation, and what happens when a dependency is unavailable.
Caching: What is cached, where, for how long, and how it is invalidated — including LiteSpeed Cache configuration where the web layer is OpenLiteSpeed.
Observability: Logs, metrics and alerts, chosen so an alert corresponds to something a person would need to act on.
Deployment: The repeatable deploy and rollback procedure, environment parity, and how configuration and secrets are handled.
Metrics normally tracked: Request latency at median and upper percentiles; error rate by class; throughput; database query time; cache hit ratio; resource saturation; successful restore tests.

Questions

About this page

Are these real client case studies?

No, and they are deliberately not presented as such. This page publishes the framework we use to structure an engagement write-up: what we would record, what we would measure and how we would report it. No client, result or figure on this page describes an actual engagement, because no client has authorised publication.

When will real case studies appear?

Verified client case studies will be published only with appropriate client permission. Each entry will identify who authorised publication and the period it covers, and every figure will be traceable to our own records or the platform's reporting.

Why not publish anonymised results instead?

Because an anonymised figure cannot be verified by the reader, and an unverifiable performance claim is worth less than an honest description of method. If a number cannot be attributed and checked, publishing it would be marketing rather than evidence.

Evaluate us properly

Ask what we would measure for your engagement

Describe the objective and we will set out what we would record, what we would optimise toward and what the reporting would contain — before any commitment.

Discuss Your Project Email Us Directly

Email: contact@aquariusinfotech.com
Telephone: +91 87800 2787
Principal place of business: 3rd Floor, Office No. 309, Cyber City
VIP Circle, Mota Varachha, Utran
Surat, Gujarat 394105, India
Accountable person: Gopal Savaliya — Founder & Managing Director