PROJECT 01Sep 2025 – Jun 2026

SpotBook: B2B Wholesale Platform

Co-Founder & Full-Stack Developer · From a first production deployment for P10 Denim / MG Sales to a modular Spring Boot platform for apparel manufacturers and wholesalers.

Staff using SpotBook on the expo floor, with racks of jeans in the background — SpotBook in its original setting: a live wholesale expo floor.

From Production Deployment to Platform

SpotBook began with a real client deployment: a mobile-first production order-management system built in approximately 15 days for P10 Denim / MG Sales ahead of a trade expo.

That deployment handled QR/product workflows, real-time inventory and order operations, and expo-floor support. Across two expo seasons it supported more than ₹9 Cr (~$1.1M) in wholesale bookings. Later SpotBook work extended the product into the multi-tenant architecture and domain capabilities documented below.

Railway was part of that product decision from the beginning. It kept deployment straightforward, so the engineering time could go into the ordering experience, concurrency safety, and the production problems users would actually feel.

This distinction matters: the first deployment proved the production workflow; the later platform engineering added the broader modular architecture, tenant isolation, and wholesale-domain depth.

See the Initial Deployment Details →

Initial Deployment: P10 Denim / MG Sales

The first SpotBook deployment was built for a real wholesale expo environment, where sales teams had to capture bulk orders quickly while stock was moving across booths, distributors, and visiting retailers.

Before the system, sales reps wrote order items manually on paper slips. During peak hours, two reps could unknowingly sell the same limited stock to different retailers, creating post-expo cancellations, distributor disputes, and no reliable real-time reporting for the manufacturer.

The 15-day build turned that workflow into a mobile-first PWA designed for noisy expo floors and 5-inch phone screens. A sales agent could learn the complete ordering flow in roughly ten minutes.

BeforePaper slipsFast to write. Hard to reconcile later.

During peak hoursThe same stock could be promised twice.Disputes and cancellations were discovered after the expo.

With SpotBookScan → choose set → book safelyStock was validated before the promise was made.

Role-based access: admin dashboard, sales-agent interface, distributor/customer flows, and manufacturer-level controls.
QR-led product lookup: staff could scan sample tags and immediately view product variants, stock levels, and order options.
Short path to an order: the interface followed how sales agents already worked, keeping the number of decisions and taps between scanning a product and booking it deliberately small.
Concurrency-safe checkout: DB-level pessimistic locking and stock validation prevented overbooking during simultaneous live orders.
Automated receipts: PDF/text receipts were generated and delivered through WhatsApp after order placement.
Live reporting: dashboards exposed revenue, order volume, inventory movement, and top-selling designs during expo days.

Initial Deployment Interfaces

SpotBook initial deployment admin dashboard

Admin dashboard: real-time revenue and order tracking

SpotBook initial deployment product catalog

Product catalog: stock filtering and size-variant ordering

SpotBook initial deployment inventory overview

Inventory overview: top-selling designs and stock valuation

SpotBook initial deployment analytics chart

Analytics: revenue trends during live expo operations

Built for Hands, Not Manuals

The people doing the work should be able to do the work. The system can carry the complicated part.

Who was doing the workSales agentBusy expo floor, one hand on a phone.Operations managerPlanning demand across products and distributors.Warehouse teamPacking what needs to go out next.

What they needed to doBook an orderwithout a form getting in the way.Make an allocation decisionwithout rebuilding the spreadsheet in their head.Find and move stockwithout decoding a wall of numbers.

What SpotBook carried underneathInventory validationConcurrency, reservations, order state.Demand groupingProduct, distributor, retailer, credit context.Inventory modellingSKU states, physical stock, future capacity.

SpotBook’s users were not people with time for training manuals. The aim was to make the next action feel natural and keep the system’s burden off their screen. In practice, a new sales agent could learn the complete ordering flow in roughly ten minutes.

Different people, different mental models

The initial deployment proved the workflow for one manufacturer. During those 15 days at the expo, I sat across the table from five other manufacturers—and every conversation revealed the same pattern.

"Business owners described what they wanted. Their salespeople and inventory managers described what they actually needed. Those were two very different products."

Warehouse staff didn't care about dashboards — they needed to know exactly how many pieces of Waist 32 × Dark Blue were left before promising them to a retailer. Salespeople didn't want a CRM — they wanted a POS that worked on a 5-inch phone in a noisy hall. Distributors didn't want login credentials — they wanted to browse a catalog via QR code without downloading anything.

That's what shaped the zone architecture below. Every boundary exists because a real person on the expo floor had a different mental model of the same data. A feature was successful only when it helped that person reach the intended outcome—not merely when the code worked.

Product Decisions

The choices beneath the screens

SpotBook was not designed around a feature checklist. It was designed around the moment a sales agent, manager, or warehouse operator needed to move quickly without carrying the system’s complexity in their head.

SpotBook mobile product-selection modal showing set, colour, stock availability, and plus-minus quantity controls

For sales agents on the expo floor

QR-to-cart without turning the order into a form.

Scan QRFocused modalChoose colour + setSet quantityAdd

The competition was not another application. It was writing an order on paper: fast, familiar, and nearly frictionless. After a QR scan, I kept the agent in one focused modal instead of sending them through a catalogue or a stack of fields.

They choose a colour, choose a set, tap thumb-friendly + and −controls, see availability, and add it. The hard part—inventory validation and safe checkout—stays underneath the interaction.

SpotBook order-based fulfilment screen listing orders and their shipping status — Start with an order

SpotBook product-based fulfilment screen grouping demanded products and their pending orders — Start with a product

For operations and warehouse teams

Two dispatch views, because people do not think in one shape.

Some fulfilment starts with an order: what should this distributor receive? Other work starts with a product: who is waiting for these pieces? Before SpotBook, that second question meant sorting through spreadsheets and rebuilding the grouping mentally.

Start with an orderWhat does this distributor need?Order-based fulfilment

Start with a productWho wants it, how much, and who should receive it first?Product-based planning + fulfilment

In an indent-based business, product-based grouping was also a planning surface before manufacturing: managers could compare demand, reserve inventory for later fulfilment, and weigh quantity against a distributor’s known credit history. The same underlying work could meet the operator from either mental model instead of asking them to translate their work into the software’s preferred shape.

SpotBook inventory edit view with size-level stock states, locked edit mode, and stock transfer controls

For the people responsible for stock

Inventory should say what it means at a glance.

Apparel inventory is not one number. Operators need to distinguish ready stock, booked stock, and what is actually available to promise. The wider model also separated physical stock from future production capacity—cloth and capacity that could become a promised product.

I used clear labels, visual states, size-level detail, and direct set-based actions so a dense inventory screen remained usable. A set update could move every size together; the interface did not make someone repeat the same action SKU by SKU.

Architectural Philosophy

Instead of jumping to microservices overhead for a 2-person team, SpotBook was built as a Modular Monolith with strict zone boundaries (Zones 0–7). Cross-module imports are restricted to explicit api/ packages, keeping internals encapsulated — while preserving a clean future microservices migration path.

Identity

Catalog

Inventory

Expo + Sales

Fulfillment

Control Plane oversees tenants and backoffice.Platform carries events, auditing, and notifications.

Zone Boundaries (0 – 7)

Zone 0: Control Plane (backoffice) — The only module that bypasses tenant filters.
Zone 1: Identity (iam) — Multi-role authentication (5 roles) & tenant context management.
Zone 2: Catalog (catalog) — Products, size matrices, prepacks, and pricing.
Zone 3: Inventory (inventory) — Virtual stock calculation, warehouse locks, and reservations.
Zone 4: Expo (expo) — Event sessions, booth QR allocations, and fast-order intake.
Zone 5: Sales (sales) — Order processing, draft persistence, and fulfillment triggers.
Zone 6: Fulfillment (fulfillment) — Packing, dispatch, and distributor receipts.
Zone 7: Platform (platform) — Shared event bus, auditing, and notifications.

Multi-Tenant Isolation

Tenant filters are enforced at the Hibernate @Filter level — every query is automatically scoped to the authenticated manufacturer's tenant_id. Cross-tenant data access is structurally impossible outside Zone 0 (Backoffice). This was verified with integration tests that specifically attempt cross-tenant reads and assert 403/empty responses.

Core Capabilities

🔒

Multi-Tenant Data Isolation

Hibernate @Filter-based tenant scoping at the query level. Automatic isolation across all 6 domain modules — verified with integration tests that assert zero cross-tenant leakage.

📊

Matrix Variant Ordering

Seamlessly handles 2D matrix orders (e.g. Waist Size 28-36 × 4 Denim Washes) with real-time stock validation and prepack bundle calculations.

🔄

Surgical Order Editing

Identity-based diffing engine computes order deltas on edits. Backend uses EDITING_RESERVED transitional status with pessimistic inventory locking — preserving order identity without full teardown.

⚡

Event-Driven Decoupling

Modules communicate asynchronously through Spring's internal event bus, avoiding direct cross-domain database coupling.

🧪

TDD for Critical Paths

JUnit 5 + Mockito unit tests across all modules. Integration and regression tests on concurrency paths, stock delta validation, and tenant isolation — run before every expo deployment.

👥

Architected for Multi-Dev Teams

Strict Zone boundaries (API vs. Internal packages) with Spring Modulith verification tests. Multiple developers can own separate domains without merge friction.

What I Learned

Architecture ≠ Diagrams

Zone boundaries aren't pretty lines on a whiteboard — they're enforced by ApplicationModulesTest failing your CI pipeline when someone sneaks a cross-module import. I learned that architecture only matters if it's testable.

Pragmatism > Purity

Modular monolith over microservices for a 2-person team wasn't compromise — it was the correct architecture for the team size, velocity constraints, and deployment complexity we had. The migration path to microservices is preserved in the zone contracts.

Complexity Stays Underneath

Concurrency, inventory locks, retries, and state transitions are engineering concerns. The sales agent should still see one obvious path from scanning a product to booking an order.

Engineering ≠ Product

SpotBook's code was production-proven. The GTM strategy wasn't. Facebook ads collected garbage leads. Traditional wholesalers trust relationships, not forms. A software system without a dedicated sales engine cannot scale into a full business.

The Business Reality

The GTM Lesson

No Corporate Filter — Direct, honest communication and high engineering integrity

While SpotBook's technical foundation was rock-solid and verified across 2 live expo deployments, the product faced distribution hurdles. Relying on paid digital marketing (Facebook lead ads) proved inefficient for a high-touch traditional industry.

Status: Paused — the product works, the engineering is proven. What stalled was go-to-market, not code quality. That distinction is important: this is an engineering success and a distribution lesson.

Explore the Engineering

See the real production problems solved building SpotBook — concurrency bugs, race conditions, schema migrations, and deployment gauntlets.

Read Engineering Challenges →Read The Full Story →