All projects

Case study · SmartSchool Education

SNL Solution

Frontend Developer · Jul – Oct 2026

A redesign of the SNL Solutions website. SNL sells smart classroom equipment to schools across India. Version 2 has 27 pages, scored 94–99 for phone speed when tested in September, and makes it easy to compare products.

Pages Built
27
Phone Speed Score
94–99
Smaller Than First Build
up to 91%

Project overview

Home page

SNL Solutions sells smart boards, all-in-one computers, classroom cameras and digital signs to schools across India. I redesigned its website. Version 1 was the previous site. Version 2 is my redesign, now live at snlsolution.com: 27 pages with one clean look, product pages where you pick a model and see its exact specs, studio setup pages, and pages that load fast on a phone.

Project type
Website redesign
Client
SmartSchool Education (SNL Solutions)
My role
Frontend Developer
Timeline
Jul – Oct 2026
Team
I built the front end. The company's own developer runs the live server.
Pages
27 pages
Key feature
Pick a model and see its exact specs

Tools Used

Technologies, platforms, and tools used to design, develop, and deliver this project.

  • PHP, a server-side language
  • JavaScript, the language of the web
  • CSS3, the styling language of web pages
  • JSON-LD, structured data for search engines
  • Lighthouse, Google's page-quality audit tool
  • Vercel, hosting and deployment

The challenge

Schools compare sizes and specs before they call. The website has to make that easy, build trust, and lead to an inquiry.

  • The old website

    • Each smart board size has its own page, so comparing two sizes means going back and forth.
    • The menu goes three levels deep, and the pages use older tools (Bootstrap and jQuery).
    • Search engines were not given the basics: no sitemap, no canonical addresses, and unknown addresses answered “OK”.
    • Exact specs sat on separate pages, so there was no single place to see them side by side.
  • The business

    • SNL sells smart boards, all-in-one computers, classroom cameras and digital signs to schools across India, and installs turnkey studios.
    • The goal is inquiries, not online sales. The buy buttons link out to SNL's Amazon.in listings.
    • Buyers need real specs, certificates and installations before they trust a company they haven't met.
    • Schools compare sizes and specs before they call, so the answer has to be on the page.
  • The build

    • No frameworks, because the company's own code is PHP.
    • Every product claim must come from a real spec sheet.
    • The live site runs on a separate server I can't push to, so my changes reach it as packages.
    • Every page has to load fast on a phone and be easy for search engines and AI tools to read.
  • What I wanted to improve

    • Make it easy to compare models and see exact specs.
    • Give every page one clean look, the Studio Setup pages included.
    • Build trust with certificates, clients and real factory photos.
    • Keep a clear way to book a demo on every page.
Frontend Development Lifecycle · Step 1 of 8

Planning around the company's PHP and a server I can't push to

The brief became three technical rules: no framework, because the company's own code is PHP; every product claim traceable to a spec sheet; and nothing assumed about the live server.

  • Tools

    Plain PHP, hand-written CSS and vanilla JavaScript. There is no framework and no build step, because the company's own code is PHP.

  • Start from the sister brand, and flag what can't be checked

    The pages started from the sister brand's design system and page structure, rebranded for SNL. Anything that could not be checked for SNL, such as figures, history, testimonials and legal text, is flagged in the page notes instead of being published silently.

  • Two destinations, one rule

    Version 2 deploys from git to a preview site. The company's own server changes only through a package its developer applies, so before writing anything for that server I ask for his current files. Version 2 is now the live site at snlsolution.com.

Frontend Development Lifecycle · Step 2 of 8

Architecture: one PHP file per page, shared parts

Version 2 uses the company's own kind of code, so it can be handed over and dropped in.

  • 27

    Pages

  • 1,479

    Questions answered

  • 106

    Icons, stored on the site

  • 1

    Server functions on Vercel

  • Shared parts

    Every page is one PHP file that pulls in the same header and footer, plus one top-section function that takes a title, text and buttons. A page's own styles load only on that page.

  • Content and data

    There is no CMS or database. Each page keeps its questions in one list in the code, and that one list draws both the visible answers and the data search engines read, so the two can't disagree.

  • Where things live

    The pages sit in the project root. Shared PHP and the structured data for each page live in one folder, and the styles, scripts, images, videos, fonts and vendored libraries in another. Pages and files taken out of use go to an archive folder that is never deployed.

Frontend Development Lifecycle · Step 3 of 8

Building pickers, menus and the Studio Setup pages

  • Built for phones first

    One set of screen widths, 360, 480, 768, 1024 and 1280 px, designed from the phone up. The menu turns into a drawer on small screens, and full-height sections use the visible screen height so phone address bars don't cut them off.

  • A small motion layer

    Fade-and-slide reveals, hover lifts and menu transitions. It moves only opacity and position, watches one marker instead of listening to scrolling, and switches off for reduced motion. The dot-and-line top background loads only on wider screens, once the browser is idle.

  • Pick a model, see exact specs

    Flat panel sizes, all-in-one processors, camera models and sign sizes each have a picker. A blank cell on a spec sheet shows a dash instead of an invented value.

  • Searchable questions

    Every page with questions has at least 60, such as 72 on the all-in-one PC page and 68 on the PTZ camera page, with category tabs and a search box. Where a sheet says nothing, the answer says so.

  • Studio Setup

    A hub and six studio pages (smart class, hybrid, podcast, YouTube, conference and green screen), each with its own equipment list, installation steps and questions.

  • A slot-in PC for the flat panel

    The SNL OPS page explains the optional Windows module that slides into a flat panel, with a ports table that fits a phone.

  • A menu that stays on screen

    Flyout menus flip sides so they never leave the screen. On a phone, Escape closes the drawer and puts focus back on the menu button.

  • Trust badges

    Three short looping videos (GeM, Make in India and CMMI Level 5) that load only when the footer is near.

  • Pay online

    A footer pop-up with a payment link and a QR code.

  • Certificates and downloads

    A certificates page and a downloads page with filter tabs. Photo galleries open in a lightbox that loads only when needed.

Frontend Development Lifecycle · Step 4 of 8

Feeds, WhatsApp, the Amazon store and maps

Version 2 has no database or CMS of its own. It reads the company's feeds and hands the rest to other services, and none of these connections can leave a page empty.

  • Blogs and newsroom from the company's feeds

    The Blogs and Newsroom pages load from the company's blog and news feeds, cached for an hour, with a saved copy as backup. Visitors see the company's own posts and stories with a category filter, even if a feed is slow.

  • Contact by WhatsApp

    The Get in Touch form opens a ready-written WhatsApp message.

  • One store link, one helper

    Product pages link out to SNL's store on Amazon.in through one shared setting and one helper, so changing the store address is a one-line edit.

  • Maps are the only outside requests

    The Google Maps embeds are the only outside requests left on the site, and they load only when someone taps.

Frontend Development Lifecycle · Step 5 of 8

Speed work and proof that nothing changed

Speed work measured with Lighthouse on a phone setup, and a way to prove that a change did not alter what a page looks like or does. The measured results are under Results.

  • Prove it, don't eyeball it

    I drive the site in a headless browser from a script. For a visual change I compare measured styles and positions with a frozen copy of the previous commit. For behavior I use real key presses and check what is under the pointer. Screenshots are for looking at, and numbers are for checking.

  • Page weight first

    Lighthouse scores and timings moved a lot between identical runs on a busy machine, so I trusted page size, request count and outside connections, which do not wobble. A move of less than about 5 points or 300 ms I treated as noise.

What the checks found

  • Problem

    My first speed test found the smart board page was 7.2 MB, mostly one video, and every page loaded fonts and icons from other websites.

    Solution

    I shrank videos and photos for phones, hosted fonts and icons on the site, and made maps load only when tapped.

    Result

    The smart board page went from 7,151 KB to 672 KB, and the home page from 2,290 KB to 480 KB.

  • Problem

    I split a large script to help phones load faster, but that could change how the animation looks.

    Solution

    I built a test that replays the animation frame by frame and compares it with the old one.

    Result

    57 of 66 checks matched exactly. The other 9 were changes I meant to make.

  • Problem

    The copied stylesheet carried rules that no page used.

    Solution

    I removed 1,392 unused style rules, then checked that nothing changed on screen.

    Result

    A lighter stylesheet with no visible change.

  • Problem

    On phones, the “Why choose” cards were squeezed into two columns about 85 px wide, and a comparison table ran off the screen with its last column out of sight.

    Solution

    A one-column rule for phones existed, but a later four-column rule overrode it. I fixed the order of the rules and fitted the tables to the phone width.

    Result

    Both now fit a phone with nothing to scroll sideways.

The Lighthouse figures here are from 26 September 2026. I have not measured again since, so they describe that day.

Frontend Development Lifecycle · Step 6 of 8

Technical SEO, structured data and AI crawlers

Rankings happen on the company's own domain, snlsolution.com, which I can't deploy to, so my work reaches search engines only as a package its developer applies. I made every page easy for search engines and AI tools to read, and checked it with a crawl of the running build on 6 October 2026.

  • 27

    Pages checked

  • 18

    Open to search engines

  • 9

    Held back on purpose

  • 1,479

    Questions answered on 24 pages

  • Every page says what it is

    Each page has its own title of about 50 to 60 characters, a description of about 140 to 160, a share preview and one main heading. None of the 27 pages shares a title with another.

  • One set of data per page

    A single helper builds what every page tells search engines: the company, the website, the page itself (typed as About, Contact or a collection where it fits), a breadcrumb trail and the question list. I added no product or review markup, because there is no first-party price or review data to back it and Search Console would flag it as errors.

  • Questions that match what people type

    Every page that has questions has at least 60: 72 on the all-in-one PC page, 68 each on the PTZ camera and digital signage pages and 67 on the flat panel page. Google retired the special search result for question lists on 7 May 2026, so the markup earns no extra feature. The value is the words on the page, which now include the phrases that were missing.

  • Open to AI tools

    robots.txt names the main AI search crawlers, such as ChatGPT, Claude and Perplexity, and welcomes them. The sitemap and robots.txt are built from one page list, so they never hard-code a domain, and a plain llms.txt file says in words what the company sells.

  • A check that catches drift

    A small script crawls the running site and compares every page's title, description, canonical address, robots rule, main heading, data types and question count with a saved snapshot. It flags a change that would hurt search, so a copy edit can't quietly break a page.

  • Held back on purpose

    The seven Studio Setup pages stay out of search until the owner replaces five placeholder testimonials with real quotes, and the Development Center page is held back by the owner's decision. The Experience Center is a coming-soon page.

The keyword map

Brand searches already bring people in, so every title keeps the SNL name. Each page then aims at one main group of phrases, taken from the Search Console data, so pages don't compete with each other.

snl solutionssnl boardsnl computerssnl smart boardsnl all in one pc
  • Interactive flat panel

    smart board, interactive flat panel, IFP price, best interactive panel in India

  • All-in-one PC

    all in one pc for schools, all in one pc under 50000, computer lab

  • PTZ camera

    camera for classroom recording, PTZ camera India

  • Digital signage

    school digital signage, digital notice board

  • SNL OPS

    OPS module, slot-in PC

  • Studio Setup and six studios

    studio setup, podcast studio, YouTube studio, green screen studio (held back from search for now)

What the audit found

The 3 October check of the live site found problems that only the company's own server can fix, so each fix here is a file its developer has to apply.

  • Found

    Any address, even one that does not exist, answered “OK” with a normal page.

    Fix

    Version 2 sends a real 404 for an address that does not exist, such as a studio that isn't there.

    Result

    Done in the build. The live server still needs the same rule.

  • Found

    No sitemap, and robots.txt had no sitemap line.

    Fix

    Both files are built from one page list, with the production addresses.

    Result

    Ready. The company's developer deploys them and submits the sitemap in Search Console.

  • Found

    No canonical addresses, and two addresses served the same all-in-one page.

    Fix

    Every page names one canonical address, the one it would have on snlsolution.com. The all-in-one page uses /all_in_one, the address Search Console already shows ranking.

    Result

    In every page of my build. snlsolution.com now serves Version 2, and I have not re-checked each address there.

  • Found

    Contact and About showed the home page's title.

    Fix

    Each page has its own title and description.

    Result

    All 27 pages have a title no other page shares.

What every page carries

  • A short title and a description that says what the page offers.
  • One main heading, printed by the shared top section.
  • One canonical address on snlsolution.com.
  • A share preview with title, description and image.
  • One set of structured data that matches the visible page.

Version 2 went live on snlsolution.com after this was written, and the Search Console data here comes from before that, so I quote no rankings or clicks for the redesign. What I can say is coverage: what each page tells search engines and AI tools in my build.

Frontend Development Lifecycle · Step 7 of 8

One gateway function, caching and the hand-off

I built and reviewed Version 2 on Vercel from one repository. The real site, snlsolution.com, is a separate server run by the company's developer, and it changes only through a package he applies.

  • Hosting

    The review copy runs on Vercel through one PHP function that routes every page. Files get a new address on every update, so nobody sees an old version. The company's own server is separate, so my changes reach it as packages its developer applies.

  • Caching

    The edge keeps a page for 5 minutes and may show an older copy for up to a day while it fetches a fresh one. Stylesheets and scripts are cached for a year, because each deploy gives their links the deploy's commit number. Images and videos are cached for 30 days, so a replaced image gets a new file name.

  • Security headers, and no source leaks

    Every response carries four security headers. Only the gateway function runs PHP, so any other PHP file that reached the host would be shown as plain text. To prevent that, every page has a route, an address ending in .php/ answers 404, the include and data folders answer 404, and notes, archives and design mockups are kept out of the upload.

From address to page

  1. A visitor opens an address
  2. Vercel sends it to one gateway function
  3. The gateway runs that page's PHP file
  4. The page pulls in the shared header, top section and footer
  5. The browser loads only that page's styles and scripts
Frontend Development Lifecycle · Step 8 of 8

Incidents, reversals and clean-ups

  • Problem

    One day every page broke after a deploy. The error looked like a bug in someone else's tool, and I spent a day on that.

    Solution

    Comparing my setup with a similar site that still worked showed the real cause: a large video folder I had forgotten to leave out of the build.

    Result

    One line fixed it.

  • Problem

    I was asked to keep only front-end code, so I turned every page into plain HTML.

    Solution

    I explained the trade-offs. It became clear the real goal was speed, not removing PHP, so I undid it the same day and got the speed another way.

    Result

    The site stayed on the company's PHP setup and still got faster.

  • Problem

    The pages I copied from the sister brand had claims that didn't match SNL's own spec sheet.

    Solution

    I wrote the product answers from SNL's sheets, said so where a sheet is silent, and marked the rest for the owner.

    Result

    Product pages now carry only claims that trace to a sheet. Open items are listed for the owner.

  • Problem

    Over time the project folder collected files no page used, including old videos and photos.

    Solution

    I checked every file twice, once by scanning the code and once by crawling the running site, then moved the unused ones to an archive folder that is never deployed.

    Result

    94 images (92 MB) and 23 videos (283 MB) left the deployed folder, and nothing on screen changed.

See the Design Lifecycle: how the experience was structured, the visual direction and the final screens.

The final result

Version 2 is now the company's public website, live at snlsolution.com. The screens below are from my build of 6 October, taken before launch, so the live pages may differ in small ways. Version 1 is the site it replaced.

Version 2 home page on desktop
Home page
Version 2 all-in-one PC page on desktop
Product page with the processor picker
Version 2 Studio Setup page on desktop
Studio Setup, the six studio cards
Version 2 home page on a phone
Version 2 all-in-one PC page on a phone
Version 2 Studio Setup page on a phone

Results

  • Smart board page size

    672 KB

    Was 7,151 KB

  • Home page size

    480 KB

    Was 2,290 KB

  • Lowest phone speed score

    94

    Was 82

  • Longest wait before a page responds

    104 ms

    Was 502 ms

Measured on 26 September 2026 with Google Lighthouse on a phone setup with slow 4G, taking the middle of three runs, across nine pages. Page size is the data loaded on the first visit. “Was” means the new pages before my speed work, not Version 1. Pages got smaller everywhere, but the main content showed up 0.2–0.4 seconds later on some pages. Since then I replaced the flat panel page's photo gallery, added the Studio Setup pages and changed the top section, and I have not measured again, so these figures describe that day.

What changed for visitors

  • A visitor can compare models and read exact specs without leaving the page.
  • All 27 pages share one look, so the site reads as one brand.
  • Product answers come from SNL's own spec sheets, and gaps say so.
  • On 26 September every measured page scored between 94 and 99 for phone speed.
  • Search engines get a sitemap, a canonical address and their own title for every page.

There are no traffic, conversion or bounce-rate numbers for Version 2, because it only just replaced Version 1 on the company's own web address and I have no visitor data for it yet. The Search Console data in the research section is about Version 1. I would rather show that gap than invent numbers.

What I learned

  • Design

    • Buyers ask “which one is right for me?” first, so the picker comes before the long text.
    • Saying “the sheet doesn't list this” earns more trust than a confident guess.
    • Reusing a sister brand's design saved weeks, but it brought its weight and its claims too. Check both before you reuse.
    • Name colors by the job they do. Moving the whole site from dark pages to light ones, and from orange to a gradient, took one block of code.
  • Building

    • Compare before you blame. A similar site that still worked showed my own mistake faster than a day of doubting the tool.
    • Prove a change, don't just look. A frame-by-frame test settled what my eyes could not.
    • Know who controls the live site, say which version something is on, and ask for the current files before writing anything for it.
    • Check unused files twice, by code and by running the site, before moving them.
  • Working with others

    • Ask what the goal is. The request to remove PHP was really a request for speed.
    • Flag what you can't confirm. The owner decides on figures, testimonials and the warranty term.
  • What I'd improve

    • Replace the five placeholder testimonials on Studio Setup with real quotes, so those pages can be shown to search engines.
    • Check the studio pages' equipment claims against the spec sheets before they go public.
    • Fix the trade-off where the main content showed 0.2–0.4 seconds later on some pages, and measure every page again.
    • Connect the demo form to the company's inbox. It needs server code that I can't reach from here.
    • Set up an Analytics key event for the demo and contact buttons, so visits can be tied to inquiries.
    • Replace the sister brand's figures and testimonials with SNL's own, once the owner confirms them.

My part

  • What I designed

    • SNL's version of the sister brand's design: wordmark, the mint-to-blue gradient and light pages with dark bands.
    • The shared top section and the small motion layer.
    • How the four product pages and the Studio Setup pages are organized.
  • What I built

    • All 27 pages, from the shared header and footer to the model pickers and the studio pages.
    • 1,479 questions and answers on 24 pages, the product ones written from the spec sheets.
    • The search data on every page, the sitemap and robots files, and the check that catches drift.
    • The speed work, the frame-by-frame test and the Vercel hosting.
  • Provided by others

    • The design system and page structure, from the sister brand Study'n'Learn.
    • The mint-to-blue gradient, from a reference image the owner supplied.
    • The spec sheets, product photos and company text, from SNL.
    • The live site's server and domain, run by the company's own developer.

On everyscreen

The portfolio home page on an iPhone

iPhone

The portfolio home page on a tablet

Tablet

The portfolio home page on an Android phone

Android

You may also like

StudynLearn screenshot

A smart classroom website: smart boards from 55 to 98 inches, AI teaching software and a national Olympiad. I built 21 pages on one design and cut the video and photo weight by about half.

EGN ConnectX screenshot

The official website for India's big education leadership summit. People can register, book stalls and nominate for awards, and explore the venue in an interactive 3D floor plan. Over 20,000 visitors are expected.