How we built an ATS-optimising résumé platform with cost-smart AI routing and a programmatic SEO engine for India
A career AI product that routes each task to the cheapest model tier that can do it well — cutting inference cost without degrading output — with a programmatic SEO layer capturing high-intent job-search traffic in India.
Visit the live productThe problem
Most résumé builders optimise for aesthetics. ATS systems — which screen 75% of applications before a human ever reads them — optimise for structured data, keyword density, and clean parsing. A beautifully designed PDF that an ATS reads as a single unstructured text block is a résumé that never reaches a recruiter.
For the Indian market specifically, the vocabulary of "résumé optimisation" does not match how job seekers actually search. Users search for Naukri format, company-specific CV formats, and ATS-friendly templates by company name — not generic "résumé builder" terms that the big incumbents already own.
And on the infrastructure side, running a powerful model for every single task — even a simple formatting check — makes the economics unworkable at scale.
The architecture
- Next.js (App Router) on Vercel, standalone from any sibling product — no shared backend, no proxy through other domains.
- A cost-smart routing layer sends high-volume, lower-complexity work (ATS scoring, keyword extraction, formatting) to a fast, inexpensive model tier and reserves the frontier tier for nuanced rewrites and cover-letter generation, cutting per-request inference cost without degrading output quality. Routing is configurable per task without a deployment, which is what let the product consolidate onto a single vendor later without touching call sites.
- A programmatic SEO engine generates keyword-specific landing pages targeting Naukri-ATS queries and company-format clusters — the proven high-intent demand surface for Indian job seekers.
- Canonical host is enforced as WWW; all apex traffic 308-redirects. The robots.ts file was hardened to emit the www canonical, fixing an indexation stall caused by stripped-www canonicals being emitted during an earlier phase.
- Payments run on Razorpay for international card checkout; OG images are rendered server-side on the nodejs runtime (not edge, which breaks font fetching) using a shared renderOgCard utility with bundled fonts.
The AI stack
Engineering challenges
Routing between models without exposing it to users
Users care about output quality, not which model produced it. We built a routing layer that dispatches by task type — a fast tier handles the high-volume checks, a frontier tier handles the rewrites where tone and nuance matter. The split is invisible to the user and configurable without a deployment, which is exactly why the product could later consolidate onto one vendor by changing config rather than code.
Capturing India-specific search intent
Generic "résumé builder" is a saturated keyword dominated by global incumbents. We built programmatic clusters around the demand patterns Indian job seekers actually use: Naukri-compatible format, company-specific CV templates (Infosys, TCS, Wipro format résumé), and ATS-pass queries. These are high-intent, lower-competition, and directly map to what our builder produces.
Canonical stall from stripped-www robots output
After launch, GSC indexation stalled. The cause was robots.ts emitting apex-domain canonicals instead of www canonicals, so Google's crawl saw a signal that the www pages were duplicates. We enforced www as the canonical host end-to-end — robots.ts, next.config redirects, and sitemap — and re-submitted. Indexation recovered.
OG images breaking on edge runtime
The initial OG image route used the edge runtime, which cannot fetch external fonts at render time. Images rendered with the system fallback font and looked broken in link previews. We moved the route to the nodejs runtime and bundled the fonts directly, keeping OG copy to two lines to fit cleanly in every preview format.
The result
- Cost-smart routing delivers nuanced AI output at lower per-request cost by matching model tier to task complexity.
- Programmatic SEO clusters capture high-intent Indian job-seeker queries that global incumbents do not target.
- Canonical enforcement and robots.ts fix unblocked GSC indexation after an apex-www mismatch stalled crawls.
- OG images render correctly across all link previews after moving to the nodejs runtime with bundled fonts.
Lessons we'd bring to your build
- Route by task, not by product — not every feature needs the most powerful model, and the cost difference compounds fast.
- For regional markets, do keyword research in the user's actual search vocabulary, not the category vocabulary the incumbents own.
- Canonical infrastructure (robots, sitemap, redirects) must all agree — one mismatched signal is enough to stall indexation.
- Edge runtime is fast but constrained; font-dependent renders belong on nodejs, not edge.
Planning something like this?
We bring the same production discipline to client builds. Tell us the problem you're solving and we'll map an approach.
Book a discovery call