Growth Systems · Discovery-to-Apply

Rebuilding Foundit’s Discovery-to-Apply Engine

Foundit’s organic-growth problem looked like a traffic problem, but the deeper constraint was fragmented ownership across one customer journey. Marketing owned acquisition targets while Product and Engineering controlled many of the systems that determined whether seekers could discover relevant jobs and apply. I owned India organic acquisition and the seeker discovery-to-apply journey across approximately 1M web MAUs and 350–400K app MAUs, working across Product, Engineering, Search, Design, Analytics, Marketing and the SEO agency.

I reframed the charter around discovery-to-apply outcomes, fixed crawlability, indexation, shared search foundations and performance before scaling conversion work, and established a common operating cadence across the teams involved.

+131%

Organic applies

+29%

Total applies

3.0s → 1.8s

P90 Search API latency

3.7 → 4.8

Daily mobile applications per user

SEO was not a marketing channel problem. It was a product infrastructure and ownership problem.

01 · The Constraint

Traffic was not the constraint. The system behind it was.

Foundit is a two-sided marketplace. Seeker growth creates marketplace value only when people discover relevant jobs and produce useful candidate supply. Recruiters benefit only when that supply is relevant, active and qualified.

01

Crawlability & indexation

Valuable SRP and JDP inventory was not consistently discoverable.

02

Fragmented discovery architecture

SEO and logged-in search experiences had evolved separately.

03

Search performance

P90 Search API latency was ~3.0 seconds.

04

Decision & apply friction

Job evaluation and downstream progression carried unnecessary cognitive load.

05

Fragmented ownership

Marketing, Product, Engineering and the agency optimised different local metrics.

Adding more traffic to a weak discovery and conversion system would have amplified leakage rather than marketplace value.

02 · Decision Sequence

One journey. Solve the dependencies in order.

The sequence mattered because each downstream optimisation depended on the layer before it.

Crawlability
Indexation
Relevant discovery
Search performance
Job evaluation
Apply conversion
Marketplace value

Phase 01 — Foundation

Crawlability · Indexation · Shared discovery architecture · Performance

Phase 02 — Conversion

Job evaluation · Apply progression · Mobile activation

Phase 03 — Scale

Traffic growth · Experimentation · Marketplace outcomes

Fix infrastructure before funnel optimisation. Scale only after the journey can convert.

03 · Foundations

Valuable inventory existed. The system could not reliably surface it.

A · Discoverability

Core SRP and JDP inventory had crawl and indexation problems across canonicalisation, duplicate URLs, sitemap / robots behaviour, structured data and index coverage.

CanonicalisationDuplicate-URL controlSitemapsRobotsStructured dataSearch Console / index coverage

Indexed pages

~650K~2.5M

A foundation and enabling metric. Indexed-page growth supported discoverability; it was not a direct cause of the application results that followed.

B · Shared Discovery Foundation

SEO pages and logged-in search surfaces had evolved separately, creating duplicated logic and inconsistent behaviour. The strategic direction was to converge them onto shared foundations rather than continue maintaining parallel discovery systems.

C · Performance Headroom

P90 Search API latency

3.0s1.8s

A richer interface on a slow foundation would have made the experience worse.

04 · Strategic Trade-off

Unify the discovery system without sacrificing organic demand.

SEO landing pages and logged-in search had accumulated separate logic. Continuing that architecture reduced iteration speed and made personalisation, measurement and experience consistency harder. The higher-leverage decision was to converge the experiences onto a shared search foundation.

Option 01

Keep SEO and logged-in systems separate

Advantage

Lower migration risk

Cost

Duplicated logic and slower long-term iteration

Option 02 · Chosen

Move toward one shared search foundation

Advantage

Shared product logic, measurement and future personalisation

Risk

SEO ranking, latency and conversion could regress during migration

Guardrails

  • ·Ranking / discoverability
  • ·Conversion
  • ·Latency
  • ·Controlled rollout

The highest-leverage platform decision was not adding another SEO feature. It was removing the architectural split between acquisition and product discovery.

05 · Conversion

Once the foundation was stable, improve the decision journey.

A · Job Evaluation

  • ·Reduce competing elements
  • ·Clarify role, company, location and experience
  • ·Strengthen the primary apply action
  • ·Remove elements that do not help the decision

Reduce the number of decisions required before the primary decision becomes obvious.

B · Mobile Progression

Once the charter shifted from traffic to applications, onboarding and mobile apply friction became part of the same discovery-to-apply system rather than a separate mobile optimisation project.

Daily mobile applications per user

3.74.8

06 · Operating Model

The operating model had to change with the product system.

The technical problems could not be solved sustainably while each function optimised a different local metric.

01

Build one causal KPI tree

Crawlability → indexation → traffic → registration → search engagement → job evaluation → applications.

02

Shift success from traffic to applications

Move agency and stakeholder conversations from rankings and sessions toward qualified job discovery and applications.

03

Create a weekly decision cadence

Product, Engineering, SEO, Analytics and the agency resolve blockers, dependencies and decisions rather than exchange status.

04

Use CPO reviews for cross-functional air cover

Escalate risks and trade-offs where no individual team owns enough of the system to unblock it.

Quarterly OKRsShared discovery-to-apply reviewsClearer accountabilityAgency reporting closer to business outcomes

This converted SEO from a channel-specific activity into a cross-functional product-growth system.

07 · Outcomes

Growth improved at multiple layers of the system.

Group A — Business / Marketplace Outcomes

+131%

Organic applies

+29%

Total applies

Group B — Funnel & Product Signals

+50%

Organic SRP/JDP traffic

+30%

Organic registrations

3.7 → 4.8

Daily mobile applications per user

Group C — Foundation / Enabling Metrics

~650K → ~2.5M

Indexed pages

3.0s → 1.8s

P90 Search API latency

+15%

Recruiter-searchable candidate profiles

A supporting marketplace-supply signal, not a business outcome or a causal driver of organic applies.

Group D — Operating-Model Changes

One discovery-to-apply KPI systemUnified core SRP / JDP foundationsShared weekly execution cadenceQuarterly cross-functional OKRsStronger visibility of technical dependencies

The +131% organic-apply and +29% total-apply results were measured after the job-listing improvements, with impact visible shortly after launch. Crawl, indexation and broader SEO recovery accumulated over a longer period.

Application volume was measured more clearly than downstream application quality and recruiter response.

08 · Reflection

Growth problems often sit across organisational boundaries.

01 · What worked

Fixing crawlability, shared search foundations and latency before scaling traffic or redesigning conversion created a stronger dependency sequence.

02 · What I would change

I would establish the shared KPI tree, ownership model and review cadence at the beginning rather than after diagnosing the workstreams separately.

03 · What remained under-measured

I would add application-quality, recruiter-response and downstream marketplace-value measures earlier so growth in application volume could be evaluated beyond seeker-side conversion.

04 · What I took forward

Better roadmaps were insufficient until ownership, metrics and decision cadence matched the full customer journey.

SEO was not a marketing channel problem. It was a product infrastructure and ownership problem.

Next case study

Building EatSure from aggregator dependence to a scaled D2C business