CASE STUDY

Deals Milegi. Retail operations, made intelligible.

Exploring how structured data, connected workflows and AI-assisted development can support more reliable retail-commerce operations.

  • Retail Commerce
  • Digital Operations
  • Analytics
Sector
Pre-owned and refurbished devices: phones, with some tablets and watches
Varada’s role
Research, requirements, workflow design, AI-assisted build and validation
Scope
Unit-level records, catalogue sync, photos, reservations, reporting
Status
In progress
Project at a glance

From fragmented records to structured retail operations.

  1. The business problem

    Records that must agree

    Product information and inventory records must remain consistent across the retailer’s operational systems, for every individual unit.

  2. Varada’s approach

    Rules before software

    Business requirements, structured records, validation rules and automated workflows, decided first and then built with AI assistance.

  3. The operational output

    Exceptions you can see

    A reporting framework that helps identify exceptions and investigate inconsistencies before they reach customers.

Explore the Analytics Demonstration
01 · Business challenge

Every unit is one of one.

Deals Milegi sells pre-owned and refurbished smartphones, with occasional tablets and watches, through a physical shop and a growing online presence. Buying is assisted: customers can enquire on WhatsApp or reserve a unit for a timed in-store inspection, while online checkout sits behind a controlled switch as it is verified.

Refurbished retail behaves differently from ordinary e-commerce. Each physical device is its own product. Its condition grade, battery health, replaced parts, storage and price belong to that one unit. When it sells, it is gone. Accurate product information, inventory visibility and consistent records are not tidiness; they decide whether a customer is shown a phone that still exists.

When every unit is one of one, an inventory error is not a rounding issue. It is a customer being shown a phone that no longer exists.
  • Consistent product information

    Staff record devices in an operator app. The same details must reach the catalogue and storefront without being retyped, reinterpreted or quietly changed.

  • Inventory that never drifts

    A reservation or a sale must reach online stock quickly, and a sold unit must never reappear because an older record still says “available”.

  • Photos that belong to one unit

    Product photos are stored privately and attached to listings. A single mix-up misrepresents a real device to a real customer.

  • Identity without guesswork

    Linking a shop record to its catalogue listing has to be exact. Duplicates, gaps and listings with no matching record must be found, not assumed away.

  • Manual administration

    Creating and updating unit-level listings by hand is slow and error-prone, and it grows with every device that comes through the door.

  • Honest disclosure

    Condition, replaced parts and warranty should be shown exactly as recorded, with no invented checklists, guarantees or battery claims.

02 · Systems & implementation

A single source of truth, and rules that protect it.

A simplified view of how information flows through the system. People edit one layer; everything downstream is generated, checked and logged.

  1. Collect

    Shop staff record each device, its condition and its photos in an operator app.

    Product-data organisation
  2. Centralise & validate

    Records land in one source of truth. A generated, read-only layer exposes only approved fields, so private details such as full device identifiers are never read.

    Validation
  3. Map identity

    Each unit receives a permanent ID mapped to exactly one catalogue listing. A sold ID is never reused.

    Inventory management
  4. Sync inventory

    A scheduled daily job reconciles, then onboards records in small batches: update, adopt an existing listing, create, or quarantine for review.

    Operational workflows
  5. Publish

    Photos are audited and attached to the right listing. The storefront reads the validated feed and offers online checkout only for purchase-ready units.

    Catalogue & storefront
  6. Report

    A protected, read-only operations summary reports mapping, media, reservation and sync exceptions, with plain-language caveats.

    Reporting
  • Workflow stage
  • Stage with a blocking data check
  • Reporting output

What the founder contributed

Six contributions, each marked by who did the work. AI accelerated execution; business understanding determined what was worth building.

  1. Human decision

    Understanding the business problem

    Studied how a unit-level refurbished-device business runs and wrote the proposal to the owner.

  2. Human decision

    Translating requirements into rules

    One unit, one listing; a sale always wins; no fuzzy matching; dry run first; identifiers masked.

  3. Human decision

    Designing structured workflows

    A single source of truth, permanent identity mapping, validation gates and a staged rollout.

  4. AI-assisted · human-directed

    Using AI tools to implement

    Code, error tracing and review passes drafted with AI coding assistants from written specifications. The founder did not hand-write the codebase.

  5. Human-verified

    Testing and validating results

    Controlled batches and dry runs, with results checked against real records before each wider stage. AI drafted tests; it did not sign off on them.

  6. Human decision

    Interpreting operational information

    Reading reports for what they mean: available, eligible and purchase-ready are different questions with different consequences.

Founder decisions

Abhay Sharma, Varada

  • Researched the business and wrote the proposal to the owner, including a candid review of the existing online presence.
  • Revised the original platform recommendation: kept the existing commerce platform behind a new storefront rather than migrating everything at once.
  • Set the operating rules: one unit, one listing; a sale always wins; no fuzzy matching; dry run first; identifiers masked.
  • Planned a staged rollout: a five-unit controlled test, a dry-run classification of every record, then controlled production batches.
  • Reviewed each stage’s results before allowing the next, wider stage.

AI-assisted implementation

Directed and verified by the founder

  • Code for the sync engine, photo pipeline, storefront and scheduled jobs, drafted with AI coding assistants from written specifications.
  • Tracing errors in failed runs and proposing candidate fixes.
  • Automated test suites (more than fifty test cases) covering access control, privacy, photo checks and disclosure wording.
  • Review passes for credential leaks, identifier masking and unsafe writes.
Completed
  • Exact identity mapping and permanent sold-lock
  • Daily scheduled sync with dry-run default and audit log
  • Listing creation, adoption and recovery of orphaned listings
  • Live catalogue and stock on the storefront
  • Timed in-store reservations
  • Read-only operations summary
  • Client-approved aggregate snapshot published in the dashboard
In progress
  • Production onboarding and clean-up of the full catalogue
  • Back-photo-first listing readiness: built, awaiting a canary release
  • Clean-up of historical photo records
  • Production verification of cart and checkout
  • A controlled paid test order, from payment to sold-lock
Planned
  • Full-catalogue reconciliation after the photo update ships
  • Automated photo refresh
  • End-to-end verification of every available unit
03 · Interactive demonstration

Explore the intelligence behind the operation.

An interactive demonstration of how retail information can be organised, validated and transformed into useful operational insights.

Records in backup
342 · one per physical unit
Available
165 · 48% of records
Marked sold
177 · a stock label, not verified sales
Median asking price
₹30,000 · available units, stored price

Client-approved grouped figures from an inventory backup dated 8 September 2026.

Embedded application Deals Milegi retail analytics · client snapshot + illustrative demo

Open the dashboard in a new tab (opens in a new tab) ↗

The interactive dashboard isn’t available right now.

It runs as a separate application and may be updating. The sections above describe the same reporting rules, and you can try opening the dashboard directly.

Try opening the dashboard

The dashboard is a separate application. Its Client snapshot view shows Deals Milegi’s grouped figures from an inventory backup dated 8 September 2026, approved by the client for publication; asking prices are stored prices, not revenue. The four demo views use synthetic data to show how the operational checks work. There is no live connection to Deals Milegi’s systems.

04 · Across retail

Different products. Similar operational questions.

The principles behind this project travel well beyond refurbished phones. The inventory structures underneath them do not. Here is how the same questions look in personal-care retail.

Operational questions compared across refurbished electronics and personal-care retail
Operational question Refurbished electronics Personal-care retail
What is a record? Individual device records SKUs, variants and quantities
What describes the product? Device condition Product specifications and batch information
What does “in stock” mean? Individual-device availability Channel-level inventory availability
What happens on a sale? Sold-device locking Stock deduction and reconciliation
What must be complete before listing? Product-media validation Product master and listing completeness
How is it reported? Unit-level reporting SKU-, channel- and batch-level reporting

The shared principle

Both need consistent definitions, reliable product records, validation before anything is published, visible inventory and a clear route for exceptions. A report is only as trustworthy as the records beneath it.

Where they differ

A refurbished phone is one of one: a sale removes it permanently and its condition belongs to that unit alone. A personal-care product is one of many: stock is a quantity shared across channels, and batch or expiry information matters for traceability. The checks rhyme; what they count, and when, does not.

05 · Reconciliation

Connecting transactions to reliable accounts.

The same discipline applies when operational records meet financial ones. A conceptual example of how an analyst reconciles an order, its invoice and the payment received.

Illustrative · synthetic transactions Open the reconciliation example

A conceptual demonstration only. These transactions are invented; this is not a Deals Milegi accounting integration, and Varada has not built a production accounting system for the client.

Identified is not the same as explained. Calculating a difference only shows that something needs attention. An explanation is confirmed when it is matched to a document, such as a credit note or a settlement report. Until then the difference stays open; it is not assumed to be a loss.

06 · Method & learning

AI accelerates execution. Business understanding determines what is worth building.

Research and operational understanding decided what the system had to protect. Structured data made those rules checkable. AI tools shortened the distance between a rule and working software, and every stage still ended with a human checkpoint.

  1. Understanding requirements

    Turning plain-language rules such as “a sale always wins” into written specifications and testable acceptance criteria.

    Human checkpoint: approve each rule as business policy.
  2. Researching approaches

    Working through platform documentation, API limits and quota constraints, and comparing implementation options with their trade-offs.

    Human checkpoint: choose the approach and rollout size.
  3. Investigating problems

    Reading logs and failed runs to trace causes, from duplicated mappings to photos attached to the wrong listing.

    Human checkpoint: confirm the cause against real records.
  4. Assisting code development

    Drafting the sync engine, photo pipeline, storefront and scheduled jobs from written specifications.

    Human checkpoint: review, run and accept every change.
  5. Reviewing validation logic

    Second-pass reviews for credential leaks, unmasked identifiers, missing access checks and writes that could not be undone.

    Human checkpoint: accept, change or reject each finding.
  6. Documentation & testing

    Drafting automated tests, edge-case scripts and the implementation notes that brief each working session.

    Human checkpoint: run controlled batches and verify results in the live catalogue.
Good analytics begins before the dashboard. It starts with knowing whether the underlying information can be trusted.
  • Consistent definitions so “available” means the same thing in every report.
  • Reliable source records that people edit in one place, not several.
  • Appropriate validation that stops incomplete records before customers see them.
  • Reconciliation that compares systems instead of trusting either one alone.
  • Clear exception handling that routes problems to a person rather than hiding them.

What the project demonstrates.

  1. Data integrity is a business decision

    Rules like “a sale always wins” are commercial policy expressed in software. They had to be decided by the business before they could be built.

  2. Automate the routine, route the exceptions

    Most records flow through untouched. The valuable work is catching the few that do not fit and handing them to a person instead of forcing them through.

  3. Measure the right thing

    Available, publishable, purchase-ready and sold are four different numbers. Reporting them separately keeps an operation honest with itself.

  4. AI speeds work up; it does not verify it

    AI output is fluent, not proof. It can propose a confident but wrong fix and depends on precise specifications. Checking results against real records stayed human work.

DIGITAL OPERATIONS

Records that don’t agree with each other?

Varada’s Digital Operations Build starts with how your business actually works, then builds the workflows, checks and reporting around it.