Online stores, dealer portals, subscription commerce and marketplaces built on a business’s own pricing rules

It depends on the selling rules. A ready platform suits a manageable catalogue at published prices with standard shipping and returns. A custom build fits when pricing varies by customer group, slab, scheme or negotiation. It also fits when dealers order against credit limits, or when stock is reserved across a counter and a warehouse. It fits when orders split across sellers or vehicles, or when subscription and route delivery logic is central. The price list and order flow are reviewed first. A hybrid is common, with a platform storefront for retail and a custom portal for the channel.

Yes. This is a large part of the commerce work. Each buyer is placed in a group with its own rate card, quantity slabs, pack and case multiples, minimum order values and product visibility by group or region. Negotiated rates can be set for specific accounts. A quotation flow lets a buyer request a rate, a salesperson approve or revise it, and the approved quote convert into an order. Credit limit and outstanding balance are checked before confirmation, and orders can be held for approval instead of being blocked.

Those the business already uses, in its own accounts. Payments typically cover Razorpay, Cashfree, PayU or a bank gateway, UPI and QR collection, recurring mandates and payment links for orders taken by phone. Delivery covers aggregators such as Shiprocket, direct accounts with Delhivery, Blue Dart or India Post, and a driver view for own delivery. Marketplace seller panels, ONDC, Google Merchant Centre and shopping catalogues are also connected. A partner not on this list has its API checked during discovery.

Yes. Connections cover Tally, Zoho Books, Odoo, a custom ERP or counter billing software, so stock, item masters and rates move between systems. Which system is the master for each figure is agreed before build. Where the software supports live updates, stock syncs on each movement. Otherwise scheduled syncs run at a frequency matched to how fast stock moves. Stock is reserved at order confirmation, which prevents a double sale. Orders and invoices can be written back to accounts.

Yes. Products, variants, images, categories, customers, addresses and order history are moved, and counts and totals are reconciled against the old store before the switch. Search rankings are protected by carrying over the URL structure or mapping old addresses to new ones with permanent redirects. Page titles, product descriptions and structured data are kept. Coupons, reviews and loyalty balances need a decision on what to carry over. The new store runs alongside the old one until sign-off, and the switch is made at a quiet hour.

It depends on pricing and fulfilment rules more than on the number of products. The factors are the complexity of pricing and order rules, the selling channels needed, and whether subscription or multi-vendor settlement is involved. Integrations count when each has a usable API. So do the state of product data and images, whether history must be migrated, and how much of the console staff will run. Discovery ends with channels and modules priced as separate lines, and cost is confirmed after scoping.

It depends on catalogue readiness more often than on development. The factors are how clean the item master, rates, tax codes and images are, and how quickly gateway and courier accounts and test credentials are issued. Exceptions in pricing rules matter too. So do changes a third party must make at its end, the speed of design review comments and the length of the soft launch. Discovery turns these into a dated schedule. Catalogue preparation can run alongside design and build.

It depends on hosting and load planning as well as the selling logic. The commerce side is settled before launch. Catalogue and listing pages are cached, images are served at suitable sizes, the checkout path is kept short, and stock reservation holds when several buyers reach the last unit together. Hosting is sized with room to scale and is monitored. A deeper load rehearsal before a large campaign falls under performance engineering, which is scoped separately when a situation calls for it.

The order is marked paid from the gateway’s server-to-server confirmation against the business’s reference, not from the browser redirect. A dropped connection after payment therefore does not leave money unmatched. This failure is designed for. A customer pays, the bank confirms, and the app closes before the order is written. Where a confirmed payment still cannot be matched to an order, it is flagged for review against the gateway settlement report. Heavy sale days are where this matters most.

Card details do not reach the business’s servers. Payments use the gateway’s hosted or tokenised flow, so card numbers are not stored. Traffic runs over encrypted connections and passwords are stored hashed. Admin access is role-based, with an audit trail of who changed prices, orders or refunds. API keys are kept encrypted outside the code. Security updates apply to platform and server components, backups are automated with a tested restore, and a signed NDA covers confidentiality before discovery begins.

Yes. The client receives the complete source code and repository access, the database, the catalogue and pricing documentation and the runbook. Gateway, courier, messaging, cloud and domain accounts are created in the client’s business name. Customer, order and product data can be exported at any time. Nothing is licensed back to the client, and nothing depends on GullySystem remaining involved. On a platform build, the client keeps its own platform account and the custom code written on it.

Yes. Training covers the people who maintain the catalogue and prices, process and dispatch orders, and handle returns and refunds. It is given in plain language, with short written guides for each role. After launch, a support arrangement can cover monitoring, bug fixes, security and platform updates, courier and gateway changes, catalogue and campaign support and performance checks before peak periods. New features are added as the selling model changes.

Four things. First, a clean item master with codes, units, tax rates and current prices, along with product images and descriptions. Second, a written statement of pricing and discount rules, including exceptions that people currently handle from memory. Third, permission to raise gateway, courier and messaging accounts in the business’s name, with access to the software that holds stock and ledgers. Fourth, one person from operations who can decide business rules such as who gets which price, when cash on delivery is allowed and how a return is approved.