QDORA

I'm Prasanth — a full-stack developer with about 12 years of experience, mostly in React, Next.js, and Firebase. A while back I decided to stop just building products for other people's businesses and build one of my own. That became QDORA (qdora.in) — an Indian e-commerce store selling imitation jewellery, women's dresses, menswear, and kidswear, shipped across India.

This post is less a launch announcement and more a log of what actually goes into running an e-commerce brand solo — the technical decisions, the SEO grind, and the stuff nobody tells you until you're the one debugging it at midnight.

Why build a store instead of a SaaS

Most indie hacker projects I see here are SaaS tools — which makes sense, they're easier to reason about, easier to charge for, easier to demo. I went a different direction on purpose. E-commerce forces you to deal with real inventory, real payments, real logistics, and real customers who don't care about your tech stack — they care whether their order arrives on time and looks like the photo.

That constraint has been useful. It's kept me honest about what actually matters: page speed, accurate product data, a checkout that doesn't break, and search visibility. No amount of clever architecture matters if a customer can't find the product or the page takes four seconds to load on a mid-range Android phone in tier-2 India.

The stack, and why

QDORA runs on Next.js and Firebase/Firestore. A few decisions that mattered more than I expected:

• Server components for anything crawlers need to see. I had a bug early on where a category page was fetching products client-side from Firestore, which meant Google's crawler saw skeleton loading text instead of actual product listings. Fixed it by splitting into a server component (data fetch) + client component (interactivity). Obvious in hindsight, expensive to learn the hard way.

• ISR, carefully. I had a regression where a isMobileDevice() check was silently forcing dynamic rendering on the homepage, killing the benefits of static generation. Replaced two separate banner components with a single ResponsiveBanner using a <picture> element instead of JS-based device detection. Simpler and faster.

• A 'use client' metadata bug was quietly breaking SEO metadata on the cart page (and I suspect others) — a good reminder that Next.js's client/server boundary punishes carelessness in ways that don't show up until you check Search Console weeks later.

The unglamorous SEO work

Nobody tells you that running a real e-commerce SEO stack is mostly plumbing:

• Structured data (Product schema, BreadcrumbList, WebSite/SearchAction) so Google actually understands what's on the page, not just what's written on it

• A Google Merchant Center feed generated from a Firestore export of ~580+ products — including chasing down google_product_category mismatches against Google's taxonomy, because a blank or malformed category value quietly kills visibility in Shopping results

• An llms.txt file for AI crawler visibility — new territory, but worth doing early

• Fixing a shared if (!mounted) return null guard that was hiding H1 tags from crawlers across every category page — confirmed fixed via Search Console, and a good reminder that a guard clause meant for hydration safety can silently sabotage SEO if you're not watching for it

None of this is exciting. All of it is the difference between a store that shows up in search and one that doesn't.

Writing product copy that isn't generic

A chunk of QDORA's catalog is traditional Kerala sarees — including Balaramapuram handloom sarees, which carry a GI (Geographical Indication) tag. Writing copy for these isn't like writing generic "beautiful cotton saree" filler — getting the cultural and technical terminology right (kasavu borders, pit-loom weaving, the actual provenance) matters both for authenticity and because that specificity is what actually differentiates the copy in search.

It's slower than templating out descriptions, but it's the kind of detail that compounds — better rankings, fewer returns from mismatched expectations, and copy that doesn't read like every other reseller's listing.

What's still hard

• Distribution without a team. Building the store is the part I'm good at. Getting people to it — without paid ads eating margin on a still-early brand — is the harder, slower problem.

• Doing everything myself. Dev, copy, SEO, customer support, and the actual business decisions all land on one person. The upside is a tight feedback loop — I can fix a bug or rewrite a product description the same day a problem shows up. The downside is obvious: there's no one to hand off to when something needs to happen and I'm also debugging a checkout bug.

• Balancing "ship fast" against "build it right." As a developer, it's tempting to keep refactoring — moving inline styles to CSS Modules, polishing accessibility, chasing lint warnings. All worth doing, but it's easy to spend a week on code quality when the store needed a new product category live yesterday.

Where this is headed

QDORA is still early — I'm not going to pretend otherwise. Revenue is modest, most of my energy so far has gone into the product and SEO foundation rather than paid acquisition. But I think that ordering is right: growth without a foundation that actually converts and ranks is just expensive.

If you're building something solo — especially something with a "boring" real-world constraint like inventory or logistics — happy to compare notes. And if you want to see what the SEO/dev side looks like in practice, the store's at qdora.in.