Services

Which of these you actually need

Most enquiries arrive naming a service. That is a reasonable way to start a conversation and a poor way to scope work, because the named service is a solution someone already chose and it is frequently not the one that addresses the constraint. The more useful framing is what is currently not working, and there are only a handful of answers that lead anywhere different.

If the problem is that the product does not exist yet and nobody has confirmed anyone wants it, the work is MVP development, and the output is evidence rather than software. If the product exists, people use it, and the difficulty is that it will not scale or cannot be sold to larger customers, the work is SaaS engineering. If it exists and works and nobody finds it, the work is search — and which flavour depends on how people are actually looking.

The expensive mistake is buying the wrong one of those three confidently. A team that builds a robust multi-tenant platform for a product nobody has validated has spent months making an unproven assumption harder to reverse. A team that runs a search programme against a product with no retention is buying traffic that leaves.

Engineering and search are not sequential

The conventional order is to build the product and then make it discoverable, and it is wrong in a specific and costly way. Whether a page can be extracted by an AI assistant depends on that page's structure — how answers sit relative to headings, how the content is rendered, whether the substance is in the initial HTML or arrives later from JavaScript. All of that is decided during the build.

Retrofitting it is not an optimisation pass; it is a frontend rewrite. We have seen products where the search work was blocked for a quarter because the rendering strategy made content invisible to everything except a browser, and the fix required rebuilding the pages rather than editing them.

That is why the two practices are described here as one team rather than as a build followed by a campaign. Where a product is being built, the visibility constraints belong in the architecture conversation. Where a product already exists, the search work frequently surfaces engineering problems — and being able to fix them rather than file a ticket is most of the value.

How the two commercial models differ, and why

Engineering runs as fixed-scope phases quoted after a paid discovery. Search runs as quarterly retainers. That difference is not a pricing preference; it follows from the shape of the work.

A build has a definable end. Once discovery has established the architecture and the actual constraint, a phase can be scoped, and the risk of scoping it wrongly sits with us rather than with you. What makes that possible is the discovery — quoting a fixed price against a specification nobody has validated forces padding into the estimate and turns every discovered requirement into a negotiation instead of a decision.

Search does not have an end. Competitors publish, algorithms change, assistants change which sources they favour, and a position held this quarter is not held next quarter without work. A fixed-scope search engagement would either be a technical audit — which is genuinely finite and which we do sell that way — or a fiction.

The practical consequence for planning is that engineering spend is lumpy and predictable while search spend is level and continuous. A company budgeting for both should not expect them to behave the same way in a cash flow forecast.

What discovery actually produces

Every engineering engagement opens with a paid discovery period, typically one to two weeks. That is a real deliverable rather than a sales process, and it is worth being specific about what it contains, because "discovery" is a word that covers a great deal of nothing in this industry.

It produces an architecture — the actual system design, with the decisions that are expensive to reverse identified and justified. It produces a scoped plan broken into phases that each deliver something usable. It produces an estimate we are willing to stand behind, which is only possible because by then we have looked at the data, the existing systems and the constraint rather than at a document describing them.

It also frequently produces a recommendation that differs from what was asked for. That is the most valuable outcome and the one most likely to be unwelcome. A discovery that concludes the proposed project should be substantially smaller, or should not happen, has saved considerably more than it cost.

You own the output regardless of whether you continue. A discovery that produces a plan you take elsewhere is a reasonable outcome and we would rather that than an engagement neither side wanted.

SEO, GEO and AEO are three different problems

These get bundled together, including by us on this page, and they behave differently enough that treating them as one budget line produces disappointing results.

Traditional search optimisation competes for a position on a results page that a person then scans. The unit is a page, the measurement is a ranking, and the mechanics are well understood after two decades.

Answer engine optimisation competes to be the extracted answer itself — the passage lifted into a featured snippet or a voice response. The unit is a passage rather than a page, and a page can rank well and never be extracted because its answer is buried under three paragraphs of preamble.

Generative engine optimisation concerns whether an assistant synthesising a response cites you among its sources. There is no results page to rank on. What matters is being readable, quotable and specific enough that a model composing an answer has a reason to attribute part of it to you.

They share a technical foundation — a page that cannot be crawled or rendered fails all three — and they diverge sharply in how content is structured. A programme addressing only the first is optimising for the surface that is shrinking.

What we decline

Being clear about this saves a conversation. We do not take staff augmentation where the requirement is people against a specification written elsewhere; the value we add is in shaping what gets built, and an arrangement removing that leaves both sides worse off.

We do not take fixed-price contracts against specifications nobody has validated, for the reasons above. We do not guarantee rankings, because they depend on competitor behaviour and algorithm changes that nobody controls, and anyone promising otherwise is either targeting terms with no demand or is not being straight with you.

And we decline work whose brief is volume — pages, posts or locations generated at scale without a corresponding claim to being useful. That approach carries real penalty risk at the domain level, and we would rather turn it down than deliver something that damages a client's site.

How long each of these takes

Timelines are the question behind most first emails, so here are the honest ranges rather than the flattering ones. An MVP that answers a specific commercial question reaches real users in eight to twelve weeks. Past that, scope has usually expanded from the experiment into building the product the experiment was meant to justify.

A first billable version of a SaaS platform typically runs three to five months from discovery, and the variable is how much of the tenancy, entitlement and billing model is genuinely custom. Products needing single sign-on, provisioning or audit logs from the start sit at the longer end, because those are structural rather than additive and retrofitting them means touching the user model.

Search moves on a different clock. Technical fixes to indexing or Core Web Vitals can show within weeks because they remove an existing obstacle rather than building an asset. Content and authority work typically shows meaningful movement across three to six months, and a programme judged at eight weeks will be judged before it has done anything measurable.

Working with us from outside India

Indian Standard Time gives a full overlapping morning with Europe and an early-morning window with the US East Coast. There is no natural overlap with the US Pacific coast, and any agency claiming otherwise is either expecting someone to work unsociable hours or is not being straight about it. Where we work with Pacific clients we say which hours are covered and structure the work so that progress does not depend on synchronous conversation.

On intellectual property, work product is assigned to you on payment. That clause is doing real work rather than restating a default, because Indian copyright law vests authorship with the creator absent an agreement — so it is worth reading rather than skimming, along with what it says about pre-existing components and the open-source licences travelling with them.

Where to start

The most useful first conversation is not a walk through a feature list. It is three questions: what is currently not working, what have you already tried, and what would count as success. Those are usually enough for us to say whether this is work we should take, which service it actually is, and roughly what it involves.

If the answer is that we are not the right fit, we will say so in that conversation rather than three months into an engagement.