DEV Community: Arpit Mishra

5 Things I Learned Working With a Lead BA On a Cross-Border EHR System

Arpit Mishra — Tue, 21 Jul 2026 07:06:15 +0000

I spent the last several months on a project connecting patient records across two countries' hospital systems — call it a cross-border EHR integration. Our lead Business Analyst had spent over a decade in clinical informatics before moving into BA work, and pairing with her fundamentally changed how I think about healthcare software. Here are the five things that actually stuck.

Terminology mapping is a harder problem than data mapping

As engineers, we tend to think of integration as a schema problem: map field A to field B, write a transform, done. That mental model breaks almost immediately in healthcare.

The two health systems we connected used different diagnostic coding standards — one was still primarily on ICD-10-CM, the other had partially migrated to ICD-11. Neither maps cleanly onto the other; ICD-11 restructured entire chapters and introduced post-coordination (the ability to combine codes to represent a more specific clinical concept) that has no direct ICD-10 equivalent. The same problem showed up with lab results: one side used LOINC consistently, the other had years of legacy data coded with internal lab identifiers that predated LOINC adoption.

Our BA built what she called a "concept crosswalk" before we wrote a line of integration code — a living spreadsheet, later a proper terminology service, mapping local codes to a canonical set (SNOMED CT for clinical findings, LOINC for observations, RxNorm for medications). Skipping that step and mapping database fields directly would have silently corrupted clinical meaning, not just data format.

Lesson: In most software integrations, a broken field mapping produces an obviously wrong value. In healthcare, a broken terminology mapping produces a plausible but clinically wrong value — which is far more dangerous and far harder to catch in QA.

Data residency law shapes the architecture before a single API is designed

I came in assuming we'd design the data model first and figure out compliance around it. That's backwards for cross-border health data.

Patient data crossing a border touches multiple regulatory regimes simultaneously — HIPAA if U.S. data is involved, GDPR-style data protection rules if EU or adjacent jurisdictions are in play, plus whatever local health-data-sovereignty law applies to the source country's records. Some jurisdictions restrict health data from leaving the country at all except under narrow conditions (research consent, direct patient request, specific treatment continuity exceptions). Our BA sat with legal and compliance early to determine which fields could replicate across the border, which required de-identification first, and which couldn't leave the source system's jurisdiction under any circumstance.

That produced constraints that reshaped the whole architecture: a federated query layer instead of a single replicated database, per-field data classification tags baked into the schema, and an audit trail granular enough to prove exactly which fields crossed the border, when, and under what legal basis.

Lesson: For cross-border health projects, get compliance and a BA who understands regulatory nuance into the room before the data model exists, not after. Retrofitting data residency controls onto an already-designed schema is significantly more expensive than designing around them from day one.

Interoperability standards are necessary but nowhere near sufficient

Both hospital systems technically supported HL7 — but one was still running on HL7 v2 messaging (ADT feeds, ORU results messages) from its core legacy EMR software, while the other had adopted FHIR R4 for newer services but kept HL7 v2 running underneath for older modules. "Both support HL7" turned out to mean two systems that couldn't talk to each other without a translation layer.

We ended up building a FHIR-facing integration layer with HL7 v2-to-FHIR adapters on the legacy side, since rewriting the older EMR software's messaging interface wasn't on the table. Even within FHIR, we hit profile mismatches — both systems claimed FHIR R4 compliance, but used different implementation guides (US Core vs. a regional equivalent) with different required fields and different extensions for locally significant data like national health identifiers.

Lesson: "We support HL7/FHIR" is a starting point for a conversation, not confirmation that integration will be straightforward. Always ask which version, which profile, and which implementation guide — and budget real time for an adapter layer even between two "standards-compliant" systems.

A BA's workflow diagrams catch edge cases engineers structurally miss

Early on, I treated our BA's clinical workflow diagrams as documentation overhead — nice for stakeholders, not essential for building the thing. I was wrong.

She mapped out cross-border patient transfer scenarios in detail: what happens when a patient is referred mid-treatment, what happens to an active medication order when care crosses jurisdictions with different prescribing rules, what happens when a lab result returns after the patient has already been discharged back across the border. None of these are edge cases from a clinical standpoint — they're Tuesday. But they're exactly the scenarios engineers miss when we design against the happy path of "patient exists in System A, gets copied to System B."

Several of these workflows directly changed our data model — for example, we added an explicit "care episode" concept spanning both systems, rather than treating each system's encounter records as independent, because the clinical reality was one continuous episode of care crossing a border partway through.

Lesson: Workflow diagrams from someone who actually understands clinical operations aren't a documentation nicety — they're a requirements-gathering technique that surfaces edge cases no amount of engineering-side analysis will find on its own.

A shared glossary should exist before the first requirements doc, not after the first miscommunication

This sounds obvious in retrospect, but it cost us real time before we fixed it. Words like "encounter," "episode," "active patient," and even "discharge" meant subtly different things in each health system's source EMR software and in each country's clinical documentation conventions. An "active" patient in one system meant currently admitted; in the other, it meant open in the record system regardless of admission status. We had at least two requirements documents reviewed and signed off on with each side interpreting a shared term differently, which surfaced only during integration testing.

Our BA eventually built a shared glossary as a living document, reviewed jointly by both sides' clinical and technical stakeholders, with every ambiguous term defined explicitly and versioned alongside the requirements. Every subsequent requirements doc referenced it directly instead of re-defining terms inline.

Lesson: In any project spanning two organizations — let alone two countries and two regulatory regimes — assume every domain term is ambiguous until it's explicitly defined in a document both sides have actually agreed to, not just skimmed.

Closing thought

None of these lessons are really about EHR systems specifically — they're about what happens when domain complexity (clinical workflows, regulatory law, terminology standards) outpaces what a typical engineering requirements process is built to handle. A strong BA doesn't just translate stakeholder requests into tickets; on a project like this, she was closer to a systems architect for everything outside the codebase — regulatory constraints, clinical semantics, and cross-organizational communication. If you're building or integrating EMR software across borders, budget real time and real headcount for that role. It's not overhead — it's the thing that keeps a technically correct integration from becoming a clinically wrong one.

AI, Open Banking, and Embedded Finance: What Developers Should Learn Before 2027

Arpit Mishra — Mon, 20 Jul 2026 05:31:00 +0000

Fintech isn't a niche anymore — it's infrastructure. The global fintech market is projected to grow from roughly $395 billion in 2025 to $1.76 trillion by 2034 (Fortune Business Insights), and the interesting part for us as developers is where that growth is happening: at the intersection of AI, open banking APIs, and embedded finance.

If you write backend services, mobile apps, or platform integrations, there's a decent chance you'll touch financial functionality in the next two years — even if you never join a "fintech company." Here's a practical breakdown of what's changing, and what's actually worth learning before 2027.

AI Is Now a Core Fintech Primitive (Not a Feature)

The AI-in-fintech market is sitting at ~$36.6 billion in 2026 and heading toward $99 billion by 2031 (Mordor Intelligence). Around 90% of financial institutions already run AI for fraud detection, and ~80% of US stock trades are executed by algorithms (BusinessStats).

What that means in practice for developers:

Fraud detection is a streaming problem. Modern fraud systems score transactions in milliseconds using behavioral biometrics, device fingerprints, and graph features. If you've never worked with event streaming (Kafka, Kinesis), feature stores, or real-time inference, this is the domain where those skills pay off most.

Explainability is becoming a legal requirement. The EU AI Act classifies credit scoring and fraud detection as high-risk AI systems, enforceable from August 2026, with penalties up to 7% of global turnover (BusinessStats). Translation: model.predict() isn't enough anymore. You need audit logs, versioned models, human-review hooks, and explainability tooling (SHAP, LIME, or model-native reasoning traces) wired into the pipeline.

Agentic AI is the next interface. The AI-agents-in-financial-services segment is projected to grow from ~$691M to $6.7B (Grand View Research, via BusinessStats). Think LLM-driven agents that categorize spending, negotiate bills, or move idle cash — with tool-calling against banking APIs. If you're experimenting with function calling and agent frameworks today, you're building exactly the muscle this wave needs.

Learn before 2027: real-time ML pipelines, model governance/MLOps, LLM tool-calling patterns, and prompt-injection defenses (an agent with payment permissions is a scary attack surface).

Open Banking: The API Layer of Money

Open banking started as regulation (PSD2 in Europe) and became an industry: from ~$39.9 billion in 2025 toward a projected $288 billion by 2033 (Research Insights).

The core idea is simple and very developer-friendly: banks expose standardized, consent-driven APIs for account data and payments, and third parties build on top.

Concepts worth understanding deeply:

AIS vs PIS. Account Information Services (read access: balances, transactions) vs Payment Initiation Services (write access: move money). Different consent flows, different risk profiles, different regulatory treatment.

Consent as a first-class object. In open banking, user consent has a lifecycle — scoped, time-boxed, revocable. Modeling consent properly (and building the revocation paths) is half the engineering work. If you know OAuth 2.0 well, you're 70% of the way there; add FAPI (Financial-grade API) profiles for the rest.

A2A payments are eating card rails. Account-to-account payments skip card networks entirely — lower fees, instant settlement. A2A is growing at ~13% CAGR toward a market near $850 billion (Grand View Research). Expect product teams to ask you to add "pay by bank" next to the card button.

The scope is widening. PSD3 and the EU's FIDA framework extend data sharing from bank accounts to insurance, investments, and pensions — "open banking" is becoming "open finance." Markets like the UAE, Saudi Arabia, Brazil, and Australia are shipping their own frameworks, so multi-region consent and data-residency handling will matter.

Learn before 2027: OAuth 2.0 + FAPI, webhook reliability patterns (idempotency, retries, signature verification), aggregator APIs (Plaid, TrueLayer, Tink, or your region's equivalent), and ISO 20022 message formats if you go anywhere near payment rails.

Embedded Finance: Every App Grows a Wallet

Embedded finance — financial services living inside non-financial products — is valued around $156 billion in 2026, heading to $454 billion by 2031 (Mordor Intelligence). Bain estimates embedded financial services will exceed $7 trillion in US transaction value by 2026 (Bain & Company).

This is the trend most likely to reach you, wherever you work. The ride-hailing app adds driver banking. The SaaS invoicing tool adds working-capital loans. The marketplace adds instant payouts. Vertical SaaS platforms are embedding accounts and lending directly into ERP systems to move from subscription revenue to transaction revenue (Future Market Insights).

The developer-relevant mechanics:

Banking-as-a-Service (BaaS) is the delivery layer. Providers expose ledgers, card issuing, KYC, and payment rails as APIs. Your job becomes orchestration: onboarding flows, webhooks, reconciliation, and error handling across a partner bank's stack.

Ledgers are harder than they look. Double-entry bookkeeping, idempotent transaction processing, and eventual-consistency handling are the real engineering meat. If you've never built (or broken) a money-movement system, study double-entry ledger design — it's the data structure of the next decade.

Conversion is the business case. Embedding point-of-sale financing directly into checkout can lift conversion 20–30% just by removing redirects (Future Market Insights). When you understand why the product team wants finance embedded, you make better architecture calls.

Learn before 2027: double-entry ledger modeling, idempotency keys everywhere, KYC/AML flow integration, PCI DSS scope reduction (tokenization, hosted fields), and reconciliation jobs that survive partial failures.

The Convergence Is the Career Opportunity

Individually, each trend is significant. Together, they compound: open banking supplies permissioned data, AI turns it into decisions, and embedded finance distributes those decisions inside products people already use. A logistics platform offering instant AI-underwritten working-capital loans on live bank data isn't a concept — it's a 2026 roadmap item at a lot of companies.

Having shipped fintech products across wallets, lending, and banking platforms with the team at Dev Technosys, I can say the hardest problems are rarely the algorithms — they're consent lifecycles, ledger correctness, audit trails, and making compliance a property of the architecture instead of a PDF. Developers who can hold both the ML side and the money-movement side in their head are genuinely rare.

A Realistic 6-Month Learning Path
Month 1–2: OAuth 2.0 → FAPI; build a toy app against a sandbox aggregator API (Plaid/TrueLayer sandboxes are free).
Month 3: Implement a double-entry ledger with idempotent writes. Break it with concurrent requests. Fix it.
Month 4: Add an ML-based anomaly detector on transaction streams; log features and decisions for auditability.
Month 5: Wrap it with an LLM agent that answers "why was this flagged?" using your audit trail — explainability as a product feature.
Month 6: Read the EU AI Act's high-risk requirements and PCI DSS v4 summaries. Map them to what you built. Notice the gaps.

Do that, and by 2027 you won't be learning fintech — you'll be the person others learn it from.

Why Most Healthcare Apps Fail Security Review — A Technical Breakdown

Arpit Mishra — Fri, 17 Jul 2026 07:08:24 +0000

Healthcare apps fail security review far more often than most teams expect, and it's rarely because of one catastrophic flaw. It's usually five or six moderate-severity issues that, together, add up to "not production-ready for PHI." Having sat through (and caused) a fair number of these reviews, here's a breakdown of where they actually go wrong — at the architecture and code level, not the compliance-checklist level.

The gap between "HIPAA compliant" and "actually secure"

HIPAA's Security Rule is deliberately non-prescriptive. It requires "reasonable and appropriate" safeguards across three categories — administrative, physical, and technical — but doesn't hand you a spec sheet. That ambiguity is exactly why so many teams ship something that satisfies a compliance checklist while failing an actual penetration test. A signed Business Associate Agreement and an AES-256 checkbox don't mean the implementation is sound.

The technical safeguards that matter most in practice: access control, audit controls, integrity controls, and transmission security. Almost every failed review traces back to a gap in one of these four.

PHI leaking into places nobody thought to check

This is the single most common finding. Protected health information ends up somewhere it was never supposed to be:

Application logs. A console.log(patientData) left in during debugging, or worse, a logging library configured to serialize entire request/response objects — including headers with auth tokens and bodies with patient names, DOBs, and diagnosis codes — straight into a log aggregator that wasn't scoped for PHI.
Crash reporting tools. Sentry, Crashlytics, and similar tools capture stack traces and local variable state by default. If a crash happens inside a function holding patient data in scope, that data can end up in a third-party crash dashboard that was never covered under a BAA.
Third-party analytics and SDKs. Firebase Analytics, marketing pixels, or even A/B testing tools initialized without care can pick up screen names, form field values, or user identifiers that map back to a patient. The SDK doesn't know it's touching PHI — it just does what analytics SDKs do.
Push notification payloads. A notification that reads "Your test results for [Condition] are ready" is PHI sitting in a push payload that transits Apple's or Google's infrastructure and lands in a device's notification tray, visible on a lock screen.

The fix isn't "be more careful." It's structural: PHI needs to be tagged at the data-model level so it can be excluded from logging middleware, redacted before it reaches crash reporters, and never handed to a third-party SDK that isn't under a BAA — enforced by lint rules or a data-classification layer, not developer discipline.

Local storage and device-side data at rest

Mobile healthcare apps routinely fail on this one. Common patterns that trip reviews:

Unencrypted SQLite or Realm databases storing cached patient records for offline access, with no additional encryption layer beyond the OS's default file protection.
Sensitive data in UserDefaults / SharedPreferences, which are not encrypted by default on either platform and are trivially readable on a jailbroken or rooted device.
Screenshots and app-switcher snapshots. iOS and Android both capture a snapshot of the current screen when an app backgrounds, for the app-switcher UI. A patient chart left visible on screen gets cached as an image on disk unless the app explicitly blanks the screen on applicationDidEnterBackground (iOS) or sets FLAG_SECURE (Android).
Keyboard caches and autocorrect dictionaries learning from free-text fields where patients type symptoms or medication names.

None of these show up in a functional QA pass. They show up when someone pulls the device's file system in a review and greps for patient identifiers.

Broken or oversimplified access control

Authorization bugs are the second-most common category, and they tend to fall into a few recognizable shapes:

IDOR (Insecure Direct Object Reference). An API endpoint like GET /api/patients/{id}/records that checks authentication (is this a valid logged-in user?) but not authorization (is this logged-in user allowed to see this specific patient's records?). This is consistently one of the highest-frequency findings in healthcare API reviews, precisely because patient record IDs are often sequential or easily guessable.
Role checks enforced client-side only. A doctor-only screen hidden in the UI for patient-role users, but the underlying API endpoint has no server-side role check — meaning the "hidden" screen's data is one crafted request away from being fully accessible.
Overly broad OAuth scopes, especially in apps that integrate with FHIR-based EHR systems (Epic, Cerner). Requesting patient/*.read when the app only needs patient/Observation.read is a common shortcut that turns a minor breach into a full record exposure.
Session tokens that don't expire meaningfully. Long-lived JWTs with no server-side revocation path mean a stolen token stays valid long after a user reports a lost device.

Transmission security gaps that aren't "no HTTPS"

Almost nobody ships a healthcare app without TLS anymore — that's not where the failures are. The real gaps are subtler:

Certificate pinning absent or misconfigured, leaving the app vulnerable to MITM interception on compromised networks or via a malicious VPN/proxy profile.
Mixed content in hybrid or WebView-based apps, where a native shell correctly enforces TLS but an embedded WebView loads a resource over plain HTTP.
Third-party SDKs making their own network calls outside the app's primary TLS configuration, bypassing pinning entirely.
API responses over-fetching. An endpoint that returns a full patient object when the screen only needs three fields increases the blast radius of any transmission-layer compromise.

Audit logging that exists but doesn't actually help

HIPAA requires audit controls — but "we have logs" and "we have logs that let you reconstruct who accessed what PHI and when" are very different bars. Common failure: logs capture that an API endpoint was hit, but not which patient record was returned in the response, making it impossible to answer the actual audit question ("who viewed patient X's chart on this date") without cross-referencing multiple systems that were never designed to be joined.

What actually gets a healthcare app through review

The teams that pass consistently share a few habits:

PHI is classified at the schema level, not identified ad hoc by whoever's writing a given feature. A field is either PHI or it isn't, and that flag drives logging exclusion, encryption requirements, and access-control rules automatically.
Authorization is enforced server-side, on every endpoint, by default — not as a special case added when someone remembers.
Third-party SDKs go through a data-flow review before integration, not after a reviewer finds an unexpected outbound network call.
Security review happens before the compliance checklist, not as a substitute for it. A signed BAA with a vendor doesn't secure your architecture; it just allocates liability if the architecture fails.

Security review failures in healthcare apps are rarely about missing a big, obvious control. They're about PHI moving through paths nobody mapped — a log line, a crash report, a cached screenshot, an over-scoped API response. Mapping every place patient data actually flows, not just the places it's supposed to flow, is the difference between an app that passes review and one that needs three more sprints to get there.

Building HIPAA-Compliant Patient Portals: What Developers Need to Know in 2026

Arpit Mishra — Wed, 15 Jul 2026 06:57:33 +0000

Patient portals sit in a strange spot for developers: the feature set looks deceptively simple — login, view records, message a provider, book an appointment — but the compliance and integration surface underneath is one of the more demanding stacks you'll work with in enterprise software. If you're building or evaluating a patient portal in 2026, here's what actually matters technically.

Start with the data model, not the UI

Every patient portal decision should trace back to one question: where does Protected Health Information (PHI) live, and who can touch it? Before wireframing a single screen, map out:

What counts as PHI in your system (names, dates, diagnoses, images, free-text notes — more than people expect)
Where it's stored (your database, the EHR, a third-party lab system)
Who can access which fields, and under what role

This becomes your access control model later, so get it right early. Retrofitting role-based access control (RBAC) into a portal that was built without it is one of the most expensive mistakes teams make.

HIPAA compliance isn't a checkbox, it's an architecture

HIPAA's Security Rule breaks down into three areas that should shape your build from day one:

Administrative safeguards — access management, audit controls, workforce training. As a developer, this mostly means building comprehensive audit logging: every read, write, and export of PHI needs a timestamp, a user ID, and an action type, stored somewhere immutable.

Technical safeguards — encryption at rest and in transit (TLS 1.2+ minimum, AES-256 for stored data), unique user authentication, automatic session timeouts, and audit trail integrity. Multi-factor authentication is no longer optional for anything touching PHI — treat it as baseline, not a nice-to-have.

Physical safeguards — mostly your hosting provider's responsibility, but you still need a signed Business Associate Agreement (BAA) with any cloud vendor, database host, or third-party API you use. If a vendor won't sign a BAA, you can't use them for anything touching PHI, full stop.

A practical tip: run a HIPAA Security Rule risk analysis at the start of the project, not after. It's far cheaper to change your architecture on paper than in production.

EHR integration: HL7 and FHIR

Almost no patient portal exists in isolation — it needs to pull data from and push data to an EHR. Two standards dominate here:

HL7 v2 — the older messaging standard, still widely used by legacy hospital systems for things like admission/discharge/transfer (ADT) messages
FHIR (Fast Healthcare Interoperability Resources) — the modern, REST-based standard that most new integrations should target. SMART on FHIR adds an OAuth2-based authorization layer specifically designed for healthcare apps

If you're integrating with Epic, Cerner, or Meditech, budget real time for this. Each vendor implements FHIR slightly differently, and sandbox environments rarely behave exactly like production. Bi-directional sync (portal writes back to the EHR, not just reads from it) is where most integration bugs surface — test it aggressively.

For terminology mapping, expect to work with LOINC (lab results), RxNorm (medications), SNOMED CT (conditions), and ICD-10 (diagnoses). These aren't optional if you want your data to actually interoperate rather than just display.

Design for the adoption problem, not just the feature list

Here's a number worth sitting with: industry data consistently shows patient portal adoption rates in the 30–50% range. Most technically complete portals still fail on usage because the UX assumes a level of comfort with software that a large share of patients don't have.

A few things that measurably move adoption:

Auto-enrollment during registration instead of an opt-in email
WCAG 2.1 AA accessibility compliance (not just for legal reasons — it broadens who can actually use the product)
Mobile-first design; a large share of patient logins happen on phones
Plain-language copy instead of clinical terminology in patient-facing screens

Usability testing with real patients — not internal QA — catches problems no amount of code review will.

Common technical pitfalls

A few patterns show up repeatedly in patient portal projects that go over budget or timeline:

Underestimating EHR integration time. Teams often scope this like a standard REST API integration. It isn't — expect vendor-specific quirks, certification requirements, and multiple rounds of sandbox testing.
Treating audit logging as an afterthought. Bolting it on later means retrofitting every data access path in the app.
Skipping the BAA review before choosing infrastructure. Picking a cloud service, then discovering it won't sign a BAA, means re-architecting.
Ignoring session and token expiry edge cases. PHI-handling apps need shorter session timeouts than typical consumer apps, and getting the UX of re-authentication right (without constant friction) takes iteration.

Where this is heading

With the 21st Century Cures Act's interoperability rules tightening and proposed 2026 HIPAA Security Rule updates pushing MFA, network segmentation, and encrypted backups from best practice to baseline, patient portal architecture is only going to get more standardized — which is good news for developers. The stack is well-defined enough now that most of what used to be custom compliance work is becoming known patterns: FHIR for integration, RBAC plus audit logging for access control, BAAs for every vendor in the chain.

If you're scoping a patient portal build, start with the data model and the compliance architecture before you touch the UI. Everything else follows from getting those two right.

Twilio vs WebRTC: Choosing Video Infrastructure for a Telehealth App

Arpit Mishra — Tue, 14 Jul 2026 07:28:54 +0000

If you're doing telehealth app development, the video layer is the single highest-stakes architecture decision you'll make. Get it right and consultations "just work" on a patient's shaky 4G connection. Get it wrong and you're debugging dropped calls in production while a doctor waits on a black screen. The choice almost always comes down to two paths: lean on a managed service like Twilio, or build directly on WebRTC. Here's how to reason about it.

The two paths, in one paragraph

WebRTC is the open, browser-native protocol that actually moves the audio and video. It's free, standardized, and already baked into every modern browser and mobile OS. Twilio Video (and peers like it) is a managed platform built on top of WebRTC — it wraps the protocol in SDKs, servers, and infrastructure so you don't have to run any of it yourself. So this isn't really "Twilio or WebRTC." It's "let a vendor operate WebRTC for you" versus "operate it yourself." That framing matters, because the trade-off is about who owns the operational burden.

What WebRTC gives you for free — and what it doesn't

Raw WebRTC handles the hard media problems out of the box: it negotiates codecs, adapts bitrate to network conditions, and — critically for healthcare — encrypts every stream with mandatory DTLS-SRTP. There is no unencrypted mode. That's a genuine head start on compliance.

What WebRTC does not give you is everything around the media:

A signaling server. WebRTC deliberately leaves signaling undefined. You build the exchange of session descriptions and ICE candidates yourself, usually over WebSockets.
NAT traversal. Peers behind firewalls can't connect directly. You need STUN and, for the ~10–20% of connections that fail P2P, TURN relay servers (e.g., self-hosted coturn) that you provision, scale, and pay bandwidth for.
Scale. Pure peer-to-peer WebRTC falls apart past a few participants because each peer sends its stream to every other peer. Anything beyond a 1:1 visit needs an SFU (Selective Forwarding Unit) — a media server like mediasoup, Janus, Jitsi, or LiveKit that routes streams efficiently.

So a minimal 1:1 doctor–patient call is very achievable on plain WebRTC. A group visit, a clinician-plus-interpreter session, or a "provider drops in on a triage nurse" flow means you're now running media servers. That's real infrastructure.

A stripped-down signaling handshake looks deceptively simple:

jsconst pc = new RTCPeerConnection({ iceServers });
stream.getTracks().forEach(t => pc.addTrack(t, stream));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
socket.send(JSON.stringify({ type: "offer", sdp: offer }));

The 20 lines above are the easy part. The pager-at-3am part is TURN capacity, reconnection logic, and packet-loss handling on real mobile networks.

What Twilio abstracts away

Twilio Video collapses that entire list into a managed service: global signaling, TURN relays, an SFU for group rooms, recording, and native SDKs for web, iOS, and Android. You write application logic; Twilio runs the media plane. For a small team, that can compress months of infrastructure work into days, which is often the deciding factor early in telehealth app development when you're racing to a compliant MVP.

There's a catch worth knowing before you commit. In late 2023 Twilio announced it would sunset Programmable Video, then extended the deadline, and in October 2024 reversed course entirely — publicly committing to keep Video as a standalone product and invest in it. As of Twilio's latest official word, it's here to stay. But that whiplash is itself a data point: when you're building a regulated product with a multi-year lifespan, vendor commitment and migration risk are legitimate evaluation criteria, not paranoia. Design your media layer so the provider sits behind an abstraction you control, and swapping it later is an inconvenience rather than a rewrite.

The healthcare layer both paths must satisfy

Encryption in transit is necessary but nowhere near sufficient for HIPAA. Whichever path you pick, you're responsible for:

A signed BAA. Any vendor that touches Protected Health Information must sign a Business Associate Agreement. Twilio signs BAAs; so do Amazon Chime SDK, Daily, and Zoom Video SDK. If you self-host WebRTC and the media never leaves infrastructure you control, the BAA surface shrinks — but your TURN provider and any cloud host still count.
Clean signaling. Never log PHI (patient names, appointment reasons) in signaling metadata or ICE traces.
Access controls and audit trails. Time-boxed room tokens, identity verification on both ends, and tamper-evident logs of who joined which consultation and when.
Data residency and retention for any recordings, which become part of the medical record.

Neither Twilio nor WebRTC makes you compliant. They just change where the compliance work lives.

The middle ground most teams actually pick

The real market isn't binary. Between "all Twilio" and "raw WebRTC from scratch" sit options that are often the sweet spot for telehealth:

Open-source SFUs — LiveKit, mediasoup, or Janus give you WebRTC scale without writing a media server from zero. LiveKit in particular offers both self-host and a managed cloud, so you can start managed and repatriate later.
Other BAA-signing managed providers — Amazon Chime SDK, Daily, and Zoom Video SDK are all HIPAA-eligible and reduce Twilio-specific lock-in.

For most funded consumer telehealth apps, a managed provider behind a thin internal abstraction is the pragmatic start. For platforms with heavy volume, tight margins, or strict data-control requirements, a self-hosted SFU pays off as you scale.

The cost curve nobody warns you about

Pricing is where the two paths diverge hardest over time. Managed providers bill per participant-minute, which is wonderful at low volume and brutal at scale — a platform doing thousands of concurrent visits can watch its video bill outrun its entire cloud spend. Self-hosted WebRTC flips the shape: high fixed cost up front (media servers, TURN bandwidth, on-call engineering) but a marginal cost per call that trends toward negligible. The crossover point is real and worth modeling early. Many teams launch on a managed service to hit the market fast, then migrate the media plane to a self-hosted SFU once volume makes the per-minute math painful — which is exactly why that thin abstraction layer around your provider isn't optional.

A decision framework

Reach for a managed service when speed to a compliant launch matters more than per-minute cost, your team is small, and you'd rather buy reliability than build it. Reach for self-hosted WebRTC (with an SFU) when you have media-engineering talent, need full control over data residency, or your usage is high enough that per-minute pricing dwarfs the cost of running your own infrastructure. And regardless of which you choose, wrap the provider in your own interface from day one — the teams that regret their video stack are the ones who let a vendor's SDK leak into every component.

Bottom line

Twilio versus WebRTC is really a build-versus-operate decision dressed up as a technology comparison. WebRTC is the engine either way; the question is whether you want to run the garage. Start by mapping your constraints — team skills, compliance surface, scale, and budget — then let those pick the path. In telehealth app development, the video layer you can change your mind about later is worth more than the one that looks cheapest on day one.

How do you catch ledger drift in a payments/lending system before it becomes unrecoverable?

Arpit Mishra — Fri, 10 Jul 2026 05:33:38 +0000

Why Mobile App Maintenance Costs More Than You Budgeted A Technical Post-Mortem

Arpit Mishra — Thu, 09 Jul 2026 06:33:52 +0000

Every estimate I have ever seen for mobile app maintenance is wrong in the same direction, and for the same reason.
The estimate is built as a support retainer. Bug fixes, some analytics, a designer on call. Fifteen percent of the original build cost, annually, because that is the number everyone repeats.
The actual invoice is generated by something else entirely: a stack of externally-imposed deadlines that you do not control, cannot negotiate, and did not put in your Gantt chart. Google sets them. Apple sets them. Your SDK vendors set them. Your certificate authority sets them. None of them care about your roadmap.
This is a post-mortem on where the money actually goes.

The annual platform tax
Google Play's target API level policy is not a suggestion. As of August 31, 2025, new apps and app updates must target Android 15 (API level 35) or higher to be submitted at all. Existing apps must target at least API 34 to remain available to new users on devices running a newer OS than the app targets. Fall below that and your app quietly stops appearing for new installs on modern devices — no removal email, just a gradual disappearance from the funnel.
Apple runs the same cadence with less ceremony. Submissions must be built with a recent Xcode and SDK; the minimum floor moves annually, and privacy manifest requirements for third-party SDKs have been enforced since 2024.
Here is what makes this expensive: bumping targetSdkVersion is a one-line change, and the one-line change is never the work.
gradle
android {
compileSdk = 35
defaultConfig {
targetSdk = 35 // <- 15 seconds
}
}
Targeting API 35 activates Android 15 behaviour changes for your process. Edge-to-edge display is enforced by default, so every screen with a hardcoded status bar assumption now has content sliding under the system bars. Predictive back requires OnBackInvokedCallback migration. Non-SDK interface restrictions tighten, so that reflection hack from 2021 throws at runtime instead of at compile time.
The 15-second change generates two to six engineer-weeks of regression work. Nobody budgets the six weeks.
The 16 KB page size problem
If you ship native code — and if you use almost any media, ML, database or crypto library, you do — Android's move to 16 KB memory page sizes requires recompiling every .so in your APK against a compatible NDK.
bash

Find out whether you have a problem

unzip -o app-release.apk -d /tmp/apk
find /tmp/apk/lib -name ".so" | while read f; do
echo "$f: $(objdump -p "$f" | grep -m1 LOAD | awk '{print $NF}')"
done
If a .so shows 2*12 alignment, it needs rebuilding. If that .so came from a third-party AAR whose vendor has stopped shipping updates, you are not rebuilding anything. You are replacing the dependency, and the replacement has a different API surface.
That is not maintenance. That is a small feature project wearing maintenance's coat.
Dependency drift is compound interest
A typical React Native or Flutter app carries several hundred transitive dependencies. Each one has a maintainer who may or may not still care.
Run this on any app older than eighteen months:
bash
npm outdated --long
npm audit --audit-level=high
Then run it again with the honest question: how many of these have a breaking major version between me and the fix?
Deferring dependency upgrades feels free because nothing breaks today. It is not free. It is a loan, and the interest compounds. Upgrading a library across one major version is a contained task. Upgrading it across four, while three other libraries in the graph also need upgrading and two of them have peer-dependency conflicts with each other, is a multi-week untangling exercise with a nontrivial chance of a rewrite.
The team that spends four hours a month on dependency hygiene pays roughly 48 hours a year. The team that defers pays a 200-hour migration in year three, plus the opportunity cost of the feature that was not shipped while three engineers untangled the graph.
The most expensive line in any mobile app maintenance budget is the one that reads "we'll deal with it next quarter."
Third-party SDK end-of-life
You do not control the lifecycle of your analytics SDK, your payment SDK, your push provider, your crash reporter, or your auth library.
When a payment SDK announces it will not support API 35, you have three options: wait for the vendor, fork and patch, or migrate to a competitor. All three cost money. The third costs the most, and it is frequently the only real option, because the deadline is Google's and the vendor's timeline is the vendor's.
I have watched a fintech client discover, six weeks before a Play Store deadline, that their KYC SDK's Android 15 support was "on the roadmap." The migration to a replacement provider consumed a full quarter, and none of it appeared on any product roadmap. It was, on the ledger, maintenance.
Audit your SDKs annually against a simple question: if this vendor disappeared tomorrow, what is my exit cost? Any dependency where the answer exceeds four weeks is a strategic risk, not a technical one.
The invisible operational baseline
These items never appear in maintenance quotes and always appear in maintenance costs.
Certificate and provisioning expiry. Apple distribution certificates expire. Push notification certificates expire. Someone has to notice before your users do, and the person who set them up has usually left.
Backend scaling under changing client behaviour. An OS update changes background execution rules. Suddenly your sync logic fires differently, your API traffic pattern shifts, and your cloud bill moves without a single line of app code changing.
CI/CD maintenance. Build agents drift. Xcode versions on hosted runners get deprecated. Your pipeline that worked in March fails in September because GitHub retired the macOS 13 image.
Crash-rate regression. A crash-free session rate that slips from 99.7% to 99.1% is invisible on a dashboard and catastrophic in reviews. Investigating a 0.6% regression across device fragmentation is genuinely difficult engineering work.
Store policy changes. Data safety declarations, permission justifications, account deletion requirements. Each one is a form, a code change, and a resubmission.

What the number actually looks like
The 15–20% rule is not wrong. It is just misattributed. People hear it and imagine a support desk. It is really:
Cost driver Share of annual maintenance
Platform/OS compliance (target SDK, behaviour changes, NDK) 25–35%
Dependency and SDK upgrades 20–30%
Bug fixes and crash regression 15–20%
Backend, infrastructure and CI 10–20%
Store policy and compliance overhead 5–10%
Note what is missing: new features. Those are not maintenance, and the moment they get billed as maintenance, your maintenance budget becomes a fiction and your feature roadmap becomes a lie.
The one practice that changes the number
Treat platform deadlines as scheduled work, not incidents.
Every year, Google announces the target API deadline months ahead. Every year, Apple announces the SDK floor at WWDC. Every year, teams find out in August.
Put both on the engineering calendar in January. Allocate the sprint. Run the target SDK bump on a branch in February, on the beta SDK, and find the breakage while the deadline is seven months away and the fix is cheap. Audit your native libraries for page alignment before the vendor deadline, not after Play Console flags you.
Maintenance is expensive because it is treated as an interruption. It is not an interruption. It is the recurring, forecastable cost of operating on someone else's platform. The only genuinely optional part is whether you pay for it on your schedule or on Google's.

Build a Wallet Backend with Node.js, PostgreSQL, and Kafka

Arpit Mishra — Wed, 08 Jul 2026 06:17:06 +0000

Most "build a wallet" tutorials stop at a balance column and an UPDATE statement. Then someone hits it with two concurrent requests, or a network retry, and money quietly appears or disappears. A wallet backend has exactly one job it can't get wrong: never lose or duplicate money. This post builds a small but correct wallet core — a double-entry ledger in PostgreSQL, atomic transfers in Node.js, and Kafka events so the rest of your system can react.

The design in one paragraph

PostgreSQL is the source of truth. Every transfer moves money inside a single database transaction using a double-entry ledger (every debit has a matching credit), row locks stop race conditions, and an idempotency key stops retries from charging twice. Once the transaction commits, we publish an event to Kafka so downstream services — notifications, analytics, fraud — can react without slowing the transfer down.

The schema

Money is stored as integer minor units (cents/paise), never floats. ledger_entries is the immutable audit trail; accounts.balance is a cached convenience you can always rebuild from it.

sqlCREATE TABLE accounts (
id BIGSERIAL PRIMARY KEY,
owner_id UUID NOT NULL,
currency CHAR(3) NOT NULL DEFAULT 'USD',
balance BIGINT NOT NULL DEFAULT 0, -- minor units
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE transfers (
id BIGSERIAL PRIMARY KEY,
idempotency_key TEXT UNIQUE NOT NULL,
from_account_id BIGINT NOT NULL REFERENCES accounts(id),
to_account_id BIGINT NOT NULL REFERENCES accounts(id),
amount BIGINT NOT NULL CHECK (amount > 0),
status TEXT NOT NULL DEFAULT 'pending',
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE ledger_entries (
id BIGSERIAL PRIMARY KEY,
transfer_id BIGINT NOT NULL REFERENCES transfers(id),
account_id BIGINT NOT NULL REFERENCES accounts(id),
direction TEXT NOT NULL CHECK (direction IN ('debit','credit')),
amount BIGINT NOT NULL CHECK (amount > 0),
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

The transfer — the part that has to be bulletproof

This is the whole ballgame. One DB transaction, in this order: claim the idempotency key, lock both accounts, check funds, move money, write the ledger, commit.

jsconst { Pool } = require('pg');
const pool = new Pool();

async function transfer({ idempotencyKey, fromId, toId, amount }) {
const client = await pool.connect();
try {
await client.query('BEGIN');

// 1. Claim this transfer exactly once
const ins = await client.query(
  `INSERT INTO transfers (idempotency_key, from_account_id, to_account_id, amount)
   VALUES ($1,$2,$3,$4)
   ON CONFLICT (idempotency_key) DO NOTHING
   RETURNING id`,
  [idempotencyKey, fromId, toId, amount]
);

// Duplicate request — return the original result, don't re-charge
if (ins.rowCount === 0) {
  await client.query('COMMIT');
  const prev = await client.query(
    `SELECT id, status FROM transfers WHERE idempotency_key = $1`,
    [idempotencyKey]
  );
  return { transferId: prev.rows[0].id, status: prev.rows[0].status, duplicate: true };
}
const transferId = ins.rows[0].id;

// 2. Lock both rows in a stable order to avoid deadlocks
const ids = [fromId, toId].sort((a, b) => a - b);
const rows = await client.query(
  `SELECT id, balance FROM accounts WHERE id = ANY($1) FOR UPDATE`, [ids]
);
const bal = Object.fromEntries(rows.rows.map(r => [r.id, BigInt(r.balance)]));

// 3. Check funds
if (bal[fromId] < BigInt(amount)) {
  const err = new Error('INSUFFICIENT_FUNDS');
  err.code = 'INSUFFICIENT_FUNDS';
  throw err;
}

// 4. Move the money
await client.query(`UPDATE accounts SET balance = balance - $1 WHERE id = $2`, [amount, fromId]);
await client.query(`UPDATE accounts SET balance = balance + $1 WHERE id = $2`, [amount, toId]);

// 5. Immutable double-entry records
await client.query(
  `INSERT INTO ledger_entries (transfer_id, account_id, direction, amount)
   VALUES ($1,$2,'debit',$3), ($1,$4,'credit',$3)`,
  [transferId, fromId, amount, toId]
);

// 6. Finalize
await client.query(`UPDATE transfers SET status = 'completed' WHERE id = $1`, [transferId]);
await client.query('COMMIT');
return { transferId, status: 'completed', duplicate: false };

} catch (err) {
await client.query('ROLLBACK');
throw err;
} finally {
client.release();
}
}

SELECT ... FOR UPDATE is what makes concurrent transfers safe — the second request blocks until the first commits, so you can never race two withdrawals past a balance check. Sorting the IDs before locking prevents two transfers in opposite directions from deadlocking on each other.

Publish the event after commit

Only once the money has actually landed do we tell the world. Note the event is emitted after the transaction commits — never before, or you risk announcing a transfer that then rolls back.

jsconst { Kafka } = require('kafkajs');
const kafka = new Kafka({ clientId: 'wallet', brokers: ['localhost:9092'] });
const producer = kafka.producer();
await producer.connect();

async function emitTransferCompleted(evt) {
await producer.send({
topic: 'wallet.transfers',
messages: [{ key: String(evt.transferId), value: JSON.stringify(evt) }],
});
}

Wire it to an Express route:

jsapp.post('/transfers', async (req, res) => {
const idempotencyKey = req.header('Idempotency-Key');
const { fromId, toId, amount } = req.body;
try {
const result = await transfer({ idempotencyKey, fromId, toId, amount });
if (!result.duplicate) {
await emitTransferCompleted({ ...result, fromId, toId, amount });
}
res.status(result.duplicate ? 200 : 201).json(result);
} catch (e) {
if (e.code === 'INSUFFICIENT_FUNDS') return res.status(422).json({ error: 'insufficient_funds' });
res.status(500).json({ error: 'internal_error' });
}
});

A consumer that reacts

Downstream services subscribe independently. Here's a notification worker — analytics or fraud scoring would look nearly identical:

jsconst consumer = kafka.consumer({ groupId: 'notifications' });
await consumer.connect();
await consumer.subscribe({ topic: 'wallet.transfers' });
await consumer.run({
eachMessage: async ({ message }) => {
const evt = JSON.parse(message.value.toString());
console.log(Notify: transfer ${evt.transferId} for ${evt.amount} completed);
// send push, update a read model, etc.
},
});

Gotchas that bite in production

Emitting after commit can still drop events. If the process dies between COMMIT and producer.send, the transfer happened but nobody heard. The robust fix is the transactional outbox: write the event to an outbox table inside the same DB transaction, then a separate relay publishes it to Kafka and marks it sent. Now the event is as durable as the transfer itself.
Never use floats for money. Integer minor units or NUMERIC — a 0.1 + 0.2 rounding bug in a ledger is a very bad day.
The ledger is the truth, the balance is a cache. You should be able to run SELECT SUM(credits) - SUM(debits) per account and match accounts.balance exactly. Reconcile it on a schedule.
Idempotency keys are non-negotiable. Clients retry on timeouts; without the unique key you'll double-spend.
Consumers must be idempotent too. Kafka is at-least-once, so the same event can arrive twice — dedupe on transferId.

Wrapping up

That's a wallet core that stays correct under concurrency and retries, with an event stream your whole platform can build on. From here you'd add authentication, KYC, holds/authorizations, multi-currency, and the outbox relay — but the ledger-plus-events foundation stays the same. Get this part right and everything above it gets a lot easier.

Building a Secure E-Wallet App in 2026: Architecture, PCI DSS & KYC Explained

Arpit Mishra — Tue, 07 Jul 2026 06:09:11 +0000

Most e-wallet demos look identical: a balance, a "send money" button, a transaction list. What separates a wallet that survives a PCI DSS audit and a Series A due-diligence review from one that gets rebuilt six months post-launch is almost never visible in the UI. It's the architecture underneath — the ledger design, the KYC state machine, the tokenization boundary, the idempotency guarantees on every money-moving endpoint.

This is a practitioner-level walkthrough of the four architectural decisions that matter most in e-wallet app development: the service architecture, the ledger, the compliance boundary, and the reliability guarantees that keep a wallet's numbers trustworthy under concurrent load.

The core service architecture

A production e-wallet, even a modest one, tends to converge on the same handful of services regardless of stack:

Identity & Auth — authentication, session management, device binding
KYC/Onboarding — identity verification workflow and risk tiering
Ledger — the source of truth for every balance and movement
Payments/Rails — integration with card networks, BaaS providers, or bank rails
Risk & Fraud — real-time transaction scoring
Notifications — transactional messaging, webhooks to merchants

The temptation early on is to build this as a monolith — and for an MVP, that's often the right call. But the ledger service in particular benefits from being isolated early, even inside a monolith, because it's the one component where a schema mistake is expensive to unwind once real money and real audit trails depend on it. Treat the ledger as a bounded context from day one, even if you don't split it into a separate deployable service yet.

The ledger: the actual heart of e-wallet app development

The single most common mistake in early-stage e-wallet app development is storing a "balance" as a mutable integer on a user row. It works in a demo. It falls apart the moment you need to explain to an auditor, or to yourself at 2am during an incident, exactly why a balance is what it is.

The fix is a double-entry ledger, borrowed directly from accounting practice: every transaction creates at least two immutable entries — a debit and a credit — that must always net to zero across the system. Balances are never stored directly; they're derived by summing entries.

typescript// Simplified double-entry ledger schema
interface LedgerEntry {
id: string;
transactionId: string; // groups debit + credit together
accountId: string; // wallet, fee account, merchant account, etc.
direction: 'debit' | 'credit';
amountMinorUnits: number; // always store money as integer cents, never float
currency: string;
createdAt: Date;
}

// A transfer between two wallets always produces a balanced pair
function recordTransfer(fromWallet: string, toWallet: string, amount: number, txnId: string) {
return [
{ id: uuid(), transactionId: txnId, accountId: fromWallet, direction: 'debit', amountMinorUnits: amount },
{ id: uuid(), transactionId: txnId, accountId: toWallet, direction: 'credit', amountMinorUnits: amount },
];
}

// Balance is a query, never a stored field
function getBalance(accountId: string): number {
const credits = sumEntries(accountId, 'credit');
const debits = sumEntries(accountId, 'debit');
return credits - debits;
}

This does two things that matter for a real wallet. First, it makes reconciliation mechanical: if every transaction is balanced and every entry is immutable, "where did the money go" is always answerable by querying entries, never by trusting a cached number. Second, it gives you a natural audit trail for free — which is exactly what PCI DSS and most banking-partner due diligence processes will ask to see.

One consistency detail trips up teams that are otherwise doing this correctly: the debit-and-credit pair for a single transaction must be written atomically, inside a single database transaction, or you risk a partial write leaving the ledger unbalanced during a crash or network blip. Most teams enforce this with a database-level transaction wrapping both entry inserts, plus a periodic reconciliation job that sums all entries system-wide and alerts if the total doesn't net to zero — a cheap, high-value safety net that catches bugs before an auditor or a user does.

PCI DSS: reducing scope before you build

Most first-time fintech teams treat PCI DSS as a checklist to satisfy after the app is built. The more effective approach is architectural: design the system so that as little of it as possible is ever "in scope" for PCI DSS to begin with.

The core technique is tokenization. Raw card data (the PAN — primary account number) should never touch your application servers or database. Instead, card capture happens directly between the user's device and your payment processor or BaaS provider (Stripe, Marqeta, Galileo, and similar all support this), which returns an opaque token your system stores and uses for all future transactions.

typescript// What your servers should NEVER see
interface RawCardData {
pan: string; // full card number — never touches your backend
cvv: string; // never stored, ever, by anyone
expiry: string;
}

// What your servers actually store and operate on
interface TokenizedPaymentMethod {
userId: string;
processorToken: string; // opaque reference from Stripe/Marqeta/etc.
last4: string; // safe to store for display purposes
cardBrand: string;
}

// Every charge references the token, never raw card data
async function chargeWallet(userId: string, amountMinorUnits: number) {
const method = await getTokenizedMethod(userId);
return processor.charge({ token: method.processorToken, amount: amountMinorUnits });
}

Done correctly, this reduces your PCI DSS assessment from a full Level 1 audit down to a much narrower SAQ (Self-Assessment Questionnaire) scope — typically SAQ A or SAQ A-EP for a properly tokenized, redirect-based card capture flow — because your infrastructure never stores, processes, or transmits raw cardholder data; the processor's PCI-certified infrastructure does. This single architectural decision, made before writing a line of production code, is usually the highest-leverage compliance decision in the entire project. Teams that skip it and store card data "just for the MVP" almost always regret it, since migrating off raw card storage later means re-architecting the payment flow while simultaneously serving live users.

KYC: model it as a state machine, not a boolean

A second common mistake: modeling KYC status as verified: boolean. Real KYC has more states than that, and treating it as binary makes tiered access, re-verification, and regulatory reporting far harder to implement correctly later.

interface KYCTransition {
from: KYCState;
to: KYCState;
trigger: string;
timestamp: Date;
}

// Transaction limits gate off the KYC tier, not a single boolean
function getTransactionLimit(state: KYCState): number {
switch (state) {
case 'basic_verified': return 100_00; // $100 in minor units
case 'enhanced_verified': return 10_000_00; // $10,000 in minor units
default: return 0;
}
}

Modeling KYC explicitly as a state machine, with logged transitions, gives you two things a boolean never can: a defensible audit trail for regulators asking "when and why was this user allowed to transact at this limit," and a clean hook for tiered onboarding — letting users start with basic verification and low limits, then upgrade to enhanced verification as they need higher transaction ceilings, without re-architecting anything.

Idempotency and webhook ordering: the reliability layer

The last piece that separates production-grade e-wallet app development from a fragile prototype is handling the fact that networks retry, clients double-tap buttons, and webhooks arrive out of order.

Every endpoint that moves money needs an idempotency key, supplied by the client, that guarantees a retried request doesn't create a duplicate transaction:

typescriptasync function transferFunds(request: TransferRequest, idempotencyKey: string) {
const existing = await findByIdempotencyKey(idempotencyKey);
if (existing) return existing; // safe to retry — returns the original result

const result = await executeTransfer(request);
await storeIdempotencyRecord(idempotencyKey, result);
return result;
}

Webhooks from BaaS or payment providers need the same discipline, plus explicit handling for out-of-order delivery — a "payment failed" event arriving after a "payment succeeded" event for the same transaction ID should never simply overwrite state; it should be reconciled against the ledger's current entries, with the ledger as the tie-breaking source of truth. A practical pattern here is to store every webhook payload with its provider-supplied event ID before processing it, check that ID against previously seen events, and process events in a queue keyed by transaction ID so that two events for the same transaction can never be handled concurrently by different workers.

Closing thought

None of this is exotic engineering — a double-entry ledger, tokenized card handling, a KYC state machine, and idempotent endpoints are well-understood patterns individually. What makes e-wallet app development hard is that all four have to be right simultaneously, from the first sprint, because retrofitting any of them after real transaction volume and real audit scrutiny arrive is dramatically more expensive than building them in from the start. Teams that have shipped this before — including fintech-focused shops like Dev Technosys — tend to treat these four decisions as the actual scope of the project, with the UI as the easy part that comes after.

What I Learned Shipping Fintech Apps: KYC, PCI DSS, and the Stuff Tutorials Don't Teach You

Arpit Mishra — Mon, 06 Jul 2026 06:30:42 +0000

Every fintech app development tutorial on the internet teaches you the same thing: connect Stripe, build a wallet screen, show a transaction list. Ship it.

Then you work on a real fintech product — one that regulators can audit and real users trust with real money — and you discover that the tutorial covered maybe 15% of the actual work. The other 85% is the stuff nobody writes about because it's unglamorous, compliance-heavy, and learned through painful production incidents.

After several years working on fintech app development projects — wallets, lending platforms, payment systems — here's the stuff I wish someone had told me on day one.

KYC is a workflow, not an API call

Tutorials treat KYC like this:

javascriptconst result = await kycProvider.verify(userDocument);
if (result.verified) activateAccount(user);

Reality: KYC is a state machine with a dozen states, and your architecture needs to treat it that way.

A real verification flow looks more like: PENDING → DOCUMENTS_SUBMITTED → AUTO_REVIEW → MANUAL_REVIEW → APPROVED / REJECTED / RESUBMISSION_REQUIRED — and users will exist in every one of these states simultaneously across your user base. Each state changes what the user can do: maybe they can browse in PENDING, deposit small amounts in AUTO_REVIEW, but can't withdraw until APPROVED.

Things that will bite you if you don't plan for them:

Providers time out and fail. Onfido, Jumio, Sumsub — they all have outages and slow days. Your onboarding can't hard-block on a synchronous verification call. Build it webhook-driven, with the user parked in an intermediate state.
Manual review is unavoidable. Some percentage of users will always fall into manual review (blurry documents, name mismatches, sanctions list near-matches). You need an internal admin tool for compliance officers on day one — not "later."
Re-verification exists. KYC isn't one-and-done. Regulators expect periodic re-verification and event-triggered checks (address change, unusual activity). Your data model needs verification records, plural, per user — not a boolean is_verified column. I've seen that boolean column in production. It did not end well.
Tiered KYC is a product decision with legal consequences. Many markets allow limited functionality with light verification (phone + ID number) and full functionality after document verification. Your limits engine and your KYC states have to be designed together.

The lesson: model KYC as an event-driven state machine from the start. Retrofitting it into an app built around if (user.verified) is a multi-month rewrite.

PCI DSS: the goal is to never touch card data

The single most important PCI DSS lesson: compliance scope is determined by where card data flows, and your job is to make sure it never flows through you.

If raw PANs (card numbers) touch your servers — even in memory, even in logs — you're in for the full PCI DSS assessment: quarterly scans, network segmentation, key management ceremonies, the works. That's a six-figure ongoing burden.

The sane architecture:

User's browser/app → (card data) → Payment provider's hosted fields/SDK
↓
Your backend ← (opaque token) ← Provider tokenizes the card

Your backend only ever stores and transmits tokens. Stripe Elements, Braintree Hosted Fields, Adyen components — they all exist precisely so card data goes straight from the user's device to the provider, bypassing your infrastructure entirely. This drops you into SAQ-A territory, the lightest compliance tier.

The mistakes I've actually seen in code reviews:

Logging request bodies globally. A generic request logger that captures everything — including the one endpoint where a card number passes through. Congratulations, you now have PANs in your log aggregator, and your log aggregator is now in PCI scope.
"Temporary" card storage. Someone stores card details "just for the retry flow." There is no temporary in compliance.
Card data in error reports. Your crash reporting tool captures local variables. One of those variables was a payment payload. Sentry is now in scope.

Practical rule we enforce in every fintech app development project: add a serialization deny-list for fields like pan, cvv, card_number at the logging middleware level, so even a careless log statement can't leak them.

Your transaction table is not a ledger

Tutorial code:

sqlUPDATE wallets SET balance = balance - 100 WHERE user_id = 42;

If you take one thing from this post: never store balance as a mutable number. A real fintech backend uses double-entry ledger design — every movement of money is an immutable pair of entries (debit one account, credit another), and balance is the derived sum of entries.

Why this matters beyond accounting purity:

Auditability. When a user disputes a balance ("I had ₹5,000 yesterday!"), you can replay every entry. With a mutable balance column, you're archaeology-deep in application logs praying you logged enough.
Reconciliation. Every fintech product eventually reconciles against external systems (bank statements, processor reports). Reconciliation against an append-only ledger is a diff. Reconciliation against mutated balances is a nightmare.
Concurrency. Two simultaneous withdrawals against a mutable balance is the classic race condition that creates negative balances. Append-only entries with database-level constraints handle this far more safely.

And the companion lesson: idempotency keys on every money-moving endpoint. Mobile networks retry. Users double-tap. Webhooks re-deliver. Without idempotency keys, every retry is a potential double-charge:

javascriptPOST /transfers
Idempotency-Key: 7f9c2e-...

// Server: if this key was seen before, return the original
// response — do NOT execute the transfer again.

Payment providers (Stripe et al.) support this natively. Your internal APIs need it too.

Webhooks will lie to you (about ordering)

Fintech backends are webhook-driven: payment succeeded, KYC completed, transfer settled. Two things tutorials never mention:

Webhooks arrive out of order. You will receive payment.settled before payment.created. Your handlers must be order-independent — treat each webhook as "here's the current state of object X, go fetch the full object and reconcile," not as a sequential event stream.
Webhooks arrive more than once. Same event, delivered three times. Every handler must be idempotent (notice a theme?).

And verify webhook signatures. Always. An unverified webhook endpoint is an open invitation to mark arbitrary payments as "completed."

Compliance shapes architecture — involve it early

The biggest non-technical lesson: in fintech app development, compliance is not a checklist you run before launch. It's an architectural stakeholder.

Data residency requirements decide your cloud regions. AML rules decide your transaction monitoring pipeline. Audit requirements decide your logging retention (and its immutability). Regulator reporting decides your data warehouse schema. Discovering any of these after the architecture is set means expensive rework.

On the projects that went smoothly, compliance requirements were in the BRD before the first sprint. On the ones that didn't... well, that's how I learned everything in this post. This is honestly the strongest argument for working with teams that have shipped regulated products before — at Dev Technosys, where I've collaborated on several fintech builds, discovery phases now start with a compliance mapping session before any tech stack discussion, because retrofitting compliance is always more expensive than designing for it.

The honest summary

Fintech app development is 15% features and 85% correctness: state machines instead of booleans, ledgers instead of balance columns, tokens instead of card data, idempotency everywhere, and compliance in the room from day one.

None of this is glamorous. All of it is what separates apps that survive their first audit — and their first traffic spike, and their first dispute — from apps that make the news for the wrong reasons.

What did your first fintech project teach you the hard way? Drop it in the comments — I'm collecting scars.

How to Choose the Right Partner for Insurance App Development in 2026

Arpit Mishra — Fri, 03 Jul 2026 06:41:40 +0000

Insurance is having its digital moment, later than banking, later than retail, but arriving with more force. The global insurtech market is on track to cross the $30-50 billion mark in 2026 depending on how narrowly you define the category, and forecasts consistently put annual growth in the 25-40% range through the early 2030s. Health insurance alone is expected to account for over a third of insurtech application demand this year, and AI-driven underwriting, automated claims, and embedded insurance are no longer experimental features — they're what customers expect by default.

For insurers, MGAs, and insurtech founders, this creates a real decision point: build the technology in-house, or bring in outside expertise to move faster. Distribution is shifting too — embedded insurance platforms are growing at a faster clip than traditional agent and broker channels, and Asia-Pacific is on pace to post the fastest regional growth of any market through the early 2030s, driven largely by mobile-first adoption and simplified onboarding. None of that growth translates into revenue on its own; it only matters if the underlying product actually works for the person filing a claim. This piece is about what actually matters when evaluating the build decision, and what a serious insurance app looks like from the ground up.

Why Insurance Apps Are Harder Than They Look

On the surface, an insurance app looks like any other consumer fintech product: onboarding, a dashboard, a payment flow, some documents. Underneath, it's one of the more demanding categories to build well, for three reasons.

First, the data model is genuinely complex. A single policy touches underwriting rules, rating tables, coverage riders, claims history, and regulatory disclosures that vary by state, country, and product line. Get this wrong and you're not shipping a buggy feature — you're miscalculating premiums or mishandling a claim, both of which carry real financial and legal consequences.

Second, the user journeys are longer and more emotionally loaded than typical apps. Nobody opens an insurance app for fun. They open it because something went wrong — a car accident, a medical event, a flooded basement — and the app is being judged in the worst moment of the customer's week. A clunky claims flow at that moment does lasting brand damage in a way a clunky shopping cart never will.

Third, the regulatory surface is enormous and fragmented. Unlike banking, insurance doesn't have a global standard equivalent to Basel; capital, solvency, and disclosure rules differ by jurisdiction, and cross-border insurtechs often have to customize policy wording, complaint handling, and data residency market by market. This regulatory drag is real, and it's one of the main reasons in-house teams without prior insurance-domain experience underestimate build timelines by months.

What "Good" Actually Looks Like: Core Feature Set

Whether you're building a direct-to-consumer app, a broker platform, or an embedded insurance layer inside someone else's product, a handful of capabilities separate a genuinely useful app from a digitized brochure.

AI-assisted underwriting and dynamic pricing. Static rating tables are being replaced by models that price risk using real-time and behavioral data — telematics for auto, wearables for health, IoT sensors for home and property. This isn't a nice-to-have anymore; over 80% of insurance companies now report using AI or ML somewhere in claims and risk evaluation, and customers increasingly expect pricing that reflects their actual behavior, not just demographic averages.

Automated, high-transparency claims processing. Computer vision applied to claims documentation has been shown to cut claims cycle times by as much as half in certain property and casualty lines. Customers don't need claims resolved instantly, but they do need visibility — a real-time status, not a black box they call a hotline to check.

Embedded and on-demand insurance. Increasingly, insurance is being sold at the point of need rather than as a standalone annual purchase — travel coverage bundled at checkout, device protection offered at the point of sale, usage-based auto coverage that activates per trip. Building for embedded distribution means your architecture needs clean, well-documented APIs from day one, not as a bolt-on integration layer added later.

Self-service policy management. Renewals, coverage changes, beneficiary updates, and document retrieval should not require a phone call. Mobile self-service adoption is rising past 60% in key markets, and every friction point in this flow is a retention risk at renewal time.

Fraud detection built into the pipeline, not added after a loss event. Claims fraud is one of the largest cost centers in the industry, and the insurers seeing real ROI from AI investment are the ones that built anomaly detection into claims intake from the start, rather than retrofitting it after fraud losses forced the issue.

The Build-vs-Partner Decision

The most consequential decision in any insurance app project isn't the tech stack, it's whether you build the core platform in-house or work with a specialized development partner.

In-house builds make sense when insurance technology is genuinely core to your competitive advantage and you have the runway to hire and retain domain-specific engineering talent — actuarial-adjacent backend developers, compliance-aware architects, and product people who understand insurance workflows, not just fintech workflows in general. This path is slower to first launch but gives you full ownership of the platform's evolution.

Working with an outside insurance app development company makes more sense for insurers modernizing legacy systems, MGAs launching a new product line, or startups that need to reach market before a funding runway closes. The tradeoff is straightforward: you're paying for domain expertise and speed, which matters enormously in a category where the difference between an 8-month and an 18-month build often determines whether you catch a regulatory sandbox window or a first-mover advantage in a niche line of coverage.

Neither path is inherently better. The mistake is choosing based on cost alone without weighing how much insurance-specific complexity your team has actually dealt with before. A team that's built strong consumer fintech apps will still hit unfamiliar ground with rating engines, reinsurance data feeds, and state-by-state compliance logic — insurance has enough of its own idiosyncrasies that general software experience doesn't fully transfer.

Compliance Has to Be a Design Input, Not an Afterthought

Every serious insurance app has to be built around its regulatory environment from the first architecture decision, not patched in before a compliance review. In the US, this means state-by-state rate filing rules and NAIC data standards. In the EU, it's Solvency II requirements and increasingly detailed disclosure rules around AI-driven underwriting decisions, given growing regulatory scrutiny of algorithmic pricing. In markets like India, IRDAI's digital distribution push is actively encouraging micro-insurance delivered through UPI-linked apps, which changes both the technical integration requirements and the KYC depth needed at onboarding.

Regulatory sandboxes are becoming a meaningful part of the go-to-market path in several markets, letting insurtechs pilot new products under limited supervisory oversight before securing a full license. Several sandbox cohorts have shown that firms graduate to full licenses faster when regulators have already had time to familiarize themselves with a product's design during the pilot phase, and successful sandbox frameworks are increasingly enabling reciprocal agreements that let approved models transplant across borders with less friction. Teams that design their compliance and data-handling architecture with sandbox graduation in mind tend to move through licensing faster than teams that treat compliance as a separate workstream from product development.

There's also a data-residency dimension that often gets underestimated. Several markets now require customer records to remain within national borders, which complicates any multi-cloud or centralized data architecture. Insurtechs expanding across two or three countries at once often end up redirecting engineering budget away from product features and toward regulatory counsel and infrastructure segmentation just to keep pace with data-localization rules — a cost that's much easier to plan for upfront than to absorb mid-build.

What to Ask Before You Commit to a Build

A few questions tend to separate a well-scoped insurance app project from one that runs over budget and past deadline:

Does the technical architecture account for multi-jurisdiction rate and disclosure rules from day one, or will that be retrofitted later?
How is claims fraud detection built into the pipeline, and at what point in the claims journey does it trigger?
What's the actual data source for underwriting — static tables, or a live pipeline from telematics, wearables, or IoT feeds?
How is the app designed to integrate into third-party checkout flows if embedded insurance is part of the roadmap?
What happens to claims-status visibility and customer communication if a claim gets flagged for manual review?

If a proposed timeline or budget doesn't have clear answers to these, it's usually a sign the scope hasn't accounted for insurance-specific complexity yet.

The Bottom Line

Insurance app development in 2026 isn't really a technology problem anymore — most of the individual pieces (AI underwriting, computer-vision claims, embedded distribution APIs) are mature, well-understood capabilities. The hard part is sequencing them correctly against a fragmented, jurisdiction-specific regulatory landscape while still delivering a claims experience that holds up in a customer's worst moment. The insurers and insurtechs winning market share this year are the ones treating compliance, fraud detection, and customer experience as one integrated design problem, not three separate workstreams bolted together after the fact.

Stripe vs Your Startup: What 50+ Fintech Apps Got Wrong

Arpit Mishra — Thu, 02 Jul 2026 05:10:39 +0000

Stripe didn't break your startup. Your integration plan did.

That sentence sounds harsh until you've sat in enough post-mortems to notice the pattern repeat itself, almost word for word, across companies that have nothing else in common. A neobank in its Series A deck. A BNPL app burning runway on chargebacks. A payroll platform that failed its first SOC 2 audit. Different products, different founders, same root cause: they treated Stripe as a plug-and-play API instead of a core piece of fintech app development that deserved its own architecture decisions.

After reviewing patterns across more than 50 fintech builds, a few failure modes show up again and again — and almost none of them are Stripe's fault.

Mistake #1: Treating Payments as a Feature, Not a System

Most teams bolt Stripe onto their MVP the way they'd bolt on a newsletter signup — grab the SDK, wire up a checkout button, ship it. That works fine for a demo. It falls apart the moment real money, real disputes, and real regulators show up.

Payments in a serious fintech product aren't a feature. They're a system with its own state machine: authorization, capture, settlement, refund, chargeback, reconciliation. Skip modeling that state machine explicitly, and you end up with the classic symptom — support tickets that say "the app shows paid but the bank shows pending," multiplied across thousands of users.

Teams that get this right treat the payment layer as its own domain inside the broader fintech app development process, with its own data model, its own audit trail, and its own on-call rotation. Teams that get it wrong find out about the gap during a funding round due-diligence call, which is a genuinely terrible time to find out.

Mistake #2: Confusing "Stripe Is PCI Compliant" With "We Are PCI Compliant"

This one alone probably accounts for a third of the horror stories. Stripe's infrastructure being PCI-DSS certified says nothing about how your app stores logs, how your support team screenshots card details into a ticketing tool, or how your analytics pipeline accidentally captures the last four digits of a card number in an event payload.

Compliance is inherited, not automatic. If your onboarding flow, your customer support tooling, and your internal dashboards touch anything payment-adjacent, they're in scope — regardless of what Stripe promises on its own side of the fence. Founders who assume otherwise usually find out the hard way, right around the time an enterprise client's security team sends over a questionnaire nobody can answer.

Mistake #3: Underestimating Webhooks

Webhooks are where a shocking number of fintech apps quietly rot. A payment_intent.succeeded event fires, but the endpoint is down for eleven seconds during a deploy, and now there's a $340 payment that exists in Stripe's world but not in yours. Multiply that by scale and you get support queues full of "where's my money" tickets that have nothing to do with the payment actually failing — it succeeded. Your system just never heard about it.

The fix isn't complicated, but it is disciplined: idempotent webhook handlers, a retry queue, a reconciliation job that runs nightly and cross-checks Stripe's ledger against your own. None of this is exotic engineering. It's just the unglamorous 20% of fintech app development that never makes it into a pitch deck but absolutely makes it into a post-mortem.

Mistake #4: Designing the Refund Flow Last

Refunds get designed last because they feel like an edge case. They are not an edge case. In consumer fintech, refund and dispute flows are often the single biggest driver of support volume and the single biggest driver of churn when handled badly.

Apps that got this wrong shipped a refund button that fired an API call and nothing else — no state update, no customer notification, no internal record of why the refund happened. Multiply that by a support team fielding "did my refund go through?" a hundred times a week, and you understand why some startups quietly spent more engineering hours patching refunds in month eight than they spent building checkout in month one.

Mistake #5: Ignoring the E-Wallet Layer Until It's Too Late

This is the mistake most specific to this current wave of fintech products. A huge share of the 50+ apps studied weren't just processing one-time payments — they were building stored-value products, wallets, and BNPL-style balances on top of Stripe. That's a fundamentally different problem than checkout.

E-wallet app development introduces its own layer of complexity that Stripe's core APIs don't solve for you out of the box: ledger integrity (does the sum of every transaction always equal the wallet balance, to the cent, at any point in time), float management, dormant account handling, and regulatory questions around who's actually holding the money. Teams that treated their wallet balance as "just a number in a database column" instead of a fully audited ledger ran into balance drift — small, silent discrepancies that compound until finance can't explain a five-figure gap during an audit.

Good e-wallet app development builds the ledger first and the UI second. The wallet balance shown on screen should always be a read off an immutable transaction log, never a mutable field that gets incremented and decremented directly. It's a small architectural choice at day one and an extremely expensive one to retrofit at month eighteen.

Mistake #6: No Sandbox Discipline

A smaller but recurring issue: teams testing against live Stripe keys "just this once" to save time, or letting sandbox and production configs drift apart until a webhook secret mismatch takes down payments in prod for an afternoon. Basic, avoidable, and still shockingly common — because payment infrastructure is one of the few parts of a codebase where a five-minute shortcut can become a five-figure incident.

Mistake #7: Skipping the "What If Stripe Goes Down" Conversation

Stripe's uptime is genuinely excellent, which is exactly why teams stop planning for the exception. But "excellent" isn't "never," and a handful of the apps studied learned this during a checkout outage that lasted less than twenty minutes and still generated a week's worth of angry reviews.

The fix isn't switching providers or building a redundant payment stack — that's overkill for most early-stage products. It's smaller than that: a status page banner that degrades gracefully, a queued-retry pattern for failed submissions instead of a hard error, and a support macro ready to go before the outage happens instead of during it. Twenty minutes of downtime is forgettable. Twenty minutes of downtime with no messaging and no retry path is the thing that ends up in a one-star review.

Choosing Stripe vs. Building Custom Rails

Worth addressing directly, since it comes up in almost every scoping call: very few early-stage products need custom payment rails. Stripe (or Stripe Connect for marketplace and platform models) covers the vast majority of use cases a startup will hit in its first two years, and the real risk was never "should we use Stripe" — it was always "did we integrate it like it's core infrastructure, or like it's a feature."

The exceptions are narrow: very high-volume platforms negotiating direct interchange rates, or products in jurisdictions Stripe doesn't fully support yet. Everyone else is better served putting that engineering energy into the reconciliation job, the ledger, and the refund flow than into reinventing payment processing from scratch.

So What Actually Works

The startups that came out the other side of these 50+ builds without a payments horror story shared a few habits:

They mapped the full payment state machine before writing checkout code, not after.
They ran reconciliation jobs from day one, even before they had meaningful volume.
They designed refunds and disputes as first-class flows, not afterthoughts.
They treated their wallet ledger as the source of truth, and the UI as just a window into it.
They kept a hard line between sandbox and production, with zero shortcuts.

None of this required a bigger engineering team. It required treating payments infrastructure as a discipline instead of a checkbox — which is the actual difference between fintech app development that survives its first audit and fintech app development that doesn't.

Where This Usually Gets Outsourced — And Why That's Not a Bad Thing

Most early-stage teams don't have a payments architect on staff, and hiring one just to build the checkout flow rarely makes financial sense. That's where a lot of these 50+ apps brought in outside help — the smart ones, at least, brought it in early rather than after the first reconciliation disaster.