Mobile-first checkout
Most Indian store traffic is on a phone, so the cart and checkout are designed and tested there first, including the payment redirect.
Online stores built to be run by you, not by your developer.
I build and fix WooCommerce stores – product structure, checkout, payments, shipping and stock – and hand them over with the training to run them yourself. Quoted as a fixed price before the work starts.
WooCommerce turns WordPress into a shop, and because it is free and installs in a minute, a great many stores get built by installing it and hoping. That works until the catalogue grows, or a customer abandons a checkout that asks for a company name they do not have, or someone realises the tax is being calculated wrong on interstate orders.
The work that actually matters happens before any of that: deciding how your products are modelled. Whether something is a variable product or three simple ones, where attributes end and categories begin, how bundles and kits are represented, what happens to stock when an order is cancelled. Get that right and the store scales quietly. Get it wrong and every later change is a migration.
The businesses this suits are the ones selling something with structure – sizes and colours, subscriptions, bundles, made-to-order items, B2B pricing tiers, or a catalogue that turns over. If you sell six things that never change, a simpler setup will do. If your catalogue has shape to it, that shape needs designing.
The problems it solves are the ones that cost real money: a checkout that loses people at the payment step, shipping rules that undercharge on heavy orders, stock that drifts out of step with what you actually hold, a product page that takes eight seconds on a phone, or an admin so awkward that adding a product is a twenty-minute job.
Done properly, a WooCommerce store is genuinely yours. The platform is open source, the data is in your own database, there is no per-transaction platform fee on top of what the gateway takes, and nobody can change the terms underneath you. That is the trade for having to look after it – which is what a care plan is for.
A store built around your catalogue, from product modelling through to the thank-you page, rather than a theme demo with your logo on it.
The store fits how you actually sell, so your team is not working around it every day.
Simple, variable, grouped and bundled products modelled properly, with attributes, taxonomies and filters that still make sense at a thousand SKUs.
Adding the next hundred products is a content job, not a restructuring project.
Trimming the fields, fixing the order of steps, handling guest checkout, and removing the friction that makes people give up at the last screen.
Fewer abandoned carts from a checkout that asks less and explains more.
Razorpay, PayU, Stripe, PayPal, Cashfree and cash on delivery, configured and tested in the provider’s sandbox before a rupee moves.
Payments that work on launch day, including the failure paths nobody tests.
Weight and zone-based rates, courier integrations, pickup options, and GST configured for the way you actually invoice.
Accurate charges on every order, instead of margin quietly lost on the heavy ones.
Moving from Shopify, Magento, OpenCart or a spreadsheet – products, customers, orders and URLs, with redirects mapped.
You keep your catalogue, your customer accounts and the search visibility you already had.
Query and index work, image pipelines, caching that understands carts and sessions, and hosting sized for the traffic you get.
Product and category pages that stay quick as the catalogue and the traffic grow.
Product configurators, B2B pricing tiers, subscriptions, wholesale rules and bespoke order workflows written as proper extensions.
The thing your business does differently is supported, rather than worked around by hand.
Standard on every build, not line items added to the quote.
Most Indian store traffic is on a phone, so the cart and checkout are designed and tested there first, including the payment redirect.
Every payment method is exercised in sandbox – success, failure, timeout and refund – before the store takes a real order.
Stock rules, backorder handling and low-stock alerts set up so what the site shows matches what is on the shelf.
Product images in WebP at display size, lazy loading, object caching and page caching configured to leave carts and sessions alone.
SSL, hardened configuration, least-privilege roles for staff, and payment data handled by the gateway rather than touching your server.
Product schema, clean category URLs, canonical handling for variations and filters, and titles and descriptions that read like sentences.
Order screens, bulk editing and reporting arranged around your workflow, with a walkthrough and written notes at handover.
The unglamorous flows set up too, because a store that cannot process a return properly creates work for someone every week.
GA4 e-commerce events, Search Console and conversion tracking configured before launch, so you know what is happening from the first order.
WooCommerce earns its keep when the catalogue has structure or the selling has rules.
Selling direct with sizes, colours and seasonal ranges, where the catalogue changes often and the brand has to look like itself.
Stores outgrowing Shopify’s per-transaction fees or app subscriptions, where owning the platform outright starts to pay.
Customer-specific pricing, minimum order quantities, quote requests and account-based ordering that standard retail checkouts do not cover.
Specification-heavy products, distributor information, and enquiry paths alongside the buy button.
Recurring orders, delivery schedules and customer self-service, where the value is in the second order rather than the first.
Delivery zones, time slots, minimum baskets and stock that changes through the day.
A working shop that is slow, awkward to run, or losing people at checkout, where a rebuild is not the only option.
White-label WooCommerce build capacity for a developer who works inside your process and your deadlines.
Bookings, courses, memberships and packages, where the checkout is the same but what is bought is not a box.
I am based in Bangalore and build stores for businesses across the city and the rest of India, as well as for clients overseas. For a store project in particular, meeting once at the start is often worth it – walking through how you pack, ship and invoice tells me more in an hour than a written brief does in a week.
Indian stores have their own requirements, and they are not optional: GST on invoices, interstate tax handling, cash on delivery as a real payment method rather than an afterthought, courier integrations for the services people actually use, and pin-code-level serviceability checks. These are configured as part of the build, not discovered after launch.
Everything after that first conversation happens remotely – a staging store you can place test orders on, scheduled calls, and written updates at each stage. That is the same way I work with store owners in the UK, USA, Canada, the UAE and Singapore, where the tax and shipping rules differ but the process does not.
In-person at the start of a store project, where it helps.
Tax classes, interstate rules and invoice formats set up correctly.
Courier integrations, COD and pin-code serviceability handled.
Multi-currency and international shipping where you sell abroad.
Serving Chennai, Bangalore, India, Canada, UK, USA, Dubai, Singapore.
What a store needs depends entirely on what is in it.
Typically needs: Size and colour variations, lookbooks, seasonal collections and a high rate of returns.
How I help: Variable products modelled properly, size guides on the product page, and a returns flow your team can actually process.
Typically needs: Specification comparison, warranty information, bundles and fast-moving stock.
How I help: Specification tables as structured fields, comparison views, bundle products and stock alerts that fire before you sell out.
Typically needs: Delivery slots, zone limits, minimum baskets and short shelf life.
How I help: Pin-code serviceability, slot booking at checkout, and per-zone minimums and charges set as rules rather than manual checks.
Typically needs: Ingredient and usage information, subscriptions and repeat purchase.
How I help: Rich product content, subscription support and re-order prompts tied to the customer’s own order history.
Typically needs: Heavy shipping, made-to-order lead times and configurable options.
How I help: Weight and dimension based shipping, per-product lead times shown up front, and configurators for options that change the price.
Typically needs: Instant delivery, licence limits and no shipping at all.
How I help: Digital product delivery with download limits, plus course or membership access tied to the order.
Typically needs: Account pricing, bulk orders, quote requests and GST invoices.
How I help: Role-based pricing tiers, minimum order quantities, a quote-request path beside the buy button, and compliant invoicing.
Typically needs: Zoomed imagery, certification details, made-to-order and secure payment.
How I help: High-resolution image handling that is still fast, certificate fields on the product, and gateways configured for higher-value baskets.
Typically needs: Prescription handling, regulated categories and careful data handling.
How I help: Prescription upload at checkout, category rules that block what cannot be sold openly, and tight handling of customer data.
Six stages. You can place a test order well before anyone else can place a real one.
I start with how you sell: the catalogue and how it varies, the price rules, how you pack and ship, how you invoice, who runs the store daily and what systems it has to talk to.
You get: A written scope, a fixed quote and a stage-by-stage timeline.
Why it matters: Store projects overrun when the catalogue turns out to be more complicated than the brief said. This is where that surfaces.
I model the products – what is variable, what is grouped, which attributes are filterable – and settle the tax, shipping and gateway configuration, plus hosting sized for your traffic.
You get: A product model, a tax and shipping plan and a technical spec, signed off.
Why it matters: Restructuring a catalogue after a thousand products are loaded is the most expensive rework in e-commerce.
Layouts for the pages that actually sell: category, product, cart and checkout, designed at phone width first with real product content rather than demo images.
You get: Designs for the key store templates, revised until you are happy.
Why it matters: Category and product pages are where the money is made, so they get designed rather than inherited from a theme.
I build the theme and custom functionality, load the catalogue, and wire up gateways, shipping and any integrations. Everything goes onto a staging store you can browse and test-order on.
You get: A working store on a staging URL, updated as each part lands.
Why it matters: Placing your own test orders early catches things no specification document would have.
Full order testing across devices – success, failure, timeout, refund and cancellation – plus tax and shipping verified against real scenarios, speed measured, and product schema, sitemap and redirects put in place.
You get: A tested store, the performance numbers and a redirect map if one is needed.
Why it matters: A payment path that fails silently is the most expensive bug a store can ship with.
Going live at a quiet hour, with DNS, SSL, live gateway keys, analytics and Search Console set up, then a training session on running orders, stock and products, with written notes.
You get: A live store, every account in your name, and training your team can refer back to.
Why it matters: A store nobody in-house can operate turns every small change into a support ticket.
WooCommerce at the centre, and the surrounding pieces chosen to fit how you sell.
Specified against your catalogue and your rules, not bundled as a package.
A store has SEO problems a brochure site never has: thousands of near-identical variation URLs, filters that generate infinite combinations, out-of-stock products that still rank, and category pages competing with each other. Most of that is settled by how the store is configured, not by writing more content.
No one can guarantee a position on Google, for a product or anything else. What is controllable is making sure the store is not the reason you are held back.
People increasingly ask an assistant what to buy rather than typing a product name into a search box. Those answers get assembled from content that states things plainly: what the product is, what it costs, whether it is in stock, who sells it and where they are.
Nobody can promise inclusion in any AI answer engine. What is possible is keeping the store’s facts accurate, structured and easy to attribute.
The practical reasons, rather than the adjectives.
A shop has failure modes a brochure site does not – payment timeouts, stock drift, tax edge cases, abandoned checkouts. Those are the parts I test hardest, because they are the parts that cost you money quietly.
How your products are modelled decides what the store can do for the next five years. That decision gets made deliberately, at the start, with you in the room.
Every gateway is exercised in sandbox across success, failure, timeout and refund. Finding out a refund path is broken from an angry customer is not a test strategy.
Handover includes real training on orders, stock and products, with written notes. If adding a product needs a developer, the store was built wrong.
The price is agreed before work starts. Anything outside that scope is quoted separately and only begun once you have said yes to it.
Care plans cover the updates, backups and monitoring a live store needs, and I am reachable when something breaks on a Saturday.
Tell me what you need. I reply within one working day, and the first conversation costs nothing.