ExperienceSoftware Developer Intern
Software Developer Intern

Prestar, Web Engineering team
Oct '25 - Feb '26 · 5 months
Case study
The Website Before the Product
Prestar was building a product and still working out the logistics of getting it to market. My term was on the public website for the company that would sell it - the landing pages that had to explain the product and move people toward it, built while the product itself was still taking shape.
Context
This is a short write-up of the work and what it taught me.
The product had not launched. There were already people paying attention - interested customers, people participating, investors - and the company needed a site that turned that attention into momentum toward the product, before there was a product to ship.
What the site had to do
I designed and built five pages end to end - Home, FAQ, About, Get Started, and Our Stories. Together they had one job: explain what the company was building and give a visitor a clear next step toward it.
Each was fully responsive, matched a reference layout down to its hover interactions, and stayed consistent between desktop and mobile - one design working on every screen, not two.
Building while the product was in flux
The product's details and go-to-market plan were still being worked out while I built the site. So the pages had to carry a value proposition that could survive the specifics changing under it, and the structure had to make swapping content - copy, sections, the Get Started flow - cheap as things firmed up.
Placeholder routes stood in for the parts of the flow that would become dynamic once the product and its systems existed, so wiring them up later would be a slot-in rather than a restructure.
One component set, five pages
Rather than style each page as a one-off, I built a set of reusable components the five pages share - a header, a card, a section layout, a call-to-action - defined once and used everywhere.
That is what kept the pages consistent, and it meant a visual change landed in one place instead of five.
The remote, async constraint
The hardest part was keeping a distributed team aligned on one visual language. Reference layouts and hover states had to be read the same way by everyone, without much back-and-forth to confirm. I leaned on tight, well-documented components as the shared source of truth - if the component was right, the page was right.
What I took from it
It sharpened how I turn a design reference into responsive, production-ready UI - working out what the reference is actually specifying across screen sizes, not pixel-copying.
And it was the first time I built a front-end whose job was conversion, not just correctness. A page that renders fine but does not move anyone toward the product has not done its job - a different bar than whether the component works.
Technology
Figma · Framer
Design and interaction references the pages were built from
Component-based front-end
A shared component set behind all five pages
Responsive layout
One design working desktop to mobile, not two
Route scaffolding
Placeholder routes for the flow that would become dynamic once the product existed
© 2026 Gaurav Divecha. All rights reserved.