Rebuilding a working eCommerce site to be mobile first in two languages

Over the last couple of weeks I've been head-down on a rebuild of Opalescence.ge, an e-commerce site my wife runs here in Tbilisi. Around 131 hours in 17 days — probably the busiest fortnight I've done in a long time, maybe ever.

The previous site had been operating for a couple of years and turned over real money, so this wasn't a sandbox exercise. It was a replacement of a working storefront with customers, traffic and revenue already attached to it. Every decision carried a real consequence. Here's what the work looked like.

Optimising the whole experience, not just the mobile part

When we scoped the rebuild, one data point set the direction: 84% of purchases on the existing site happened on mobile. Not 84% of visits — 84% of actual transactions. Customers come for a product and they buy from a phone. And we had known for a while there were some things we could improve there, but more broadly identified the need for a full redesign and build to speed it up and improve the overall experience.

That made mobile-first the obvious starting point. Wireframes on a phone viewport. Thumb zones and sticky add-to-carts treated as primary problems, not afterthoughts. A checkout that survives a 4G connection on a five-year-old Android.

Once we'd settled on mobile-first, the broader goal got clearer too. The rebuild isn't just about mobile — it's about making the whole experience frictionless. For the buyer, who should be able to go from product page to confirmation in as few taps as possible. And the admin who’s not super tech savy, having a system that gets out of the way more and makes it easy to manage. The old site worked. The new one should be smoother — for the customer buying, and for the person running it day to day.

Two languages, one of which I can't proofread

The site runs in Georgian (default) and English. Georgian is the right default — most customers are local — but my Georgian is functional, not fluent. In addition, there’s a significant market here for people who also don’t speak Georgian and are more comfortable in English.

A bilingual build where you don't speak the default language natively gets hard, in ways that don't show up until you're in it. Character widths differ, so a button that fits in English overflows in Georgian. A short English CTA becomes a longer Georgian phrase, and the layout has to flex for both. Meta titles, slugs and structured data all need to be right in Georgian first, English second. Every product string lives in two places and has to stay in sync.

The fix isn't clever tooling. It's pairing with someone who reads the language natively — in my case, my wife — and accepting that "spot-check" isn't a step you get to skip and leveraging the best translation data available for the build to take the load off the translator.

Capturing the SEO equity, not just protecting it

Something easy to miss when you replace a working site is that the old one if built for SEO, was already doing real work in search. It ranked well for a bunch of keywords people actually type in when they're ready to buy — driving real traffic, in the background, while most of the visible marketing energy went into social.

Two things followed from that. First: any rebuild that loses that SEO position is a step backwards, no matter how nice the new design looks. URL parity, 301 mapping, structured data, page-speed gains, internal linking — all of those got serious attention during the build, not as a tidy-up at the end.

Second, and more interesting: the business has been mostly driven by social, with SEO as a quieter bonus compounding in the background. The rebuild is a chance to make both channels pull their weight — keeping the social momentum going, and properly building on the search rankings that years of content have already earned us. The goal isn't to preserve what's there. It's to build further on it.

How we launched

We did it in stages.

About a week before the hard launch, we soft-launched — the new site went live but the old site kept running in parallel. Active visitors mostly stayed on the old site; we used the soft-launch window to shake out anything obvious before real traffic landed on the new one. No redirects, just a side by side test.

Then on Friday afternoon we hard-launched — coordinated with an email push to existing customers and social announcements. That coincided with an influx of social-driven traffic, which is exactly when launch issues show up: when real customers, on real connections, with real cards, start trying to buy things.

And one did show up. The payment gateway started throwing problems within the first few hours of the hard launch, and the provider's tech support and comms were — to put it diplomatically — not what you want when real customers are trying to give you money. We had it sorted within an hour or two of finding it mostly without their help. But the lesson is straightforward: vendors will let you down at the worst possible moment, and whoever's running the rebuild needs to be on hand and ready to triage fast when they do.

Between Friday and yesterday afternoon I put in another 20-plus hours of polish — abandoned cart recovery emails, testing, smoothing edges, hammering anything that still looked shaky. The result is something clean: live, functional and ready to hand back to the business to run.

Where AI actually pulled its weight

I built this largely solo, with Claude alongside me end-to-end. Claude Design did the wireframes, hi-fi screens and brand redesign. Cowork handled the messier mid-stage juggle of content, assets and revisions. Claude Code did the implementation — components, the bilingual scaffolding, the inevitable theme quirks and Ultraplan in Claude Code (still in early release) even showed out a bit.

The judgement calls aren't AI's to make. Whether the hero image works, whether the Georgian copy reads like a person wrote it, whether the checkout actually makes sense to someone on a patchy connection at 9pm — those calls still belong to me, to my wife, and to the customers the site is for.

What AI actually does is compress the work that used to eat time — scaffolding, catching drift between language versions, drafting copy variants, surfacing UX issues at 11pm that I'd otherwise miss. The 131-hour figure at the top of this post is what one person, with the right tools and experience in the space, can get done in a fortnight (where before 3 months would have been optimistic for this).

What's next

The build is done. Handover starts now. We've hooked up Google Analytics and Google Search Console so we can actually see what's happening, and we're connecting Google Merchant Listings to get products in front of people at the moment they're searching to buy — not just browsing.

If you run an established e-commerce business and the idea of rebuilding it makes you nervous because it's already working — that's exactly the kind of project I do. Careful replacement of something that's already earning, without breaking what already works. Get in touch.

— Mike