Selected work

Three jobs we ship, written in full — not three slogans.

Read the problem, what we actually build, the deliverables, and who it is for. These are capability studies from Gurugram. They are not invented client logos.

How to read this page

A buyer who opens Work should leave knowing what CycloneWebz will do, what we will not do, and what to send us to start. Each study below is a full brief: symptoms, the product we build, the steps, the hand-over, and the questions we get on the first call.

We do not publish client names or percentage lifts we cannot stand behind. If you need a named reference after an NDA, say so on the contact page.

01 · AI development

In-product AI assistant on your own data

A retrieval assistant that answers from your help centre, PDFs, tickets, and policies — on the website, in the app, or on WhatsApp — with citations and a human fallback.

Support, operations, professional services, and any team that answers the same questions every day

This is the AI work CycloneWebz ships most often. It is not a generic chatbot widget dropped on a homepage. It is a retrieval assistant that can only speak from material you already own, placed in the channel your customers already use, with a person taking over when the system is unsure.

We write it as a capability study because the shape of the work repeats: the same ten questions burn staff time, a public model invents policy, after-hours enquiries die, and nobody can see what the bot said last Tuesday. The documents, the channel, and the brand voice change. The job does not.

What is going wrong

▸ Support and sales paste the same answers into chat, email, and WhatsApp every day.
▸ A theme chatbot or a vendor widget invents refund, pricing, or compliance answers.
▸ After-hours and weekend enquiries sit unanswered until Monday.
▸ Help-centre articles exist, but nobody searches them — they just open a ticket.
▸ There is no log of what the assistant said, so you cannot improve the corpus.
▸ The AI vendor is separate from the team that owns the website or the app.

What we build

A mapped question set, not a model looking for a job

We sit with support and ops and write down the ten to thirty questions that actually cost time. We match each one to the document, CMS page, or ticket thread that already answers it. If the answer is not written down, we say so before anyone talks about models.

Retrieval over your corpus

Help-centre articles, PDFs, FAQs, and approved ticket macros are chunked, stored, and retrieved. The assistant answers from those passages. It does not invent a policy that is not in the files. Citations are shown to the agent or, when you want, to the customer.

The assistant in the product

Web widget, in-app help, or WhatsApp — sometimes all three with one brain. Tone, language (English and Hindi when needed), and what the bot is allowed to do are set with you. Booking, order status, or ticket creation can be wired when the data is clean enough.

Handoff, logs, and a weekly loop

Low confidence, angry language, or a topic you marked as human-only opens a person. Every turn is logged. Each week we add missing documents, fix prompts, and retire answers that drifted. That loop is the product, not a one-off launch.

You leave with

▸ Question map and corpus inventory (what you have, what is missing)
▸ Retrieval pipeline over approved documents, with versioning
▸ Assistant UI on web, in-app, and/or WhatsApp
▸ Citation display and confidence-based human handoff
▸ Staff transcript console and export
▸ Eval set of real questions, scored before and after launch
▸ Topic block-list and brand-voice rules
▸ Runbook for adding documents and reviewing failed turns

This is for you if

▸ Support and sales teams drowning in repeat questions that already have written answers
▸ Service businesses that want WhatsApp or web help after hours without inventing policy
▸ Product teams adding a first AI feature to an existing site or app
▸ Operators who need a log of every answer for training and compliance

This is not for you if

– A company that wants a public model trained on their private data with no retrieval and no review
– A brief that is only “add ChatGPT to the site” with no documents and no owner
– A use case that is really a full CRM rebuild dressed up as a chatbot

Full study: process, stack, FAQ Start this work

02 · IoT + apps

Live fleet and campus visibility

Device-to-cloud tracking for vehicles and campuses — ingest, maps, geofence alerts, operator web, and parent or driver apps the morning shift will actually open.

Transport operators, schools, campuses, and mobility businesses that need one live map

IoT only pays when devices, people, and decisions share one picture. CycloneWebz builds the software side of that picture: ingest from the hardware you already bought or we specify, a live map, alerts that mean something, and the web and mobile apps for dispatchers, drivers, and parents.

This study covers the fleet and campus work we publish as a practice — remote vehicle monitoring, school bus tracking, smart transport, and operator consoles. Hardware is specified and integrated; software, cloud, and apps are engineered end to end in Gurugram.

What is going wrong

▸ Location lives in a vendor GPS app, a WhatsApp group, and a phone call to the driver.
▸ Parents or customers ask “where is it?” and the office cannot answer without another call.
▸ Geofence alerts fire so often that nobody trusts them — or they never fire at all.
▸ Morning dispatch and the field team do not share the same map or the same roles.
▸ A conference-room pilot worked on one bus and died when the second depot came online.
▸ Nobody owns device security, SIM expiry, or what happens when a unit goes dark.

What we build

Device and protocol fit

We specify or integrate the units you already have. Protocols, reporting interval, ignition and door events, and what “offline” means are written before we draw a pretty map. Hardware is sourced to the brief; we do not pretend every dongle is the same.

Ingest, store, and alerts

A device-to-cloud path with storage you can query later — not only a live blinking dot. Geofences, speed, route deviation, and dark-device alerts are tuned so they mean something. Operators can silence noise without turning the system off.

Operator web console

One map for the fleet or the campus. Filters by vehicle, route, depot, or campus. History playback for a dispute. Roles so a depot manager does not see another city. The console is built for a desk that is already busy — large targets, few clicks, Hindi and English when needed.

Parent, driver, and field apps

Limited mobile views: a parent sees their bus, a driver sees their job, a security desk sees the gate. Push or SMS for the events you chose. This is where school-bus and campus work either earns trust or creates a hotline of angry calls.

You leave with

▸ Device and protocol specification, or integration of existing units
▸ Ingest pipeline and queryable location history
▸ Live map with last-seen honesty and history playback
▸ Geofence, route, speed, and dark-device alerts
▸ Operator web console with roles by depot or campus
▸ Parent-facing and/or driver mobile views
▸ Security and retention note for location data
▸ Field rollout checklist and ops runbook

This is for you if

▸ School and campus operators who need parent-safe bus or gate visibility
▸ Transport and logistics teams that want one map instead of three vendor apps
▸ Mobility businesses adding remote vehicle monitoring to an existing fleet

This is not for you if

– A request for hardware-only supply with no software or ops owner
– A nationwide rollout promised before one corridor has run for a month
– A consumer “find my scooter” toy with no operator and no alert policy

Full study: process, stack, FAQ Start this work

03 · Ecommerce

Conversion-focused ecommerce storefront

A store that can take a sale-day spike: catalogue, search, checkout, wallets, COD, GST, and ops wired so fulfilment is a system — on Shopify, Magento, or a custom storefront.

Retail, D2C, and catalogue businesses that sell in India and need checkout that holds up

Ecommerce website development at CycloneWebz is not a theme with a logo swap. It is the path from browse to paid order on real Indian phones: search, variants, offers, UPI and wallets, COD, GST, and the inventory or ERP link that stops you selling what you do not have.

This study is the storefront work we repeat. The brand and the catalogue change. The failure modes do not: pretty homepage, broken cart, COD treated as an afterthought, marketing locked out of landing pages, and a sale-day crash nobody load-tested.

What is going wrong

▸ The theme looks on-brand and still loses people at variant, address, or payment.
▸ COD, UPI, wallets, or failed-payment recovery were bolted on after launch.
▸ Stock on the site and stock in the warehouse disagree by the afternoon.
▸ Marketing cannot change a landing page or offer without an engineering ticket.
▸ Sale days stall the site or double-charge, and nobody ran a load test on checkout.
▸ GST, invoices, or returns are a spreadsheet next to the store.

What we build

Browse-to-buy on real devices

We audit the live path — or design it if you are new — on the phones your customers use. Search, filters, variants, cart, address, COD, and failed payments are treated as one flow. Desktop is checked. Mobile is where we spend the time.

The right engine for the catalogue

Shopify, Magento, or custom / headless. Payments and GST rules are designed with merchandising, not copied from a US theme. Offers, coupons, and bundles are things marketing can run.

Checkout, wallets, and COD

Certified payment paths, wallet and UPI options you actually need, COD rules that do not invite abuse, and a recovery path when a payment fails. The customer sees a clear total before they commit.

Ops, CMS, and sale-day proof

Inventory or ERP link, shipping partners, and a CMS for landing pages. We load-test the path that makes money — catalogue and checkout — not only the homepage film. You get a merchandising runbook, not a locked theme.

You leave with

▸ Conversion audit on real devices (or a new IA if you have no store yet)
▸ Storefront on Shopify, Magento, or custom / headless — chosen for the catalogue
▸ Product, search, cart, and checkout UX
▸ UPI, wallets, cards, and COD rules as needed
▸ GST-aware totals and invoice path as scoped
▸ Inventory, ERP, or shipping integration
▸ CMS for merchandising and landing pages
▸ Checkout/catalogue load test and launch runbook

This is for you if

▸ D2C and retail brands selling in India that need wallets, COD, and GST treated as first-class
▸ Teams whose theme is pretty and whose cart is not
▸ Catalogue businesses ready to leave a spreadsheet or a marketplace-only setup

This is not for you if

– A two-day logo-on-a-theme job with no payment or inventory work
– A marketplace listing brief with no owned storefront
– A request for fake “300% conversion” case-study numbers we will not invent

Full study: process, stack, FAQ Start this work

About these studies

Are these named client case studies?

No. They are capability studies for the three practices we ship most: an in-product AI assistant, fleet and campus visibility, and a conversion-focused ecommerce storefront. We describe the problem, the build, the deliverables, and who it is for — without invented logos or fabricated metrics.

Why only three pieces of work?

Because those three are the jobs buyers ask us to explain in detail. AI is the lead practice. IoT and ecommerce are the other two products we still run end to end in Gurugram. Every other service is on the services pages.

Begin with AI

Ready when the idea is still a sentence.

Send the corpus, the product, or the rough brief. We will tell you what AI we would ship first, what we would wait on, and what the rest of the product needs.

Start an AI project