What I Learned Building a Production Website for a 30-Year-Old Offline Business

No spec. No PM. Just a client, WhatsApp, and a lot of figuring it out.

Most of my technical writing here has been about RAG pipelines, vector databases, and MCP servers — systems I built for myself, to learn, on my own timeline. This one’s different. This is a case study on the first project I built for someone else, with real constraints I didn’t get to choose, and a real non-technical stakeholder whose business actually depends on it working.

The client

Smart Art is an industrial art, signage, and custom painting business in the Kalwa Works area of Thane, Maharashtra, run by artist Anil Jadhav since 1990. Thirty-plus years of real craft, a registered vendor relationship with Siemens dating back to the business’s founding, and — until now — no digital presence at all. No website, no way to browse past work, no way to order without a phone call.

The actual problem, once I looked closer

The brief going in was “build us a website.” The real problem, once I understood how the business runs day to day, was narrower: customers order over WhatsApp, not through contact forms. A polished site with a “Contact Us” form nobody uses would have solved nothing. That reframing — from “build a website” to “make it easy to order the way customers already order” — shaped almost every decision after it, starting with routing every CTA on the site straight into a pre-filled WhatsApp message instead of a form submission.

Architecture

The site ended up as 9 route-level pages — Home, Industrial Services (with a dynamic detail route per service), Store (with a dynamic detail route per product), Gallery, About & Contact, Blog detail, and a proper 404 — built on React 18 with React Router 6 for client-side navigation and Framer Motion handling both page transitions and scroll-triggered reveals.

Underneath the pages sit 32 components split across UI primitives (buttons, cards, skeleton loaders, a floating WhatsApp button, back-to-top), layout (header with a pure-CSS hamburger menu, footer, an animated-routes wrapper), and 15 feature components specific to the homepage and gallery — things like an animated stats counter, a testimonials slider, and an infinite-scrolling client marquee.

Seven custom hooks do the actual load-bearing work rather than sitting as unused boilerplate: a throttled scroll tracker with direction detection, an intersection-observer hook powering every scroll-reveal animation on the site, a debounce hook for search/filter inputs, a localStorage sync hook, and a reactive media-query hook for responsive behavior driven from JavaScript rather than CSS alone.

Content and SEO

The content layer isn’t an afterthought bolted onto a template — it’s 8 fully-written blog articles (topics ranging from the history of Warli tribal art to a technical comparison of epoxy vs. PU floor coatings), a 59-image gallery organized across 7 categories with a masonry layout and lightbox viewer, and a dedicated SEO module that programmatically generates per-page meta tags, Open Graph and Twitter Card data, canonical URLs, and Schema.org JSON-LD (LocalBusiness and Service markup) for every route. This is the kind of SEO infrastructure a lot of small-business sites skip entirely, and it’s the difference between a site that looks good and a site that a search engine can actually understand.

A few decisions I’d make again

• PWA over a native app. A service worker with a cache-first strategy plus an installable manifest gives an offline-capable, app-like experience without the cost of building and maintaining an actual native app — the right tradeoff when most customers are on mobile data.
• Dual-channel contact submission. The form validates a proper Indian mobile number format and writes to Google Sheets via Apps Script, while also offering a direct WhatsApp path — covering both “I want a record of this” and “I want a reply right now.”
• No backend server for the contact flow. Google Apps Script as a serverless target means there’s nothing for a non-technical owner to maintain, and he can open a spreadsheet himself without needing me for every change.

What this taught me that solo projects hadn’t

Every project I’d built before this had one stakeholder: me. I picked the tech, the scope, the priorities, and if something was slightly wrong, no one but me ever knew. This one had a real client with a real business and zero technical background, which meant the hardest part of the project was never the React code — it was figuring out what he actually needed versus what a “modern website” is supposed to have. The WhatsApp-over-forms decision is the clearest example: it’s not something you’d find in a tutorial, it’s something you find by actually listening to how a business runs.

The site is built and handed off to the client, who’ll be publishing it on her own domain — I’ll update this post with the live link once it’s up. In the meantime, here’s a full walkthrough of the build: [recorded video]

A version of these features and this write-up will also go into my LinkedIn and resume — this is the first project I’ve shipped for an actual external client rather than for myself, and it’s changed how I think about what “done” means.

Update: Just received a signed testimonial from Anil Jadhav, the business owner: “She brought our legacy business into the digital age smoothly and professionally.” Genuinely more meaningful to me than any metric in this article — the whole point of the WhatsApp-over-forms decision was making sure it actually worked for him, and hearing that it did is the real result.