DEV Community: ZANISS SOFTWARES

Integrating India's GST e-Invoice IRP API: A Developer's Guide to IRN Generation in 2026

ZANISS SOFTWARES — Mon, 09 Nov 2026 05:24:31 +0000

If you're building or maintaining billing software for the Indian market, you've probably hit the point where "just print an invoice" stopped being good enough. Since August 2023, any business crossing ₹5 crore in aggregate turnover has to get every B2B invoice registered with a government Invoice Registration Portal (IRP) before it's legally valid — and the integration details matter more than most teams expect going in.

The flow itself is simple on paper: serialize your invoice into the prescribed JSON schema, POST it to an IRP or GSP endpoint, get back a 64-character IRN plus a signed QR code, and embed both on the customer-facing invoice. The complexity is in everything around that one call — strict schema validation, IRP sandbox quirks, and a 30-day hard cutoff for any business over ₹10 crore AATO. Keep those thresholds in config rather than hard-coding them: they reflect the rules as of late 2026, and GSTN has changed them several times before.

Five IRPs currently handle this in production: NIC's free government portal, and four GSTN-approved private IRPs (ClearTax, Cygnet, IRIS, EY). Most serious integrations go through a GST Suvidha Provider (GSP) rather than hitting the IRP raw.

If you're scoping this for a client or your own product, the real engineering work isn't the API call — it's the retry logic, idempotency handling, and a reconciliation layer that flags anything stuck in a pending or failed state before the 30-day window closes. Full cost and architecture breakdown: https://zanisssoftwares.com/blog/gst-e-invoicing-api-integration-cost-india-2026

Why Your Hotel's Channel Manager Is the Most Important Line of Code You'll Ship This Year

ZANISS SOFTWARES — Sat, 07 Nov 2026 05:25:33 +0000

If you've ever built an integration that has to be right 100% of the time or someone loses money, you already understand why hotel channel managers are an underrated engineering problem.

Here's the shape of it: a hotel has, say, 40 rooms. Those 40 rooms are listed on MakeMyTrip, Booking.com, Goibibo, and the hotel's own website. The moment a guest books room 12 on any one of those four surfaces, the other three need to know room 12 is gone — ideally within seconds, never with a multi-minute lag, and never with a silent failure that lets two guests show up for the same room on the same night (the industry calls this an "overbooking," and it is exactly as bad as it sounds for a 40-room property with no overflow capacity).

The naive approach is a cron job that polls each OTA's inventory API every few minutes and reconciles. It mostly works until volume spikes during a festival weekend, at which point race conditions between two near-simultaneous bookings on two different channels become a real, recurring bug — not a theoretical one.

The approach that actually holds up in production treats the property's own inventory table as the single source of truth and pushes availability deltas outward on every state change, with OTA webhooks (where available) supplementing rather than replacing that push. Idempotency keys on every write matter more here than in almost any other CRUD system I've worked on, because a retried webhook that double-decrements inventory is a financial incident, not a log line.

On a recent build for a multi-property hotel group in India, we scoped this channel manager layer at roughly ₹9–22 lakh depending on how many OTAs and properties were in play — meaningfully cheaper than licensing an enterprise PMS like Opera for a mid-sized group, while giving the client full ownership of the sync logic instead of being locked into a vendor's black box. Treat that range as a starting point rather than a quote: the number of OTAs, each OTA's certification process and your property count move it more than anything else.

The other half of the stack — GST-compliant billing, a guest CRM, and WhatsApp-based guest messaging — all hang off that same inventory core, which is the real argument for building this as one coherent system rather than bolting together five SaaS tools that each have their own idea of "the truth."

We wrote up the full cost breakdown and build timeline here: https://zanisssoftwares.com/blog/travel-hospitality-software-development-india-2026

Curious what other engineers here have run into with inventory-sync systems that have real financial consequences on a race condition — booking platforms, ticketing, limited-inventory e-commerce. The patterns rhyme a lot more than I expected going in.

Building an Order Management System for Indian D2C Brands: What It Actually Costs to Sync Stock Across Channels

ZANISS SOFTWARES — Fri, 06 Nov 2026 05:24:27 +0000

If you're an engineer at a D2C brand or agency in India, you've probably been handed the "why does the website say in-stock when the warehouse is empty" ticket more than once. That bug is almost never a bug — it's a missing (or badly built) order management system (OMS).

The core engineering problem is straightforward to state and genuinely hard to get right: every channel — your storefront, 2-4 marketplaces, maybe a POS at a kiosk — needs to read from one source of truth for stock, and every order needs to be routed to the fulfillment point with that stock, in real time, without double-booking the same unit. Platforms like Unicommerce solve this generically for standard retail flows; the moment your fulfillment logic has brand-specific rules (store-level promos, B2B pricing tiers, complex bundles), you're often better off building the sync layer yourself.

We recently broke down the actual cost tiers for this in the Indian market — from a ₹1.5L point-to-point sync between a storefront and Tally, up to an ₹8L–₹25L custom OMS handling 4+ channels with a loyalty engine attached. Treat those ranges as a starting point: channel count, SKU volume and the state of your existing systems will move them. If you're scoping a similar build, the full cost and architecture breakdown is here: Retail & D2C Software Development in India 2026.

A few implementation notes worth sharing from our builds: idempotency keys on every order-sync webhook save you from the "marketplace retried and double-decremented stock" class of bug; and GST e-invoicing (mandatory above ₹5 Cr AATO in 2026) means your billing service now needs a hard dependency on the government's IRP being reachable — build a retry queue for that path, don't assume synchronous success. One scoping note: that threshold has applied since August 2023 and covers B2B invoices rather than walk-in consumer sales, so check how it applies to your invoice mix before you build for it.

Integrating MES with SAP and Legacy PLCs in India: What It Actually Costs (2026 Data)

ZANISS SOFTWARES — Thu, 22 Oct 2026 05:25:26 +0000

If you've ever been asked to "just connect the shop floor to SAP," you already know the quote that follows is rarely as simple as the ask. We pulled together 2026 India market data on Manufacturing Execution System (MES) builds — specifically the integration cost, not just the headline MES price — because that's usually where scope creep actually lives.

A few numbers worth internalizing if you're scoping one of these projects: SAP S/4HANA integration alone adds 40-60% to a base MES build, and a single production-order-to-confirmation sync can eat 4-6 weeks on its own. Machine connectivity swings even harder by protocol — Modbus RTU, OPC-UA and Allen-Bradley Ethernet/IP are commodity work at roughly ₹50,000-₹1,00,000 per machine, but anything proprietary or legacy jumps to ₹2,00,000-₹5,00,000 per machine. If you're estimating a multi-line rollout as "the same integration five times," budget for it not to be — each line with different equipment or quality-check steps adds its own 15-25% on top. Treat those ranges as a starting point rather than a quote: your PLC mix, machine age and how clean your existing ERP data model is will move them, so price your own hardest line before committing to a budget.

The compliance angle matters here too, even for a backend-focused build: India's e-invoicing mandate (Notification No. 10/2023-Central Tax) kicks in once a business crosses ₹5 crore in aggregate turnover in any year since FY 2017-18, and it doesn't switch off if turnover later drops. If your MES build touches finished-goods data that flows into invoicing, that 30-day IRN reporting window for ₹10 crore+ turnover businesses (effective April 2025) is a real constraint on your data pipeline design, not just a finance team problem.

We wrote up the full cost breakdown — including a tier-by-tier pricing table and the decision checklist we run with manufacturers before quoting — on the ZANISS SOFTWARES blog: https://zanisssoftwares.com/blog/manufacturing-software-development-india-2026

Jira, Linear, Azure DevOps or Notion: What an Indian Engineering Team Should Actually Pick in 2026

ZANISS SOFTWARES — Mon, 19 Oct 2026 06:59:10 +0000

If you're an engineer who's been handed the job of picking (or defending) your team's tracker, here's the version of this decision that skips the sales pages. Linear is the one most of us actually enjoy using day to day — keyboard-first, cycles instead of mushy sprints, 250 free issues and two teams before you pay anything, then about $10/seat/month (Basic) or $16/seat/month (Business) once you outgrow that. It does almost nothing for non-engineers, which is either a feature or a dealbreaker depending on your org chart.

Jira is the tool you end up on anyway once a PMO, a client success team, or a compliance function needs cross-project reporting — Standard runs about $7.91/user/month, Premium about $14.54/user/month, and Premium is where Advanced Roadmaps and a 99.9% uptime SLA kick in. Azure DevOps is worth a hard look only if your team is already paying for Visual Studio or running GitHub Enterprise through Entra ID — the Basic plan's first five seats are free, then roughly $6/seat/month, and it comes with Repos and a baseline amount of Pipelines bundled in, which can genuinely undercut Jira if you're already in that ecosystem. Notion is the dark horse: not built as a tracker, but its database views cover basic kanban needs well enough that a lot of 10–20 person teams run on Plus ($10/member/month) or Business ($20/member/month) for docs and lightweight tracking combined, until sprint reporting outgrows it. Treat those numbers as list prices at the time of writing, not quotes: check each vendor's pricing page before you budget, because tiers change and annual contracts above 20–25 seats are usually negotiable.

The actual engineering decision isn't which tool is "best" — none of them are universally best — it's whether your team's reporting and process needs match what each tool assumes by default. We wrote up the full cost and decision breakdown, including a 20-person team cost table in INR, here: Software Project Management Tools for Indian Tech Teams in 2026.

Modeling RERA Escrow Rules in a Real Estate Platform's Data Layer (India, 2026)

ZANISS SOFTWARES — Fri, 16 Oct 2026 05:25:35 +0000

Most write-ups about real estate software in India talk about RERA as a legal checkbox. From an engineering seat, it's closer to a state machine problem. Section 4(2)(l)(D) requires 70% of buyer collections to sit in a project-scoped escrow account, released only against construction milestones — which means your payments module needs a ledger keyed on project ID, not just buyer ID, with milestone-gated release states rather than a simple paid/unpaid flag.

Then there's the advertising layer. MahaRERA now requires every new-project ad creative to carry a QR code linking straight to that project's MahaRERA registration page. If your CMS generates ad creatives programmatically, that's a small but real pipeline step: generate the code, embed it, and keep a record of which creative version shipped with which registration status, since registration data can change mid-campaign.

The harder problem is reconciliation. State RERA portals — GRERA in Gujarat, MahaRERA in Maharashtra, and others — are becoming the system of record your own listings have to check against. A property marked "available" that hasn't been reconciled against current registration status is a correctness bug with legal consequences, not just a stale-cache issue. We've found a nightly reconciliation job against the relevant state portal, with a diff log for anything that doesn't match, is the simplest version of this that actually holds up.

None of this needs to be built on day one for a single-project brochure site. It becomes unavoidable the moment you're aggregating listings across projects or developers. We wrote up the fuller cost and architecture breakdown, including where this logic tends to live in each pricing tier, in the original piece.

Full breakdown with INR cost tiers: Real Estate Software Development in India 2026 →

Redesign, Optimise, or Rebuild? A Decision Framework for Your Website's Architecture

ZANISS SOFTWARES — Tue, 13 Oct 2026 05:26:15 +0000

When a client says "our website needs a redesign," what they usually mean is "something about our website is failing us" — and those are two very different engineering problems. Before touching a single component, we run three diagnostic questions: Is the platform itself sound (supported CMS, acceptable security posture, able to scale)? Is the UX/IA meeting business goals? Is the gap narrow enough to be a targeted fix (Core Web Vitals, a broken funnel, stale content)?

If the platform fails the first question — end-of-life CMS, plugin-stack fragility, no API-first path to the integrations the business now needs — no amount of new CSS fixes it. That's a rebuild: new architecture, often a move toward headless content delivery, and a proper data-migration plan. If the platform is fine but the experience layer isn't, that's a redesign: same CMS, same hosting, new design system and IA, content migrated across. If both pass and the problem is isolated — LCP, INP, CLS, a specific conversion funnel — that's an optimisation sprint, and it should stay scoped that way.

We cover the full cost breakdown (2026 India pricing: ₹35,000 for optimisation sprints up to ₹30,00,000+ for full platform rebuilds) and the complete decision framework in the original article: Website Redesign Cost in India 2026: When to Redesign vs Optimise vs Rebuild. Treat those ranges as indicative rather than a quote: page count, integrations and how much content has to move all shift the number, so scope your own site before you budget.

Curious how other teams have drawn this line — at what point did "redesign" actually mean "our CMS can't do this anymore" for you?

Chatbot, AI Agent, or Human: What I'd Actually Build for Customer Support in 2026

ZANISS SOFTWARES — Sat, 10 Oct 2026 05:25:28 +0000

If you're a developer being asked to "add AI to our support," you're actually being asked to choose between three distinct architectures, and the choice changes your whole implementation.

A rule-based chatbot is just an intent classifier plus a decision tree — cheap to ship, cheap to maintain, and fundamentally incapable of handling anything outside its scripted intents. No memory, no reasoning, no tool calls.

An AI agent is a different system entirely: an LLM with function-calling access to your order, payments, and CRM APIs, plus a memory layer that carries context across turns (and ideally across a customer's full history). Implementation complexity jumps immediately once you add tool calls — you're now building permission scoping (what can the agent actually do without a human sign-off?), idempotency handling for actions like refunds, and a RAG layer if you want it grounded in your own docs instead of hallucinating policy details.

The part most teams underbuild is the escalation state machine. It's tempting to treat handoff as an exception path, but it should be a first-class state with its own triggers: confidence score below threshold, specific keyword matches, repeated unresolved turns, and a context-passing payload that gives the human agent the full transcript instead of a cold start.

On cost: outcome-billed platforms like Intercom Fin charge per resolution (~$0.99), which is easy to reason about at low volume and surprisingly expensive at scale — do the math against your own LLM API costs before assuming "buy" beats "build."

We went deep on the actual INR cost tiers — SaaS vs custom RAG build — for the Indian market in a longer piece: AI-Powered Customer Support in India 2026: Chatbot vs AI Agent vs Human Handoff.

If you're scoping this for a production system, the escalation state machine and the tool-call permissioning are the two things worth over-engineering relative to everything else.

Building AIS-140-Compliant Fleet Tracking in India: A Developer's Guide to the 2026 Mandate

ZANISS SOFTWARES — Fri, 09 Oct 2026 05:27:22 +0000

If you're building fleet or logistics software for the Indian market, AIS-140 isn't optional reading — it's the spec your ingestion layer has to be built around from day one. It mandates dual-constellation GNSS (GPS + NavIC) with 5-meter minimum accuracy, location pings every 30 seconds while the vehicle is moving, a hard-wired panic button input, tamper/SIM-removal detection, at least 6 hours of local buffering for connectivity drop-outs, and a standardized packet format that forwards to the government's NVLT portal and the Vahan database.

A few implementation details that matter more than they look: the 30-second ping interval during movement means your backend needs to handle bursty, high-frequency writes per vehicle — don't assume a sparse polling model. Tamper detection has to be a device-side event, not something you infer server-side from missing pings, because the standard expects real-time alerts, not retroactive detection. And because enforcement checks (permit renewal, roadside checks) hit the Vahan database directly, your data format validation needs to happen before transmission, not after — a malformed packet isn't just a bug, it's a compliance gap for your client's fleet.

Cost-wise, device hardware runs ₹3,000–₹8,000, with SIM/data plans at ₹500–₹1,500/year and backend subscriptions at ₹500–₹3,000/year — cheap enough that the real engineering cost is in the ingestion pipeline and alerting logic, not the hardware. Treat those numbers as indicative ranges rather than a quote: certified-device vendors, fleet size and data-plan terms all move them, so price your own fleet before you budget. We go deeper on the full stack — WMS, TMS and last-mile routing layered on top of the tracking foundation — in the complete cost breakdown: Logistics & Supply Chain Software Development in India 2026.

If you're architecting around AIS-140, building the tamper-detection and alerting pipeline as a first-class event stream (rather than bolting it on later) will save you a rewrite once a client's compliance audit finds the gaps.

Building UPI Payments Into Your App in 2026: What Razorpay, Cashfree, PayU and Autopay Actually Cost You

ZANISS SOFTWARES — Thu, 08 Oct 2026 05:25:15 +0000

If you're wiring UPI into an Indian app right now, the engineering decisions you make this month will hit your margins differently after October 15, 2026, when NPCI's new 0.4% MDR on UPI P2M transactions above ₹2,000 kicks in. Here's the developer-level version of what changed and what it means for how you build.

The gateway layer itself hasn't changed much — Razorpay, Cashfree and PayU all still sit at roughly 2% + GST for cards, zero setup fee, and (until now) zero MDR on UPI. What's new is that your backend now needs to know, per transaction, which MDR bucket it falls into: standard P2M (0.4% above ₹2,000, capped at ₹300 on tickets ≥ ₹75,000), sector flat-fee (₹5 flat for insurance/fuel/utilities/education), capital markets (0.02%), or small-merchant-exempt (static QR, under ₹1 lakh/month). That's a data-modeling problem before it's a UI problem — your transaction schema needs a category field that didn't need to exist a year ago.

If you're building recurring billing, the bigger engineering lift isn't the MDR change at all — it's UPI Autopay (still colloquially "UPI 2.0"), NPCI's e-mandate framework. You need mandate-creation flows, pre-debit notification handling, execution retry logic on insufficient balance, and mandate revoke/pause states, all of which are priced separately from one-time Collect/Intent transactions (Cashfree, for example, publishes roughly ₹7.50 per mandate creation and ₹5–15 per execution depending on ticket size).

Practically, this breaks into three build tiers: a basic single-gateway UPI Collect/Intent checkout is a 1–2 week job; add a second PSP for failover plus Autopay mandates and you're at 3–5 weeks; go full Payment Aggregator with direct bank certification and multi-bank switch failover and you're looking at 2–4 months. Treat those timelines as a starting point, not a promise: your existing backend, team size and how much reconciliation you automate will move them in either direction. We wrote up the full cost breakdown with INR figures and a decision framework for which tier actually fits your app's transaction profile: UPI Payment Gateway Integration Cost for Indian Apps in 2026.

Curious what other dev teams are doing about the MDR-category tagging problem specifically — anyone building this as a rules engine vs. hardcoding the thresholds?

Implementing Passkeys in 2026: A WebAuthn Walkthrough for Indian SaaS Teams

ZANISS SOFTWARES — Wed, 07 Oct 2026 05:27:28 +0000

If you're still shipping bcrypt-hashed passwords in 2026, you're maintaining infrastructure to protect a secret that shouldn't need protecting in the first place. Passkeys sidestep the whole category of problem: the browser's navigator.credentials.create() call generates a public/private key pair on the device, your server only ever stores the public key, and the private key never crosses the network.

A minimal registration flow looks like this conceptually: your server issues a challenge, the client calls WebAuthn's create() with that challenge plus relying-party ID, the device prompts for biometric/PIN unlock, and the resulting attestation gets verified and stored server-side against the user. Login is the mirror image with get() instead of create(). No password field, no OTP SMS gateway bill, no bcrypt rounds tuning.

The parts that actually take engineering time aren't the happy path — they're the fallback for browsers/devices without WebAuthn support, the account-recovery flow when someone loses their only enrolled device, and cross-device testing across Safari/Chrome/Android WebView, which behave subtly differently around resident keys and platform authenticators. Budget real QA time here; it's where most passkey rollouts actually slip.

We wrote up the full cost breakdown and phased migration roadmap we use with Indian SaaS and enterprise clients — worth a read if you're scoping this for your own stack: https://zanisssoftwares.com/blog/passwordless-authentication-passkeys-india-2026

Integrating with ONDC's Beckn Protocol: A Practical Guide for Indian Dev Teams (2026)

ZANISS SOFTWARES — Tue, 06 Oct 2026 05:24:45 +0000

If you've been asked to "add ONDC support" to a client's e-commerce backend, here's the technical reality: ONDC isn't an SDK you drop in, it's an implementation of the Beckn Protocol, an open API specification for decentralized commerce built on discovery, order, fulfillment, and settlement transaction flows between a Buyer App (BAP) and Seller App (BPP).

For most dev teams, the practical entry point isn't building a full Network Participant from scratch — it's building a middleware connector that maps your client's existing product and order APIs into Beckn-compliant JSON payloads, validates against ONDC's sandbox, and handles the async callback pattern the protocol uses (search → on_search, select → on_select, and so on through confirm/status/cancel).

Three things catch teams off guard: the callback-based async flow requires a message-queue-backed architecture rather than simple synchronous request/response; catalog data needs structured attributes (category codes, GTIN/HSN where applicable) that most existing product databases don't have cleanly; and settlement reconciliation across multiple buyer apps needs its own ledger logic if you're running as a Network Participant rather than through an aggregator.

We recently wrote up the full cost and architecture breakdown for the three integration paths — aggregator listing, middleware connector, and full custom BPP — with real 2026 INR pricing for each: ONDC Integration for Indian Businesses in 2026 →

If you're scoping an ONDC integration for a client, start with the connector path unless they specifically need to onboard other sellers under their own brand — it's a fraction of the engineering effort of a full BPP build.