DEV Community: ZANISS SOFTWARES

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.

AI Governance in 2026: The MLOps Infrastructure Nobody Budgets For

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

Every team shipping an LLM feature eventually hits the same wall: the model works in the demo, but nobody can answer "who owns this in production, how do we know if it drifts, and what happens when it's wrong." That's not a legal problem, it's an infrastructure gap — and in India specifically, it's becoming an expensive one fast.

The numbers back this up. Enterprise AI investment in India grew 119% year over year, but a recent industry study found only 22% of Indian enterprises actually have testing, auditing, and risk-assessment processes around what they've shipped. The country's AI governance maturity score sits at 55/100 against a regional Pacesetter benchmark of 78 — a 23-point gap that tracks almost exactly with the ROI gap between governed and ungoverned AI deployments (149% ROI for mature-governance orgs vs. meaningfully less for everyone else).

From an engineering standpoint, "governance" breaks down into four concrete, buildable things:

A model registry — not a wiki page, an actual queryable inventory: every model/agent in prod, its owner, its data sources, its review cadence.
MLOps monitoring — drift detection, automated retraining pipelines, version control with rollback, centralized audit logging. This is the part that turns governance from a policy doc into something enforceable.
Escalation protocols — a defined path (with a human in the loop) for when a model's output deviates from expected parameters, especially for anything touching a high-stakes decision.
Audit functions — scheduled internal or third-party review of outputs against both business goals and whatever regulatory surface applies (DPDPA at minimum, RBI/SEBI overlays if you're in fintech).

None of this is exotic — most teams already have fragments of it (a logging pipeline here, a security review process there). The actual work is stitching it into one system someone owns end to end, instead of leaving it distributed and undocumented.

Worth knowing if you're in India specifically: MeitY published the country's AI Governance Guidelines in November 2025 — currently voluntary, but I'd bet on it becoming a de facto procurement/audit checklist within a couple of budget cycles, the way a lot of "voluntary" frameworks do.

Full writeup, including the four-pillar framework and real INR cost ranges for building this out: AI Governance for Indian Businesses in 2026

Curious how other teams are handling model registries in practice — homegrown tooling, or has anyone found a vendor platform that doesn't feel like overkill for a mid-sized deployment?

Flutter vs React Native in 2026: What Actually Changed Under the Hood

ZANISS SOFTWARES — Sun, 04 Oct 2026 05:29:52 +0000

Every year someone reopens the Flutter vs React Native debate, and every year most of the takes are stale by six months. This year the underlying tech genuinely moved, so here's what's actually different if you're picking a framework in 2026.

React Native's New Architecture is the real story on that side: Fabric replaces the old async bridge with direct native UI manager communication, TurboModules load on demand instead of eagerly, and JSI lets JS call into C++ host objects synchronously. Combined with Hermes precompiling to bytecode, cold starts land around 350ms — a big improvement over the old bridge-era numbers, even if it's still behind Flutter.

Flutter's Impeller 2.0 attacks a different bottleneck: shader compilation jank on first paint. Precompiling shaders at build time instead of runtime means Flutter apps hit 120fps with reportedly 0% dropped frames in benchmark testing, and Dart's AOT compilation to native machine code means there's no bridge at all to bottleneck through.

Things worth knowing if you're mid-decision:

If your UI is animation-heavy (custom charts, gesture interactions, anything gaming-adjacent), the Impeller 2.0 numbers are hard to ignore — this is where the performance gap is largest and most visible to users.
If you already have a React/TypeScript team, the retraining cost to Dart is real and often underestimated. Factor it into your timeline, not just your framework comparison spreadsheet.
AI coding assistants currently write noticeably better React Native code than Flutter code on the first pass, simply because there's more JS/TS training data out there. Worth knowing if your team leans on Copilot/Cursor-style tooling heavily — this gap is closing but hasn't closed yet.
There's no meaningful migration path between the two. Don't pick either as a "placeholder."

I wrote up the full 2026 cost and performance breakdown, including real India-market INR pricing by project tier, here: https://zanisssoftwares.com/blog/flutter-vs-react-native-2026

Curious what others are seeing in production with the New Architecture — has Fabric closed the gap enough for your use case, or are you still hitting frame drops on complex screens?

The IAM Mistakes That Turn a Cloud Misconfig Into a Breach (India, 2026)

ZANISS SOFTWARES — Sat, 03 Oct 2026 05:29:24 +0000

If you've ever copy-pasted an IAM policy from a tutorial to unblock a deploy on a Friday afternoon, this one's for you.

Cloud misconfigurations now account for roughly 15% of initial attack vectors in data breaches — not zero-days, not exotic exploits, just doors left open. Palo Alto's research found 65% of cloud network security issues trace back to plain user error. As engineers, that statistic is on us more than it's on any attacker.

The pattern I keep seeing in audits: a security group opened to 0.0.0.0/0 "just to unblock testing," an S3 bucket or Azure Blob container made public during a demo and never locked back down, an IAM role scoped from a Stack Overflow answer instead of least-privilege from day one, a departing contractor's access key that never got rotated out.

None of these look dangerous in a PR review. Stacked across a few dozen services and a couple of cloud accounts, they're exactly what shows up in the post-incident timeline six months later — and misconfiguration breaches take an average of 186 days to detect and another 65 to contain, per IBM's Cost of a Data Breach Report. That's 251 days of live exposure most teams don't know they're carrying.

The fix isn't heroic — it's process: automated drift detection against a CIS benchmark, IAM access reviews on a schedule instead of "when someone remembers," and treating staging/sandbox accounts as seriously as production, because that's where we keep finding real customer data that was never supposed to be there.

I wrote up the full cost breakdown for running this as an actual program in India in 2026 — assessment, remediation sprint, and continuous monitoring pricing — over on the ZANISS SOFTWARES blog: Cloud Security Posture Management in India 2026. Worth a read if you're the one who inherited "cloud security" as an unofficial fourth of your job description.

Why Your App's Store Listing Is Costing You Installs in 2026 (An ASO Primer for Builders)

ZANISS SOFTWARES — Fri, 02 Oct 2026 05:26:41 +0000

Most engineering teams ship the app and hand the App Store / Play Store listing to whoever's free that week. In 2026, that's a measurable mistake — and it's fixable in an afternoon.

Here's the technical reframe: both Apple and Google now run their store search as an intent-matching system, not a keyword-frequency index. Apple's 2025 search algorithm update pushed ranking toward semantic matching — the store tries to infer what a searcher actually wants rather than rewarding exact keyword repetition. Google Play's Guided Search does the same thing on the Android side, organizing results by inferred intent. If your metadata reads like a keyword-stuffed list instead of natural, benefit-led copy, you're now actively working against the ranking model, not with it.

The part that should interest anyone who ships product: screenshot text is now a parsed ranking input on iOS, not just a UI element users glance at. Google Play has gone further and folded post-install engagement and retention signals directly into ranking — meaning a spike in day-1 uninstalls from a buggy release doesn't just hurt your reviews, it can measurably suppress your organic search rank for weeks afterward. ASO and app quality are no longer separable disciplines; they're reading from the same data.

A few numbers worth internalizing if you're deciding how much engineering/design time to allocate here: properly optimized listings see roughly 60% more organic installs than un-optimized ones, and store-page conversion rate benchmarks currently sit around 33% on iOS and 26% on Google Play — meaning even a well-built app is losing two-thirds to three-quarters of its store-page visitors before they ever tap install. That gap is almost entirely closeable with better screenshots, a benefit-led description, and (increasingly) portrait-format preview video, which is converting about 5% better than landscape or static assets in early 2026 data.

Two engineering-adjacent implementation notes if you're doing this yourselves: Apple's Custom Product Pages now support up to 70 variants per app and — new as of the 2025/2026 update — these can be linked to and surfaced in organic search results, not just paid campaign traffic. That means you can legitimately build separate, keyword-targeted listing variants for different use cases of the same app (e.g. a fleet-tracking app could run separate CPPs for "driver app," "dispatch software," and "fleet tracking") without maintaining separate app binaries.

We wrote up the full cost breakdown and decision framework — including what a properly resourced ASO program costs in the Indian market in 2026 and when it's actually worth the investment versus premature — in a longer piece here: https://zanisssoftwares.com/blog/app-store-optimization-cost-india-2026