Commerce Insight Master Plan

What the audit found

Before planning anything, I read the existing site and the Review Engine. Four findings change the shape of this project, and one of them is urgent.

Facts carried over from the old site

These were in the previous build. They look genuine, but given what else that build invented, every one needs re-confirmation in writing before it goes near the new site.

The four decisions that shape everything after this

Final recommended sitemap

The brief proposed roughly fourteen top-level areas. I recommend nine. Thin pages hurt both trust and search rankings, and several of the proposed pages would launch nearly empty.

/                                  Home
├── /about                         Story, founder, philosophy, why CI
├── /courses                       All programmes
│   ├── /courses/class-11-commerce
│   ├── /courses/class-12-commerce
│   ├── /courses/ca-foundation
│   ├── /courses/ca-intermediate
│   └── /courses/cma
├── /results                       Results + toppers + student stories
│   └── /results/[year]            e.g. /results/2026
├── /faculty                       All mentors
│   └── /faculty/[slug]            Individual profile
├── /reviews                       Google reviews, from the engine
├── /videos                        YouTube library
├── /gallery                       Institute life
├── /contact                       NAP, map, directions, hours
└── /admissions                    Enquiry + admission process

Utility
/privacy · /terms · /sitemap.xml · /robots.txt · /opensearch
/admin/*                          Authenticated, noindex

Deferred until content exists (Section 23, Phase 6)
/resources · /resources/[slug]     Notes, exam updates, articles

What I merged, and why

Complete page inventory

Every route, its rendering strategy, its data source, and its single conversion goal. "Blocked" means the page cannot be built to a launchable standard until the client input in Section 22 arrives.

Homepage architecture

Section by section, with the job each one does and how it behaves when the evidence behind it is missing. The order follows the brief's recommended flow with two changes, both argued below.

Two changes from the brief's flow

Results moved above Why Commerce Insight. The brief places the value-proposition pillars before results. But pillars are claims and results are evidence, and evidence read first makes the claims that follow credible. Reversed, the pillars read as marketing the reader has to take on faith.

Videos moved above student stories. Video is the one piece of proof where a visitor can judge teaching quality directly, in seconds, without trusting anyone's word. It belongs higher than written stories.

Page-by-page UX strategy

What each page is for, what it must do differently from every other page, and the one decision it is trying to unblock.

/about — the founder page in disguise

The brief is right that a 300-word paragraph fails here. But the mistake most institute About pages make is describing the institute when readers want the person. Structure: a short statement of what Commerce Insight is → the founder's story at real length, with a photograph → teaching philosophy stated as method, not adjectives → the four differentiators → faculty preview → CTA. The YouTube channel belongs here too, as evidence the founder teaches publicly and can be judged before enrolment.

/courses — a comparison tool, not a list

A visitor arriving here is choosing between two or three options, so the page must support comparison rather than scrolling. Cards carry the same four fields in the same positions — who it's for, subjects, mode, duration — so the eye can scan a column. A short "not sure which?" prompt routes the genuinely undecided to WhatsApp rather than leaving them to guess.

/courses/[slug] — the highest-intent page on the site

Follows the brief's structure with one addition: "Who this is not for" placed immediately after "Who this is for". Naming who should not enrol is the single cheapest trust signal available to an institute, it costs nothing, and no competitor does it. Sticky bottom enquiry bar on mobile, pre-filled with the course name so the lead arrives attributed.

/results — make it auditable

Toppers band, then a full filterable table by year, programme and board. Table over cards for the body of the data: a table looks like a record and cards look like marketing, and here the reader is deciding whether to believe you. Each entry carries year, programme, board and score. Student stories sit at the bottom as depth for readers who want it.

/faculty — qualifications, not adjectives

Given Section 0's findings, this page gets the strictest content rule on the site: every claim must be a verifiable credential or an observable fact. "Ph.D., Economics, [university]" is publishable. "The Academic Edge" is not. Each profile carries subjects taught, qualifications, years teaching, and optionally a short statement in the mentor's own words.

/reviews — show the engine's honesty

Rating summary, distribution bars, full review list with owner replies, and — unusually — a quiet freshness line reading "Last updated [date]". Most sites hide this. Showing it is a trust signal precisely because it proves the reviews are synced rather than typed.

/videos, /gallery, /contact, /admissions

/videos: latest first, filtered by subject only once each filter has three or more videos. /gallery: masonry grid, category filters, keyboard-navigable lightbox, every image with real alt text. /contact: actions before information — call, WhatsApp, directions as large touch targets at the top, then hours, then map, then form. /admissions: process as a numbered sequence (numbered because it genuinely is one), then fees if the client publishes them, then the form.

Student journeys

Three real paths, each with the moment it typically fails and the design response.

A — the Instagram tap (highest volume)

Instagram bio link → / → hero → course finder → /courses/class-12-commerce
→ sticky bar → WhatsApp, course pre-filled

Fails at: the hero, on a mid-range phone over patchy mobile data. If the largest element takes four seconds, the visitor is gone before reading a word. Response: the hero is the performance budget's first claim — see Section 18.

B — the Google search (highest intent)

"ca foundation coaching pratap nagar" → /courses/ca-foundation (no homepage)
→ scan → /results → /reviews → back → enquire

Fails at: orientation. This visitor never saw the homepage, so a course page that assumes context loses them. Response: every course page opens by restating what Commerce Insight is in one line, and carries breadcrumbs and full contact access in the footer. Every deep page is treated as a potential entry point.

C — the researcher

Multiple visits over days → / → /faculty → /videos → watches
→ /results → /reviews → /gallery → /admissions → form

Fails at: nothing sudden — this journey fails by attrition when a page has nothing new to offer. Response: every page ends with a contextual next step rather than a generic CTA, and the video library gives this visitor a reason to return before deciding.

Parent journeys

Parents are usually the decision-makers and almost never the first visitors. They arrive second, sceptical, and looking for different things.

D — the verification visit

Student shows parent → parent opens later, alone → / → /faculty → /results
→ /reviews → /contact → calls (does not fill the form)

What a parent checks, in order: Is this a real place with a real address? Who teaches? What have their students actually scored? What do other parents say? Can I speak to someone now?

Design response. Four things matter for this visitor:

• The phone number is always reachable — in the header on desktop, in a sticky bar on mobile. Parents call. They do not fill forms.
• Faculty credentials are legible without jargon — qualification, subject, years teaching, stated plainly.
• Results read as a record, not a poster — the table format in Section 4 exists for this reader.
• Google reviews carry more weight than testimonials — a parent knows the institute cannot edit them. This is the strongest argument for prioritising the engine integration.

E — the WhatsApp forward

Parent receives a forwarded link → opens in the WhatsApp in-app browser
→ lands mid-page → judges in ~5 seconds

Fails at: the link preview and the in-app browser. A forward with no image and a truncated title reads as spam. Response: every page gets a deliberate Open Graph image and title (Section 17), and every page is verified in the WhatsApp and Instagram in-app browsers — not just Chrome — because that is where a large share of this audience actually reads the site.

Conversion strategy

One primary action per page, chosen to match where the reader actually is, plus a persistent low-friction escape hatch.

The persistent action

A single floating WhatsApp button, bottom-right, on every page except /admin. One button, brand-coloured rather than WhatsApp green so it does not fight the palette, with an aria-label and a real touch target. Its message is pre-filled with the page context, so an enquiry from /courses/ca-foundation arrives already saying which course.

Measuring it

Without measurement none of the above is more than an opinion. Minimum instrumentation at launch: WhatsApp clicks by source page, phone-tap clicks, form submissions by source page, course-page depth, and video plays. Section 18 covers doing this with a privacy-respecting, lightweight analytics tool rather than the full Google Analytics bundle.

Brand & design direction

Derived from the brief's description of the logo, and to be re-derived from the artwork itself once it arrives. This document is set in the proposed palette and typography, so it doubles as the first proof of the system.

The positioning idea

The record, not the pitch. Commerce is a discipline of ledgers, statements and audited numbers — work where a claim is only worth what its evidence supports. That is also, precisely, the problem with the old site. So the design direction and the content-integrity requirement come from the same place: a site that looks like a record and reads like a record is both more honest and more persuasive than one that looks like an advertisement.

Practically, this means ruled tables over floating cards where the content is data; generous white space over decorative fills; typographic hierarchy over colour to signal importance; and orange used the way an accountant uses a highlighter — rarely, and always to mean something.

Colour

Blue and white dominate; orange is reserved. The discipline is a ratio: roughly 60% white/paper, 30% blue, under 5% orange. If orange ever appears twice in one viewport, one of them is wrong.

The neutrals carry a slight blue bias throughout rather than being pure grey — it is a small thing that makes the palette read as one considered system instead of brand colours dropped onto a default template.

Typography

Two families, three roles. Source Serif 4 for display and headings — academic weight and editorial authority without period costume; it is what makes the site read as an institution rather than a startup. IBM Plex Sans for body and interface — institutional, highly legible at small sizes on Android, and a genuine complement rather than a neutral default. IBM Plex Mono for labels, eyebrows, scores and tabular data, which also gives numbers a deliberate treatment — appropriate for a commerce institute where numbers are the proof.

Both families are on Google Fonts, cover Latin comprehensively, and are subset and self-hosted at build time (Section 18). Notably, IBM Plex also has a Devanagari cut, so a future Hindi surface would not need a new typeface.

Motion

Three effects, total: a short fade-and-rise on band entry (16px, 320ms, once); a 120ms elevation change on card hover; and a count-up on the credibility strip only. Everything respects prefers-reduced-motion. No parallax, no scroll-jacking, no page transitions — page transitions in particular cost real perceived performance on the mid-range Android devices most of this audience uses.

Design system

Tokens first, components second. Every value below lives in one Tailwind theme file so a brand change is a single edit.

Scale and spacing

A 4px base unit with a restricted spacing set — 4 8 12 16 24 32 48 64 96 128. Restricting the set is the point: unrestricted spacing is how a site drifts into looking assembled rather than designed. Section padding is 64px mobile, 96px tablet, 128px desktop. Container max width 1200px, gutters 20/32/48.

Type scale

Body text never goes below 16px on mobile — below that, iOS Safari zooms on input focus and the layout jumps.

Other primitives

• Radius: 4px inputs and badges, 8px cards, 12px modals. Nothing fully rounded except avatars. The brief's warning about "excessive rounded cards" is a real one — heavy rounding is what makes a site read as a template.
• Elevation: three levels only, all blue-tinted rather than black, so shadows sit in the palette instead of muddying it.
• Borders: 1px rule is the default separator. This system prefers a rule to a shadow — it reads as a document.
• Buttons: primary (blue fill), secondary (blue outline), tertiary (text + underline), plus WhatsApp and Call as distinct icon-led variants. Minimum target 44×44px. Every state defined: rest, hover, active, focus-visible, disabled, loading.
• Forms: labels always visible above the field — never placeholder-as-label, which fails accessibility and memory both. Errors sit below the field, in words, tied by aria-describedby.

Component architecture

Three tiers. Server Components by default; 'use client' only where interaction genuinely requires it, which keeps the JavaScript budget in Section 18 achievable.

primitives/   no domain knowledge
  Button · Input · Select · Textarea · Badge · Tag · Card
  Dialog · Disclosure · Tabs · Skeleton · Rule · Prose

patterns/     composition, still domain-free
  Section · SectionHeader · Grid · Lightbox · Carousel
  Breadcrumbs · Pagination · FilterBar · EmptyState

domain/       knows Commerce Insight
  SiteHeader · SiteFooter · AnnouncementBar · Hero
  CredibilityStrip · CourseCard · CourseDetailLayout
  ResultsTable · TopperCard · FacultyCard · FacultyProfile
  ReviewCard · ReviewSummary · ReviewFreshness
  VideoCard · VideoGrid · StoryCard · GalleryGrid
  MapPanel · EnquiryForm · WhatsAppButton · StickyActionBar

Client-component boundary

Only these are client components: SiteHeader (mobile menu), FilterBar, Lightbox, EnquiryForm, Tabs, Dialog, and the count-up in CredibilityStrip. Everything else — including all review, video, result and course rendering — is server-rendered. Reviews and videos in particular arrive as HTML with zero client JavaScript, which is the entire performance argument for Next.js on this project.

Data model

PostgreSQL via Prisma. Deliberately small: only content that genuinely changes on a cadence, or that must be captured, gets a table.

Deliberately not in the database

Admin architecture

The brief wants a full CMS across twelve content areas. I recommend building roughly a third of that, and explaining the omission rather than quietly shipping it.

How it works

Auth.js with credentials, Argon2id hashes, HTTP-only session cookies, and a rate-limited login. No public sign-up — accounts are seeded. Everything under /admin is protected in middleware, returns noindex, and is excluded from the sitemap. Photo uploads go to Vercel Blob through a server-issued token, with MIME and size validated server-side and every image re-encoded with sharp so an uploaded file is never served back as it arrived.

The topper flow the brief describes is the design target: log in → Add Topper → upload photo → enter marks → confirm consent on record → publish, with the site reflecting it within the hour via revalidation. The consent step is not optional — Section 19 explains why.

Review Engine integration

The most technically interesting part of this project, and the one where the brief's proposed architecture should be simplified rather than followed.

Corrected architecture

Brief proposed:
  Google Business Profile → Review Engine → Backend → Database → Website

Recommended:
  Google Business Profile
        ↓  scheduled harvest, offline
  tp-reviews-engine → private ledger (state branch)
        ↓  publish gate
  reviews.json (public data branch, HTTPS)
        ↓  server-side fetch, revalidate 6h
  Next.js Server Component → HTML
        ↓
  Visitor  — zero client requests, never contacts Google

The engine already is the backend: it maintains the durable ledger, reconciles changes, and gates publication on invariants. Adding our own database between it and the site would fork the source of truth, bypass the publish gate the engine exists to enforce, and create a second thing that can be stale. We fetch the published payload and render it.

Implementation

The engine ships a Next.js App Router recipe. We follow its data contract but render with our own components rather than its reference DOM renderer — the bundled widget is deliberately unopinionated, and this site needs review cards that match the design system. What we do adopt from the kit is its safety discipline, which is well-reasoned:

• Review text is rendered as text, never as HTML. React escapes by default; the rule is that dangerouslySetInnerHTML never touches payload data. This is the kit's first safety rule and it is correct.
• Server-side fetch with next: { revalidate: 21600 } — matched to the harvest cadence, not to visitor traffic. Per-request fetching would turn a static file into load proportional to traffic.
• Reserve the container height before the payload renders, so no layout shift reaches Core Web Vitals.
• A failure is never the visitor's problem. If the fetch fails, the band does not render — no error text, no empty box.

Degraded states — and why we show them

The payload carries honest freshness signals that most integrations discard: notices, stats.completeness, and last_full_harvest_at. We surface them, quietly:

YouTube integration

Dynamic, server-side, and quota-aware. The naive implementation exhausts the daily quota and is the most common way this integration fails in production.

YouTube channel
   ↓  playlistItems.list on the uploads playlist — 1 quota unit
Server-side route, API key in env
   ↓  ISR, revalidate 6h + on-demand webhook
Next.js Server Component → HTML
   ↓
Visitor  — no YouTube JS until a video is actually played

• The API key never reaches the browser. Server-side only, in an environment variable, restricted to the YouTube Data API in Google Cloud.
• No YouTube iframe until play. We render our own thumbnail and title, and load the embed only on click — via youtube-nocookie.com. A YouTube iframe costs roughly half a megabyte and sets tracking cookies before the visitor has asked for anything.
• Graceful failure. API error, quota exhaustion, or fewer than three videos → the band does not render.
• Curated override. A small config array can pin specific videos ahead of chronological order — useful when the channel is young and the best video is not the newest.

Location & Maps

Pratap Nagar is a large sector. For a local institute, "can I find it and is it near me?" is a genuine conversion question, not a footer detail.

The location experience appears twice: as a band on the homepage and as the substance of /contact. Both render the same component reading the same config module, so the NAP cannot drift.

What it contains

• Actions before information. Get Directions, Call, WhatsApp as large targets at the top — Directions opens the native maps app on mobile via a geo:-aware Google Maps link, which is what people actually want.
• Full address exactly as it appears on the Google Business Profile, plus a human landmark line, because "Near Pannadhay Circle" is how people in Jaipur actually navigate.
• Opening hours as structured data and as readable text, with the current open/closed state computed server-side in IST.
• The map, loaded on interaction. A static styled map image or a lightweight placeholder renders first; the interactive embed loads on click. An eagerly-loaded Google Maps iframe is typically the heaviest thing on a page and it sits below the fold — there is no reason to pay for it on every visit.

Enquiry & lead system

Two capture paths, one lead record, and enough anti-abuse that the institute's inbox stays usable.

WhatsApp button  ──┐                    pre-filled, page-attributed
                   ├──→ lead
Enquiry form  ─────┘
     ↓ POST /api/enquiry  (Zod validated, rate limited, honeypot)
  Postgres Enquiry
     ↓
  Email notification → institute inbox
     ↓
  /admin/enquiries  status · notes · CSV export

Fields

Name, phone, class/level, course of interest, and an optional message. Nothing else. Every additional field measurably reduces completion, and none of the others are needed to make a follow-up call. Email is optional, not required — this audience converts on phone.

Abuse and integrity

• Server-side validation with Zod, including a real Indian mobile format check. Client validation is for the user's benefit only and is never trusted.
• Honeypot field plus a minimum time-to-submit — catches most naive bots at zero cost to real users.
• Rate limiting by IP on the route. Cloudflare Turnstile added only if spam actually materialises; a challenge on every form is friction paid in advance for a problem that may not arrive.
• Consent line above the button, with the submission timestamp stored as consentAt.

Email delivery via Resend or Postmark on the institute's own domain, with SPF and DKIM configured — notification emails sent from a Gmail address land in spam, which silently loses leads. The lead is written to the database before the email is attempted, so a mail failure never loses an enquiry.

SEO architecture

For a single-location institute, local search is nearly the whole game. National keyword ambition is a distraction; ranking for "commerce classes near Pannadhay Circle" is worth more than any generic term.

Priority

Implementation

• Metadata per route via the Next.js Metadata API — unique title and description on every page, no templated duplication.
• Structured data: EducationalOrganization + LocalBusiness on the homepage with NAP generated from the config module, Course on each course page, BreadcrumbList site-wide, VideoObject on /videos. No AggregateRating or Review — Section 13.
• NAP consistency is structural, because the footer, contact page, map and schema.org output all read the same typed module. Human error is designed out rather than watched for.
• Open Graph images per page, generated at build with the brand system. This matters more than usual here: Journey E in Section 6 is a WhatsApp forward, and the preview card is the first impression.
• sitemap.xml generated from actual routes, robots.txt disallowing /admin and /api, canonical URLs everywhere, one <h1> per page with a real heading hierarchy beneath it.

Off-site, which matters more than anything on-site here: a complete and active Google Business Profile with correct hours, categories and photos, and a steady flow of genuine reviews. The /reviews page's "Leave us a Google review" CTA feeds this loop directly — and the Review Engine then displays the result. That circuit is the highest-leverage thing in this entire plan.

Performance

Budgets, not aspirations. The target device is a mid-range Android phone on a congested mobile network in Jaipur — not a laptop on office wifi.

How the budgets are met

• Server Components by default. Reviews, videos, results and course content ship as HTML with no accompanying JavaScript. This is the single largest lever.
• Fonts subset and self-hosted at build via next/font, font-display: swap, preloaded for the two faces used above the fold. No render-blocking request to a third-party font host in production.
• Images through next/image — AVIF with WebP fallback, explicit dimensions on every image so CLS stays near zero, lazy below the fold, and the hero eagerly loaded with fetchPriority="high".
• Nothing third-party loads eagerly. The map, the YouTube embed and any chat widget load on interaction. Between them these are typically 80% of a coaching site's weight.
• ISR everywhere — pages are served from cache and revalidated on a schedule, so a visitor never waits on the reviews or YouTube fetch.
• Analytics via a lightweight, cookieless tool (Vercel Analytics or Plausible, ~1KB) rather than GA4's ~45KB. If GA4 is required for the client's reporting, it loads deferred and after interaction.

Budgets are enforced in CI with Lighthouse CI on pull requests, so a regression fails the build rather than being discovered months later.

Security

Standard web hygiene, plus one obligation specific to this project that most coaching sites get wrong.

Everything else

• Secrets in environment variables only — database URL, YouTube key, admin session secret, mail key, Blob token. Never in the repo, never in a NEXT_PUBLIC_ variable, and .env* in .gitignore from the first commit. A pre-commit secret scan is worth the five minutes it takes to configure.
• Admin auth: Argon2id, HTTP-only SameSite=Lax cookies, short session lifetime, rate-limited login with generic failure messages, no public registration, middleware-enforced route protection.
• Every input validated server-side with Zod, including admin forms. Prisma's parameterised queries handle SQL injection; the discipline is to never bypass them with raw SQL on user input.
• Uploads: server-issued tokens, MIME and size validated server-side, re-encoded with sharp, randomised filenames, served from Blob storage rather than the app origin.
• Headers: a real Content-Security-Policy (no unsafe-inline), HSTS, X-Content-Type-Options, Referrer-Policy, and a restrictive Permissions-Policy. Note the Review Engine's integration kit is explicitly built to work under a strict CSP — that alignment is deliberate on their part and we should not weaken the policy to accommodate anything else.
• Dependencies: minimal surface, Dependabot enabled, npm audit in CI.

Accessibility

Target WCAG 2.2 AA. Beyond the ethical case, an accessible site is a better site for the low-end devices and bright-sunlight conditions much of this audience browses in.

• Contrast verified against the final logo colours, not assumed. Brand oranges frequently fail AA as text on white — the plan is a darkened orange for text and the original for fills, verified rather than eyeballed.
• Semantic HTML throughout — real <nav>, <main>, <table> for the results table, buttons that are buttons and links that are links. This single discipline resolves most keyboard and screen-reader issues before they exist.
• Full keyboard operability — including the mobile menu, the gallery lightbox (Escape closes, arrows navigate, focus is trapped while open and restored on close), and every filter control.
• Visible focus states everywhere — a 2px brand-blue ring with offset. Never removed, only restyled.
• Forms: visible persistent labels, errors in text tied by aria-describedby, error summary focused on failed submit, no colour-only error signalling.
• Images: meaningful alt text written per image — "Class 12 students in the Pratap Nagar classroom", not "image1" — and empty alt on genuinely decorative ones.
• prefers-reduced-motion honoured for all three motion effects, including the count-up, which jumps to its final value.
• Skip-to-content link, correct language attribute, and a page title that identifies the page first.

Verification is automated (axe in CI) and manual — a full keyboard pass and a screen-reader pass on the homepage, a course page, the results table and the enquiry form. Automated tools catch perhaps 40% of real issues.

Responsive strategy

Mobile-first as a working method, not a label: every component is designed and built at 360px first, then allowed to expand.

Per-component behaviour

On course pages, mobile gets a sticky bottom action bar (Enquire + WhatsApp) once the reader passes the hero — the single highest-value mobile pattern on this site, because it removes the scroll-back that kills enquiries.

Testing includes the in-app browsers — WhatsApp, Instagram and Chrome on real Android hardware, not just devtools emulation. Journeys A and E in Sections 5 and 6 both land there, and in-app browsers have their own viewport and font-scaling quirks that emulation hides.

Client inputs required

The critical path. Nothing here is blocked on engineering, and most of the site cannot reach launch quality without it. Grouped by urgency.

Blocking — needed before design can be finalised

Blocking — needed before launch

Useful, not blocking

Instagram and other verified social handles; student stories with consent; event and achievement photographs; FAQs from questions actually asked on the phone; any notes or study material for the deferred resources section.

Development phases

Sequenced so that work blocked on client content never blocks work that isn't. Each phase has an exit gate.

Risks

Ordered by expected impact. The top four are all content or consent risks, not technical ones — which is the honest shape of this project.

Implementation roadmap

Sequenced by dependency rather than dated, because the true critical path runs through client content, not engineering. Engineering durations are estimates; the gates are firm.