Krenno
All projectsCase study
CommerceB2B Commerce2023iOSAndroidWeb

ZCommerce

The procurement stack businesses need when a storefront is not enough.

Enterprise buying with negotiated catalogues, approval workflows, and GST-ready fulfillment.

Client

ZCommerce

Engagement

product company

Krenno roleProduct strategyInformation architectureUX and UI designCross-platform mobile engineering+4 more
Positioning

Why this product exists

ZCommerce replaces fragmented purchasing — WhatsApp quotes, spreadsheet POs, unmanaged spend, and disconnected logistics — with a single platform that combines catalog commerce, bid negotiation, approval control, budget enforcement, GST-compliant finance, and last-mile fulfillment.

ZCommerce shows that Krenno can design and ship a four-surface commercial platform — buyer, vendor, admin, and delivery — on a shared API, with the hard parts of B2B intact: RFQ negotiation, L1/L2 approvals, cost-center budgets, GST invoicing, and AI-assisted purchase-order capture. For the next client, this is evidence that we can take a complex operational domain and turn it into a polished, policy-aware product rather than a generic storefront.

Built for

  • Mid-market and enterprise procurement teams
  • Organizations with multi-location cost centers and GST registrations
  • Finance heads who need budget control and MIS reporting
  • Suppliers selling into business accounts
  • Operators running catalog, order, and logistics desks
  • Product companies that need a white-label B2B commerce engine
The story

Challenge, approach, solution

01

The Challenge

Business purchasing does not behave like consumer checkout. A buyer may need a negotiated price, a purchase order, a manager's approval, a cost-center budget, a GST-correct invoice, and a tracked shipment — often across multiple locations and roles. Consumer commerce tools collapse under that complexity. Spreadsheets and email fill the gap, and spend becomes invisible. The opportunity was to build a commerce system that treats procurement policy, negotiation, and fulfillment as first-class product surfaces rather than afterthoughts.

02

Our Approach

We designed ZCommerce as four coordinated products on one architecture. The buyer app is a commerce experience with enterprise controls. The admin console is the operational backbone for organizations, catalog, RFQ negotiation, and bulk operations. The vendor portal gives suppliers their own pricing book and order desk. The delivery app closes fulfillment in the field. Behind them, a single Express API, a multi-tenant organization model, and a policy engine let each company turn features on or off without forking the product.

03

The Solution

ZCommerce is a complete B2B commerce operating system. Organizations onboard with GSTIN and certificates. Teams are structured by role and reporting line. Buyers shop by category or brand, or they build personal catalogues, submit bid prices, and negotiate until a deal is active. Orders move through approval, payment, shipment, invoice, and delivery challan. Budgets debit against cost centers. Finance heads receive automated MIS. The result is a platform that feels like commerce to the buyer and like procurement software to the business.

Experience

The Experience

A buyer opens the ZCommerce app, authenticates with email OTP, and lands in a storefront shaped by their organization's rules — catalog mode, hidden prices, mandatory PO, or prepaid checkout when policy requires it. They add products to a cart or assemble a catalogue, enter bid prices, and submit an RFQ. When the deal is accepted, checkout captures delivery and billing addresses, cost center, receiver details, and purchase-order data. The order waits for L1 and L2 approval. Managers review team spend, approve or reject in bulk, and watch wallet balances update. Operations staff onboard organizations, negotiate catalogues, create shipments, and assign delivery partners. Agents in the field verify delivery. Finance downloads GST invoices, delivery challans, and order reports. Every role works in a surface designed for that job, against the same source of truth.

Product

What we built into the product

Four-Surface Commerce Platform

A coordinated product system across buyer, admin, vendor, and delivery applications. Each surface has its own information architecture and visual language while sharing authentication, catalog, orders, and fulfillment through one API.

Negotiated Catalogue and RFQ Bidding

Buyers build personal catalogues, set bid prices and quantities, and move deals through a structured workflow from new request to negotiation, RFQ received, discussion, and active pricing. Operations can counter, accept, or continue discussion, with notifications at each step.

Multi-Level Purchase Approval

Orders route through L1 and L2 approvers based on reporting hierarchy. Managers review team orders, approve or reject individually or in bulk, and release spend only when policy is satisfied.

Organization Policy Engine

Each enterprise configures how the product behaves: shop by category or brand, catalogue mode, mandatory purchase orders, billing address rules, price visibility, receiver capture, unique-buyer enforcement, prepaid versus credit orders, bulk ordering, and automated MIS.

Cost Centers and Budget Wallets

Organizations allocate spend across GSTIN-registered cost centers. Users receive wallet balances, transactions are ledgered as credits, debits, and cashback, and checkout binds every order to the correct cost center.

GST-Native Invoicing

Products carry HSN codes and tax rates. Invoices calculate CGST, SGST, and IGST, generate professional PDFs, and store them with matching delivery challans so finance can close the books without leaving the platform.

AI-Assisted Purchase Order Capture

Uploaded purchase-order documents are read by Azure AI Form Recognizer and converted into structured orders, reducing manual re-entry and keeping PO numbers, dates, and line items aligned with the live catalog.

Vendor Book and Supplier Operations

Suppliers maintain company profiles, GSTIN documents, and a vendor book of product-level pricing. The vendor portal gives them a dedicated desk for their catalog, orders, and shipments without exposing the full admin console.

End-to-End Fulfillment

Shipments are created at line-item level with tracking IDs and delivery PINs, assigned to delivery partners and agents, and progressed through accepted, processing, shipped, out for delivery, delivered, returned, or short-closed states. Buyers acknowledge receipt. Agents verify delivery in the field app.

Role-Based Procurement Workspace

Seven roles — from buyer and line manager to finance head, category owner, and head admin — see the screens, approvals, reports, and controls that match their responsibility.

Also included

Enterprise Catalog Architecture

A four-level taxonomy of super category, category, subcategory, and brand, with SKUs, variants, stock, tax, weight, multi-image media, and organization-exclusive products.

Policy-Aware Checkout

Checkout captures delivery and billing addresses, cost center, receiver information, and purchase-order number and date when the organization requires them, with pincode lookup for Indian addresses.

Prepaid and Credit Buying Modes

Organizations can require Cashfree-powered prepaid checkout or allow post-paid procurement, so the same catalog can serve cash-and-carry and credit-account customers.

Bulk Operations and Automated MIS

Admin teams import and export organizations, users, products, orders, and cost centers through Excel. Finance heads receive scheduled MIS order reports when auto-reporting is enabled.

Operational Analytics

Buyer and admin dashboards surface order volume, value, delivery progress, pending approvals, catalogue activity, and wallet position so teams can manage spend from a single view.

Document Vault

GSTIN certificates, profile images, purchase-order files, invoices, and challans are stored on object storage with controlled upload URLs, keeping compliance documents attached to the organizations and orders they belong to.

Notifications Across the Buying Cycle

Firebase push, in-app notification history, and transactional email keep buyers, approvers, and operators informed as RFQs, approvals, payments, and shipments change state.

Organization Onboarding and Team Hierarchy

Companies register with business details and GSTIN, wait for operational approval, then build teams with reporting lines, cost-center mappings, and member-level access.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Engineering

How it's built

ZCommerce is an API-driven, multi-client architecture. Flutter applications for buyers, administrators, vendors, and delivery agents authenticate against role-specific OTP and JWT flows, then call a shared Express API. The API is organized by domain — users, organizations, catalog, cart, catalogue/RFQ, orders, budgets, shipments, invoices, vendors, documents, and notifications — and can run as a long-lived Node server or as a serverless-http function on AWS Lambda behind API Gateway in ap-south-1. Writes that touch money or fulfillment run inside Sequelize transactions against MySQL. Documents and generated PDFs move through S3. Payments settle through Cashfree. Purchase-order files are analyzed by Azure Form Recognizer before becoming orders. Push events leave through Firebase. A policy record on each organization shapes which of those capabilities a given tenant can see.

API-drivenMulti-clientMulti-tenantServerlessRole-based accessTransactional domain servicesCloud-native

Decision

Four product surfaces on one API instead of four backends

Buyer, admin, vendor, and delivery work share catalog, order, and shipment state. Splitting services by app would duplicate the hardest domain rules.

One source of truth for procurement policy, pricing, and fulfillment, with clients that can still feel purpose-built.

Decision

Organization-level feature flags as a policy engine

Enterprises do not buy the same way. Mandatory POs, hidden prices, prepaid checkout, and unique-buyer rules had to be data, not forks.

The same codebase can serve very different procurement cultures without custom builds per tenant.

Decision

Catalogue bidding as a first-class workflow, not a discount field

B2B price is often negotiated. Treating bid, RFQ, discussion, and activation as states makes negotiation auditable and operational.

Buyers and operators share a structured deal process instead of moving prices in side channels.

Stack

ZCommerce is a multi-client Flutter product on a serverless Node.js API, with MySQL as the system of record and AWS as the commercial hosting layer. The stack was chosen so one engineering team can ship buyer, vendor, admin, and delivery experiences without splitting the domain model, while still meeting Indian payment, tax, document, and notification requirements.

FlutterDart and flutter_blocGoogle Fonts / PoppinsNode.js and ExpressSequelizeJSON Web TokensMySQL on AWS RDSAWS Lambda and API GatewayServerless FrameworkAWS S3AWS AmplifyOTP Authentication with SHA-512 hashingRole and token isolationOrganization-scoped data and policyCashfreeFirebase Cloud MessagingSendGrid and transactional emailIndia Postal Pincode API
Process

From brief to shipped product

  1. 01Discovery

    We mapped how Indian businesses actually procure: GST onboarding, cost-center spend, manager approvals, negotiated pricing, purchase orders, and last-mile proof of delivery. The product was scoped as four roles with one shared domain, not as a storefront with an admin theme.

  2. 02Design

    Buyer commerce received a light storefront language with a coral accent. Admin and vendor consoles received a dark operational system built for dense tables and side navigation. Delivery received a focused field UI. Shared components, Poppins typography, and role-specific information architecture kept the suite coherent.

  3. 03Development

    The backend was modeled domain-first — organizations, policy, catalog, RFQ, orders, budgets, shipments, invoices — then exposed as REST with role-aware auth. Four Flutter clients were built on that contract, with Cashfree, Firebase, S3, Azure document intelligence, and GST PDF generation integrated into the live flows.

  4. 04Testing

    Critical paths were exercised as end-to-end procurement stories: onboarding and approval, catalogue negotiation, policy-constrained checkout, L1/L2 release, budget debit, prepaid payment, shipment assignment, invoice generation, and delivery verification.

  5. 05Launch

    The API ships through Serverless Framework to AWS in ap-south-1, web consoles through Amplify, and buyer, vendor, admin, and delivery clients as Flutter builds for mobile and web.

Challenges

Hard problems, clear outcomes

Commerce that behaves like procurement

Problem

A cart and a catalog are not enough when price is negotiated, spend needs approval, and finance needs a PO and a GST invoice. Treating ZCommerce as a B2C storefront would have hidden the real product.

Approach

We designed a dual buying path — immediate catalog checkout and a catalogue RFQ state machine — then wrapped both with organization policy, reporting hierarchy, and cost-center budgets.

Outcome

The platform supports both spot buying and negotiated buying without splitting into two products, and every order still carries the financial and approval context a business requires.

One platform, four jobs

Problem

Buyers, operators, suppliers, and delivery agents need different density, navigation, and trust cues. A single UI would have failed all four.

Approach

We shipped four Flutter applications against one API and one domain model, with distinct visual systems and menus, and token isolation so each client only reaches its own routes.

Outcome

Each role gets a purpose-built workspace while catalog, order, and shipment state remain consistent across the suite.

Tenant policy without product forks

Problem

Some organizations must hide prices, require POs, enforce unique receivers, or run prepaid-only checkout. Hard-coding those rules would have produced a custom build per customer.

Approach

We modeled fourteen organization restrictions as persisted policy and made checkout, catalog, reporting, and MIS read those flags at runtime.

Outcome

A single codebase can present very different procurement experiences per tenant, which is the commercial requirement for a B2B platform.

Statutory finance inside a commerce flow

Problem

Indian B2B buying is incomplete without HSN, GSTIN, CGST/SGST/IGST splits, invoices, and delivery challans attached to shipments and cost centers.

Approach

Tax lives on the product and the order line. Invoices and challans are generated as PDFs and stored with the order. Cost centers carry their own GST identity.

Outcome

Finance can operate from the same system that buyers use to shop, instead of reconciling a storefront against a separate tax tool.

Turning purchase-order documents into live orders

Problem

Enterprise buyers already raise POs outside the app. Re-typing them creates mismatches in SKU, quantity, and tax.

Approach

We placed Azure Form Recognizer at the admin order boundary so an uploaded PO becomes structured order data that can be validated against the catalog.

Outcome

Operations capture official buying documents into the same order lifecycle that approvals, budgets, and shipments already use.

Proof

What this work proves

ZCommerce concentrates the buying journey that usually lives across chat threads, spreadsheets, payment links, and courier tools. Organizations onboard once, configure policy, and then run catalog commerce, RFQ negotiation, approval, budgeting, GST invoicing, and last-mile delivery from a coordinated product suite. The work demonstrates a complete commercial platform: multi-tenant organization design, financial controls, applied document intelligence, and four production-quality client applications on a shared serverless backend.

B2B product strategyMulti-surface information architectureCross-platform mobile engineeringEnterprise UX for commerce and operationsMulti-tenant SaaS architectureRole-based authenticationProcurement and approval workflowsPayments integrationGST and invoice document generationApplied document AICloud-native serverless deliveryBulk operations and reportingLast-mile logistics product design

What's next

AI-guided sourcing and price intelligence

Extend the existing RFQ and catalogue history into recommended bid ranges, supplier alternatives, and buy-versus-negotiate guidance so procurement teams can act on patterns the platform already records.

ERP and accounting integrations

Connect approved orders, GST invoices, and budget ledgers to SAP, Tally, or NetSuite so ZCommerce becomes the buying front end of the customer's existing finance stack.

Supplier performance scorecards

Build vendor analytics on top of the vendor book and shipment history — fill rate, dispute rate, lead time, and bid competitiveness — to support awarded-catalogue decisions.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

Advora — Legal Intelligence & Court Operations Platform

Elevate Communication. Unify Operations. Advance Justice.

View case study