How we diagnose, build and measure client projects

Why this page has no client logos on it

Most case study pages in the web development market, in India and everywhere else, are decoration. A logo, a number with no baseline, a sentence about growth, and no explanation of what actually changed. You cannot learn anything from that, and you certainly cannot predict whether the same team would help you. We are a three person freelance group, we have been building for a while, and we do have work we are proud of. What we do not have is a set of published case studies with client permission, verified before and after figures, and honest notes about what did not work. Until we do, this page will not carry any.

So we wrote the next most useful thing. Six scenarios, clearly labelled as illustrative, each following the same shape: what the business was experiencing, what we would look at before touching any code, what we would build, and what we would measure once it was live. If you recognise your own situation in one of them, that is the point. Project references are available on request, and we will connect you with someone directly rather than quote them selectively.

How we diagnose a problem before quoting a build

Nearly every enquiry we receive arrives as a solution rather than a problem. "We need a new website." "We need SEO." Sometimes that is right. Often the real issue is narrower and cheaper to fix. So the first conversation is diagnostic. Where do enquiries currently come from, and how many? What happens to an enquiry after it arrives, and who picks it up? Which pages does search traffic land on, and what do those visitors do next? What does the business actually earn per customer, because that decides how much a website is worth building.

Then we look at the site as it exists. Not aesthetically, but structurally. Is it indexed. Does it load acceptably on a mid-range Android phone on mobile data. Does every service have a page worth ranking. Is there a phone number visible without scrolling. Are forms reaching an inbox anyone checks. Half the time this audit produces a list of small fixes that beat a rebuild, and we say so, because quoting a ₹60,000 (US$900) web app for a problem solved by a ₹10,000 (US$150) site helps nobody twice.

What we agree on before starting

Before a project begins we write down the measure of success. Not "more traffic" but something checkable: enquiries per month by source, or the number of service pages indexed and ranking, or order completion rate. We also agree on what we are not doing, which prevents scope drifting sideways for six weeks. Because we deliver end to end, planning, design, development, SEO setup, hosting and deployment all sit in one plan with one timeline.

• The single metric that decides whether this worked
• A baseline reading taken before we change anything
• Page count, integrations and content responsibilities
• Launch date and what happens in the five free maintenance months

Scenario one: a local service business getting no online enquiries

An air conditioning repair and installation business covering three neighbourhoods has a site built four years ago. It looks fine. It produces roughly one enquiry a month, all from people who already knew the company name. The owner assumes the site needs redesigning. It usually does not.

What we would investigate first: whether the site is indexed at all, whether there is a page for each service and each area served, and what people in that city actually type when their AC stops cooling in May. Very often the entire business sits on one page listing seven services, competing against nobody in particular. We would also check whether the phone number is clickable on mobile, because a surprising number are not.

What we would build: separate pages per service and per service area, each written for how people phrase the problem, with the phone number above the fold and a short form underneath. Clear pricing bands where the business is comfortable publishing them. Proper local structured data and a Google Business Profile that matches the site exactly. This is typically a static website of up to 100 pages from ₹10,000 (US$150), or a 299+ page SEO website from ₹20,000 (US$300) where the business covers many areas, often paired with monthly SEO from ₹10,000 (US$150) per month while rankings build.

What to measure afterwards: calls and form submissions separately, by month, split by which page the visitor landed on. Indexed page count in the first six weeks. Rankings for eight to ten commercial phrases, not vanity terms. If service-area pages are not producing calls by month three, the problem is the copy or the competition, and we adjust rather than wait. Our SEO services page explains that cycle in more detail.

Scenario two: a manufacturer whose catalogue is trapped in PDFs

An industrial components manufacturer has 400 products documented across eleven PDF brochures linked from a downloads page. Buyers search for a part specification, find nothing, and go to a competitor or a marketplace listing. Internally, sales spends hours emailing the correct PDF to people who could have found it themselves.

What we would investigate first: how buyers actually search, which is usually by specification, material grade or part number rather than by product family. We would extract the catalogue structure from the PDFs, look at how many genuinely distinct products exist versus variants, and check whether the specification data lives anywhere structured, such as an ERP export or even a maintained spreadsheet. That single question decides whether this is a content project or a data project.

What we would build: a filterable product catalogue where every product has its own indexable page carrying specifications as real text, with the PDF datasheet still available as a download rather than as the only source. Filters for the attributes buyers care about. An enquiry button on each product page that carries the part reference into the message so sales knows immediately what is being asked about. Where the data lives in a spreadsheet or ERP, we build an import so nobody retypes 400 rows.

What to measure afterwards: how many product pages get indexed, organic landings on product pages rather than the homepage, enquiries carrying a specific part reference, and the time sales spends answering catalogue questions. A catalogue project of this size normally sits in web development territory, with cost driven by data quality more than page count.

Scenario three: a coaching institute losing leads across WhatsApp and phone

A competitive exam coaching institute gets steady interest. Enquiries arrive on two WhatsApp numbers, one landline, an Instagram inbox and a website form nobody has checked since December. Three staff members reply when they can. Nobody knows how many enquiries came in last month, how many converted, or which channel produced the students who actually enrolled.

What we would investigate first: not the website. We would trace one enquiry end to end. Who sees it, how fast, what they say, and where it is recorded. Then we would count last month's enquiries by hand across every channel, which usually takes an afternoon and produces the most useful number the institute has ever had. Only then does it become clear whether the problem is lead volume or lead handling. In this scenario it is almost always handling.

What we would build: a single intake path. Every channel, including the WhatsApp click-to-chat links, feeds one shared record with course interest, batch preference and source. Automated first response within seconds so nobody waits an hour. A simple dashboard showing enquiries, follow-ups pending and enrolments by source. Website pages per course and per exam, since parents research course fees and batch timings before they ever message. Automation work of this kind starts from ₹40,000 (US$600), with the website portion quoted separately.

What to measure afterwards: total enquiries, median first response time, follow-up completion rate, and enrolments attributed to source. The response time number moves fastest and predicts the rest.

Scenario four: an ecommerce store with slow product pages

A homeware store on a common platform has healthy traffic and a disappointing conversion rate. Product pages take five or six seconds to become usable on a mid-range phone. The owner has been told to buy faster hosting. Hosting is rarely the culprit.

What we would investigate first: a waterfall trace of a real product page on a throttled mobile connection. Usually the findings are unglamorous. Eleven marketing scripts, four of them for tools nobody uses any more. Hero images shipped at 3000 pixels wide and scaled down in the browser. Three chat widgets. A review app loading a font. Layout shifting as the price block arrives late, so customers tap the wrong thing. We would also check the checkout separately, since a fast product page feeding a broken payment step fixes nothing.

What we would build, or more accurately remove: unused scripts deleted, remaining third-party tags deferred, images converted to modern formats and served at the size actually displayed, critical styles inlined, and space reserved for late-arriving elements so nothing jumps. Then the product page itself gets attention, since specifications, delivery timing and return terms visible without scrolling do more for conversion than shaving another half second. Full ecommerce builds start from ₹50,000 (US$750); a focused speed and conversion pass is quoted on scope.

What to measure afterwards: time to interactive on a mid-range Android, layout shift, add-to-cart rate, checkout completion rate, and revenue per session. Track revenue per session above all, because speed work that does not move money is a hobby.

Scenario five: a clinic invisible in local search

A two-doctor dental clinic has a decent website and effectively zero visibility when someone nearby searches for a dentist. Patients arrive by referral only. The clinic has a Google listing created years ago with an old phone number and an address written differently from the one on the site.

What we would investigate first: consistency. Name, address and phone number across the website, the Google listing, directory entries and old social profiles. Search engines treat mismatches as uncertainty, and uncertainty costs map visibility. Then coverage: does the site have a page per treatment, with honest fee ranges, timings, and the practical questions patients ask before booking. Then reviews, which for clinics are usually the deciding factor and usually neglected.

What we would build: corrected and matching business details everywhere, a treatment page per service written in plain language, doctor profiles with real qualifications and registration details, opening hours and directions rendered as text rather than only inside an image, and structured data describing the practice. A booking or callback request that reaches the front desk reliably, because a form landing in an unmonitored inbox is worse than no form at all.

What to measure afterwards: map pack impressions and direction requests on the Google listing, calls from the listing separately from calls from the site, new patient bookings by month, and review count and recency. Local visibility moves in weeks, not days, and treatment pages usually start ranking before the map position improves.

Scenario six: a team drowning in spreadsheet admin

A twelve person logistics coordination team runs on shared spreadsheets. One file per client, one master tracker, and a daily hour of copying between them. Two people maintain formulas nobody else understands. Every month someone overwrites a column and a day disappears reconstructing it.

What we would investigate first: which parts of the process are genuinely repetitive and which need judgement. Automating a decision that needs a human produces confident wrong answers at speed. We would sit with the team, record the actual steps rather than the documented ones, and time them. Then we would find the two or three transfers that consume the most hours and carry the most error risk. Those get automated first, and the rest waits.

What we would build: usually not a giant internal platform. Often a small tool that replaces the copying, validates entries at the point of entry, keeps an edit history so a bad paste is recoverable, and generates the reports someone currently assembles by hand every Friday. Where documents and emails need reading, that is where AI automation earns its place, starting from ₹40,000 (US$600). A fuller internal tool with roles and permissions becomes a custom web app, from ₹60,000 (US$900).

What to measure afterwards: hours per week on manual transfer, error corrections per month, and how long a new joiner takes to become productive. If the tool does not save hours within a month of launch, it was the wrong tool and we would rather find that out quickly.

What makes a case study worth trusting

When you read anyone's case studies, including ours later, apply a few tests. Is there a baseline, or does the page only show the after figure. Is the time period stated. Does it mention what else changed, such as a new ad budget or a seasonal spike, because a website rebuild that coincides with festival season will claim credit for the calendar. Are the numbers business outcomes or vanity metrics, since a 300 percent traffic increase to a page that sells nothing is not an achievement. And can you talk to the client.

The last test is the one that matters. Anyone can write a paragraph. Few will put you on a call with the person who paid for the work. We will. Project references are available on request, subject to the client agreeing, and we introduce you directly rather than passing along a curated quote. Ask them what went wrong during the project, not just what went right, because every project has something.

What we include and what it costs

Every project runs end to end: planning, design, development, SEO setup, hosting and deployment, handled by the same three people throughout. Once hosting goes live, two months of maintenance are included free, covering content updates, bug fixes, security updates, backups, and uptime and speed checks. After that period maintenance is from ₹8,000 (US$120) per month.

• Static website, up to 100 pages, from ₹10,000 (US$150)
• 299+ page SEO website, design to deployment, from ₹20,000 (US$300)
• AI automation from ₹40,000 (US$600)
• Ecommerce from ₹50,000 (US$750)
• Custom web app from ₹60,000 (US$900)
• Monthly SEO from ₹10,000 (US$150) per month

INR prices apply in India and USD prices to international clients. Final cost always depends on scope: pages, features, integrations and content. Full detail sits on the pricing page.

Related pages

If one of the scenarios above matched your situation, these pages go into the relevant detail. We work remotely from India with clients in the USA, UK, Canada, Australia, the UAE, Singapore, Europe and India.

• All services
• Web development
• SEO services
• Industries we work with
• Portfolio
• Pricing
• About the team
• Countries we serve
• Web development for US businesses
• Web development for UK businesses
• Canada, Australia and UAE
• IT services across India
• Web development in India
• Mumbai
• Bangalore
• Gurgaon
• Blog

Questions people ask about our case studies

Straight answers about what we have published, what we have not, and how to check our work before committing to a project.