All projects

Case study · SmartSchool Education Pvt. Ltd.

StudynLearn

Frontend Developer · Jun – Sep 2026

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.

Pages Built
21
Questions Answered
61
Video Weight Cut
52%

Project overview

Home page

StudynLearn helps schools, colleges and coaching centers across India set up smart classrooms: smart boards from 55 to 98 inches, AI teaching software and the SNOT national Olympiad. I built the front end with PHP and JavaScript, tested it on Vercel, and made it easy for Google and AI tools to read.

Project type
Website redesign and build
Client
SmartSchool Education Pvt. Ltd.
My role
Frontend Developer
Timeline
Jun – Sep 2026
Team
I built the front end. The company's server developer owns the live site and applies my changes by hand.
Pages
21 pages
Key feature
Five flat panel sizes, 55 to 98 inches, with a size picker and spec table

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
  • WebGL, 3D graphics in the browser
  • JSON-LD, structured data for search engines
  • Vercel, hosting and deployment

The challenge

StudynLearn sells smart boards, AI teaching software and a national Olympiad to schools, colleges and coaching centers. One website has to serve very different visitors and earn their trust before they call.

  • The website

    • A content check found the site answered too few of the questions buyers ask, such as price, full specs and comparisons.
    • The headline promised help for four kinds of visitors but gave them one message.
    • Each product needed its own page with the same look and behavior.
    • Schools, colleges, coaching centers and a national Olympiad are served from one set of pages.
  • The business

    • It competes with Teachmint, Next Education, LEAD Group, Extramarks, BenQ and ViewSonic, each stronger in some way.
    • Buyers spend a lot, so they want certificates, a government listing and proof from other schools.
    • It sells hardware, software and an exam, so the home page has to point each visitor the right way.
    • Trust has to be earned before the call, so the page must do the convincing a salesperson would.
  • The build

    • The live site runs on a separate server that I can't push to, so my work reaches it as hand-off packages.
    • I build the front end only. There is no database on my side.
    • Videos and photos were heavy: 437 MB of video across 31 files.
    • Pages have to stay light enough for phones despite that media.
  • What I wanted to improve

    • Answer buyer questions on the page: specs, sizes, comparisons and FAQs.
    • Speak to each kind of visitor, with its own clear page for every product under one design.
    • Show proof: certificates, clients and testimonials.
    • Be easy for Google and AI tools to read.
Frontend Development Lifecycle · Step 1 of 8

Planning plain PHP, one list of questions and two folders

Two constraints drove the technical decisions: buyers need their questions answered on the page, and the company's own developer has to be able to take the files as they are.

  • Tools

    PHP and vanilla JavaScript, with no jQuery, and hand-written CSS with shared values. Bootstrap's grid is used on one page only. Icons come from Lucide and Font Awesome, and galleries use a lightbox library.

  • Questions kept in one place

    Each page's questions live in one list that draws both the visible accordion and the search-engine markup, so the two can't drift apart.

  • A working copy and a hand-off package, kept apart

    The repository holds a front-end-only working copy that runs on my machine and on Vercel. The company's server developer's own versions of the files live in a separate hand-off folder that is never served, and the two are never merged into one.

Frontend Development Lifecycle · Step 2 of 8

Architecture: one PHP file per page, one shared stylesheet

The front end is plain and small on purpose, so the company's developer can take it as it is.

  • 21

    pages, each one PHP file

  • 1

    shared stylesheet, plus one per page

  • 0

    databases

  • Structure

    Every page is one PHP file with the same header and footer. Everything else is static content plus PHP lists for questions, specs and testimonials. There is no database.

  • Styles and cache-busting

    A shared stylesheet holds the colors, spacing, header and footer, and each page has its own stylesheet. Pages link minified copies, which I regenerate by hand after each edit, and every stylesheet link carries a version tag that changes with the edit so browsers fetch the new file.

Frontend Development Lifecycle · Step 3 of 8

Building the menu, animations and product pages

  • Animations written from scratch

    I wrote the engines in plain JavaScript: one master frame loop, neural-network backgrounds, a drag carousel, a WebGL light-rays hero and a starfield hero. They pause when the tab is hidden and skip on phones under 768 px or for reduced motion.

  • Responsive layout

    The header becomes a floating pill with a rounded drawer on phones. One spacing value tightens at 992 px and again at 600 px, so every section gets the same rhythm.

  • Size picker and spec table

    Five flat panel sizes from 55 to 98 inches, each with photos and key specs, plus one table that compares every size side by side.

  • Flat panel versus projector

    A comparison table that answers a question buyers ask before they choose.

  • Searchable questions

    61 questions and answers on four pages (AI 21, flat panel 12, K-12 20, Olympiad 8) with category tabs, marked up for search engines.

  • The Olympiad page

    A landing page for the national Olympiad with ten subject cards, a three-month exam calendar by subject and its own questions.

  • A video series

    A page for 26 conversation episodes, each described for search engines as a video.

  • Testimonials

    A video carousel of customer stories and a lightbox for review screenshots.

  • Regional offices

    Nine regional offices can be filtered by zone.

  • Blog and downloads

    A blog with a case stories filter, and a downloads hub for apps, firmware and content.

  • A demo page with a chaptered video

    The Book a demo page holds the form and a demo video. The player sits on the left and a chapter list on the right, with a menu to pick 1080p, 720p or 480p. Chapter images are WebP. The three video files are served from studynlearn.com.

Frontend Development Lifecycle · Step 4 of 8

The blog feed and WhatsApp contact

The site reads one outside source and hands one task to another service. Both are built so a failure leaves the page working.

  • The blog, with two fallbacks

    Blog posts come from the company's WordPress blog, then a feed, then a saved list if both fail.

  • Contact through WhatsApp

    The contact form does not send an email. It opens WhatsApp with a ready-written message, so an inquiry reaches the company without a server on my side.

No analytics, Search Console or keyword tool is connected to this site yet.

Frontend Development Lifecycle · Step 5 of 8

Media weight, loading behavior and phone checks

Checks and clean-ups on media weight, loading and phone layout. These are file sizes and rendering fixes, not speed scores: I quote none, because I have no Lighthouse run for this site.

  • Loading behavior

    Gallery images load lazily and the hero image loads straight away. The icon and font stylesheets are loaded in a way that does not block the first paint, and the icon script is deferred.

  • A check after every edit

    After editing a PHP or CSS file I check the PHP for syntax errors and ask the local server for the page, to confirm it answers with a 200.

Fixes from checking weight and phones

  • Problem

    Heavy media: 437 MB of video in 31 files, 17.7 MB of photos, and two badge posters of 1.6 MB shown at a tiny size.

    Solution

    I re-encoded the videos, converted 304 images to WebP, and cut the posters and icons to the size they are shown.

    Result

    Video fell from 437 to 211 MB and images from 17.7 to 9.0 MB. The two posters went from 1.59 MB to 86 KB.

  • Problem

    On phones the screen went white and blinked when scrolling to the last case-story card.

    Solution

    I traced it to a page-height estimate that went stale at one screen width, and corrected the estimate at that width.

    Result

    The freeze is gone.

The video and image figures here are the state on 5 September 2026, when I measured them. The repository's video folder has since grown back to about 2 GB across 33 files (checked 20 October 2026), because the Book a demo videos were added: a 902 MB, a 708 MB and a 291 MB file. Those three files are served on studynlearn.com. So the heavy-media problem is not solved for good.

Frontend Development Lifecycle · Step 6 of 8

Technical SEO, question data and AI crawlers

Buyers search before they call, and more of them now ask an AI assistant, so I made every page easy for both to find and read. The work followed the 50-question ranking in the research section: price, sizes, comparisons and warranty come first.

  • 21

    pages, each with its own title and description

  • 19

    pages with a share preview

  • 61

    questions published as search-engine data

  • 2

    placeholder pages held back (noindex)

  • Every page says what it is

    Each of the 21 pages on studynlearn.com has its own title and description, and 19 of them also set a share preview (the card that appears when a link is pasted into a chat). The two placeholder pages, the development center and the experience center, are marked noindex, so they are hidden from search until they are ready. I checked these on the live site on 20 October 2026. Some titles and descriptions run longer than the usual 60 and 160 character guides, so that is still to tidy.

  • Questions that answer themselves

    The 61 questions on the AI, flat panel, K-12 and Olympiad pages (21, 12, 20 and 8) are also published as search-engine data, built from the same list that draws the visible question list, so the two can't drift apart. I rewrote the 8 Olympiad answers from about 20 words to 87–98 so each one makes sense when an AI assistant quotes it alone. I also fixed a bug that showed raw code such as — inside the published answers.

  • Product data in the words buyers type

    The flat panel is described to search engines with the other names buyers use: digital board, interactive whiteboard, smart panel board and touch screen board. Buyers rarely type the company's own product name.

  • Open to AI tools, with a plain summary

    The live robots.txt allows the main AI crawlers by name, such as GPTBot, ClaudeBot and PerplexityBot, plus Bingbot, and an llms.txt file tells AI tools in plain language what the company sells and who it is for. I corrected one line in it that still promised home page questions that no longer existed. The live sitemap is out of date: it lists 18 addresses, leaves out the K-12 page, and still names the earlier flat panel address.

What every page carries

  • A unique title and a description that says what the page offers.
  • One main heading.
  • A share preview with title, description and image.
  • A canonical address on studynlearn.com, so search engines know which copy counts.
  • Search-engine data that matches the page: product details on the home page, questions on four pages, and video details on the talks page.

The 12 flat panel questions are published as search-engine data on the new page at /studynlearn_ifp. The earlier page at /interactive-flat-panel has none, and its canonical tag points to the home page. No Search Console or keyword tool was connected, so I quote no rankings, clicks or search volumes. What I can say is coverage: what each page tells search engines and AI tools. Whether that moves rankings is not measured yet.

Frontend Development Lifecycle · Step 7 of 8

One Vercel function and the hand-off to the live server

studynlearn.com is served by a separate server, so a green Vercel build does not mean the live site changed. Vercel hosts the new build for review, and the finished changes reach the real server through a hand-off. The flat panel page shows why: the new page is live at /studynlearn_ifp, yet the live sitemap still lists the earlier address, because the server and its sitemap belong to the company's developer.

  • One function for every page

    Vercel runs the new build through one PHP function with a list of allowed pages. A new page needs two small entries: one in that list and one route.

  • Hand-off to the company's server

    The real domain runs on the company's own server, so I keep a hand-off folder that mirrors its file layout, and I list changed photos and videos separately from code.

  • Caching on the Vercel copy

    Stylesheets and scripts are cached for a day, fonts for a year, and images and videos for 30 days. The live server sent none when it was checked in September 2026, and its settings belong to the company's developer, so these apply to the Vercel copy only.

From address to page

  1. A visitor opens an address such as /studynlearn_ifp.
  2. vercel.json sends that address to one function, api/gateway.php, with the page's key.
  3. The gateway checks the key against its fixed list of pages. An unknown key gets a plain 404.
  4. The matching PHP file, kept in the project folder, builds the page.
  5. Vercel sends the page back. Every page runs through this one function.
Frontend Development Lifecycle · Step 8 of 8

Incidents and fixes

  • Problem

    Every deploy failed for more than two days in July 2026. The first design gave each page its own Vercel function and went over the free plan's limit of 12.

    Solution

    I moved to one gateway function that routes every page from a list of allowed pages.

    Result

    One function serves all the pages, and a new page needs only two small entries.

  • Problem

    Cards on some pages jumped up and down when the pointer rested near their bottom edge.

    Solution

    Lifting a card also moved the area that reacts to the pointer, so the card slipped out from under it, dropped back, and lifted again. I removed the lift everywhere and kept the shadow and border change.

    Result

    The jitter is gone, and there is a rule for every new card: never lift on hover.

  • Problem

    Two new animations didn't move after their first deploy, and there was no error.

    Solution

    A temporary “stop all animation” style was overriding them. I added the new animations to its exceptions, and later removed that kill switch and replaced it with a small phone-only motion budget.

    Result

    Motion returned, and it now follows one rule: off under 768 px or for reduced motion.

  • Problem

    My notes said the big videos were stored with Git LFS, but nothing was, so the repository grew. It was about 965 MB in August 2026 and is about 6 GB on 20 October 2026.

    Solution

    I checked the setup instead of trusting the note, corrected the docs, and wrote down the real fix. Moving videos to LFS rewrites history, so it needs a planned day.

    Result

    The docs now match reality. Git LFS is still not set up, so the fix itself is still open.

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

The final result

The new home page and the new flat panel page are both live on studynlearn.com, the flat panel page at /studynlearn_ifp. The earlier page is still served at /interactive-flat-panel, which the company's developer controls, and the live sitemap and the new page's canonical tag still name that address.

The new StudynLearn home page on desktop
Home page (live)
The new flat panel page on desktop with five size tabs
Flat panel page (live, new design)
The new StudynLearn home page on a phone
The new flat panel page on a phone

Results

  • Video weight

    211 MB

    Was 437 MB

  • Photo weight

    9.0 MB

    Was 17.7 MB

  • Two badge posters

    86 KB

    Was 1.59 MB

  • Twelve feature icons

    53 KB

    Was 279 KB

These are file sizes, measured on the day of each change between August and September 2026. They are not page-speed scores. I have no Lighthouse run or visitor numbers for this site, so I don't quote any.

What changed for visitors

  • The new pages share one design, so the site reads as one brand.
  • Visitors can compare five flat panel sizes side by side and find answers in 61 questions across four pages.
  • Each page has its own title, description and search data.
  • On the company's live domain, the new design runs on 21 pages. The earlier flat panel page is still served at its old address.

There are no traffic, ranking or conversion numbers, because no analytics or Search Console data was connected. Some company figures on the site, such as customer counts and exam dates, are still waiting for the owner to confirm, so I don't repeat them here.

What I learned

  • Design

    • A hover effect can break a layout. Lifting cards moved their hit area and caused jitter. Test with the pointer resting, not just passing.
    • Shared parts beat copies. Fixing the question list once fixed it on every page that shows it.
    • Dark sections carry impact and light sections carry reading. Mixing both keeps long pages easy on the eyes.
  • Building

    • Check the setup, not the note. I wrote down Git LFS as done, but nothing was tracked.
    • When something “does nothing”, look for a global override first.
    • Check minified files. One stray comment ending silently deleted a heading rule.
  • Working with others

    • Never send a file to someone else's server without their current version. My draft cache file could have overwritten their routing rules, so I pulled it, and I no longer propose changes to that file.
    • List changed photos and videos separately from code in every hand-off. Two updated photos were once missed that way.
    • A green Vercel build doesn't mean the live site changed. They are two separate copies.
  • What I'd improve

    • Move the videos to Git LFS on a planned day. The repository is now about 6 GB.
    • Add a real price or quote path and a visible WhatsApp number.
    • Get real names and roles for the ten testimonial videos.
    • Connect a keyword tool or Search Console so questions can be ranked by real volume.
    • Remove the dead styles that are still in three stylesheets.

My part

  • What I designed

    • The design system: colors, type, spacing and shared parts.
    • The floating menu and the top section with a product video.
    • The size picker, spec table and comparison tables.
  • What I built

    • 21 pages and the shared header and footer.
    • The animation engines, written from scratch.
    • 61 questions and answers and the search data on every page.
    • The Vercel setup and the hand-off process for the company's server.
  • Provided by others

    • Product photos and videos, spec sheets, certificates and company text, from the company.
    • Team headshots, supplied by the owner.
    • The live server and domain, run by the company's 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

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.

SNL Solution screenshot

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.