DEV Community: Arpit Mishra

The Classroom Fit in Your Pocket the Whole Time

Arpit Mishra — Thu, 06 Aug 2026 10:39:32 +0000

Strip away the pedagogy and the press releases, and an education app is one of the most technically demanding consumer products you can build. It's a video platform, a real-time collaboration tool, an analytics engine, an offline-first data store, and a payments system — running simultaneously, on low-end devices, over unreliable networks, for users ranging from six-year-olds to sixty-year-olds.

Most write-ups on this topic list features. This one is about the engineering underneath them: the architecture decisions, the hard problems, and the places where technical choices quietly determine whether the product survives. Here's how the pocket classroom actually gets built.

Architecture: Modular Monolith First, Services Later

The temptation in education app development is to start with microservices — separate services for content, users, live classes, assessments, payments. Resist it at MVP stage. The operational overhead of distributed systems (service discovery, inter-service auth, distributed tracing, eventual consistency bugs) is a tax you pay before you have the traffic that justifies it.

The pattern that works: a modular monolith with hard internal boundaries — content, learning, assessment, and commerce as separate modules with explicit interfaces, one deployable unit, one database with schema-level separation. When scale arrives, the seams are already cut: live-class infrastructure and video transcoding are typically the first candidates to extract into services, because their load profiles (spiky, compute-heavy) differ most from the CRUD core.

Backend stack choices are less important than the discipline around them, but the common center of gravity in 2026: Node.js or Python (Django/FastAPI) for the API layer, PostgreSQL as the system of record, Redis for sessions, leaderboards, and caching, and a message queue (RabbitMQ/SQS) for the async work — transcoding jobs, notification fanout, analytics ingestion. Mobile clients in Flutter or React Native unless you need platform-specific capabilities; education apps rarely do.

Video: The Subsystem That Eats Your Budget

Video is where education apps live or die technically, and it splits into two very different problems.

On-demand content is a pipeline problem. Uploaded lectures need transcoding into adaptive bitrate ladders (HLS/DASH) so a lesson plays smoothly on a flagship phone over fiber and a $120 Android over congested 4G. The non-negotiables: multiple renditions (240p through 1080p), segment-based delivery via CDN, and signed URLs with token expiry so your paid content isn't trivially scraped. DRM (Widevine/FairPlay) is a judgment call — it raises the piracy bar meaningfully but adds licensing cost and playback complexity; most platforms below enterprise scale ship signed URLs plus watermarking and accept the tradeoff.

Live classes are a real-time problem, and the protocol choice is the decision. WebRTC gives sub-second latency — mandatory for genuine interaction (a tutor asking "does that make sense?" can't wait four seconds for the answer) — but scales expensively beyond small groups without an SFU (Selective Forwarding Unit) architecture. HLS-based live streaming scales to thousands cheaply but carries 6–15 seconds of latency, fine for broadcast-style lectures with chat. The pragmatic pattern: WebRTC for classes under ~50 participants, low-latency HLS for large broadcasts, and a managed provider (Agora, LiveKit, or Amazon IVS) rather than self-hosted media servers until your volume makes the build-vs-buy math flip.

Offline-First Is Not a Feature Flag

The "classroom in your pocket" promise collapses the moment a student boards a metro or goes home to patchy rural connectivity. Offline support has to be architected, not appended.

That means: downloadable lesson packages (video renditions selected by device storage, plus documents and quiz definitions) stored encrypted on-device; a local database (SQLite/Isar/Room) acting as the primary read model, with the network as a sync layer rather than a dependency; and a conflict-resolution strategy for what happens when a student completes a quiz offline while the syllabus updated server-side. Last-write-wins is fine for progress markers; assessments need append-only event logs so nothing a student did ever silently disappears.

The sync engine is genuinely hard engineering — queued mutations, retry with exponential backoff, delta syncs to respect data caps — and it's invisible when done right, which is why it's chronically underscoped.

Assessment Engines and the Integrity Problem

A quiz module is a weekend project. An assessment engine is not. The difference: question banks with randomized selection and shuffled options, multiple question types (MCQ, numeric, code, long-form), timed sessions that survive app kills and network drops mid-exam, partial submission recovery, and — for anything high-stakes — integrity tooling: app-switch detection, copy-paste blocking, randomized question ordering per student, and optionally camera-based proctoring with its serious privacy weight.

The state-management rule that saves you: treat an exam session as a server-authoritative state machine. The client renders; the server owns the clock, the question sequence, and the submission record. Client-owned exam state is an invitation to manipulation and a support-ticket factory when devices die mid-test.

The Data Layer: Progress Is Your Real Product

Every tap, lesson completion, quiz attempt, and rewatch is signal. Architect the analytics path early: client events batched and shipped to an ingestion endpoint, landed in an event store, aggregated into the two views that matter — student progress models (mastery per topic, streaks, at-risk flags) and content performance (where do students rewind? which lesson precedes drop-offs?).

This is also the foundation for adaptive learning, if your roadmap includes it: recommendation of the next lesson based on mastery gaps is a tractable ML problem only if the event data has been clean from day one. Retrofitting analytics onto an app that never instrumented properly is archaeology.

One hard constraint shapes this entire layer: minors' data. COPPA, GDPR-K, and India's DPDP Act impose real requirements — parental consent flows, data minimization, no behavioral advertising to children, and deletion rights. These are architecture inputs, not legal footnotes; consent state has to gate the analytics pipeline itself.

Scale Patterns Worth Knowing Early

Education traffic is viciously spiky — exam nights, enrollment windows, 7 PM in every timezone. The mitigations, in order of leverage: CDN everything static, cache rendered course catalogs aggressively (they change rarely, get read constantly), queue all non-interactive work, use read replicas for the reporting load that teachers and admins generate, and autoscale the live-class infrastructure separately from the core API — their load curves are completely different shapes.

The Engineering Summary

The pocket classroom is deceptively hard: a video platform's infrastructure, a fintech app's payment care, a collaboration tool's real-time layer, and a children's product's compliance burden, in one codebase. The teams that ship well sequence it — modular monolith, managed video, offline-first data layer, server-authoritative assessments, instrumented from the first release — and extract complexity only when scale demands it.

The classroom fit in your pocket the whole time. Making it fit well is the actual work.

Building a HIPAA-Compliant Telemedicine API: Architecture, Code, and Pitfalls

Arpit Mishra — Fri, 24 Jul 2026 10:16:20 +0000

HIPAA-compliant" is one of those phrases that appears on every healthtech landing page and in almost no codebases. That's because HIPAA doesn't ship as a library you can npm install — it's a set of obligations (the Security Rule, the Privacy Rule, breach notification) that your architecture either satisfies or doesn't. This post translates those obligations into actual engineering decisions: how to structure a telemedicine API, what the code looks like, and the pitfalls that quietly turn "compliant" systems into breach reports.

We'll use Node.js/Express and PostgreSQL for examples, but every pattern here maps directly to Django, Spring Boot, or Go.

What HIPAA Actually Requires From Your Code

Strip away the legal language and the Security Rule demands four things from your system:

Access control — only authorized people see Protected Health Information (PHI), and only the minimum they need
Encryption — PHI is unreadable in transit and at rest
Audit trails — every access to PHI is logged: who, what, when
Integrity and availability — data can't be silently altered, and it survives failures

Everything below is one of these four, expressed as architecture.

Architecture Overview

A telemedicine API decomposes into services with very different PHI exposure:

┌──────────────┐ ┌──────────────────────────────────┐
│ Mobile/Web │────▶│ API Gateway (TLS termination, │
│ Clients │ │ rate limiting, JWT validation) │
└──────────────┘ └───────────┬──────────────────────┘
│
┌────────────┬───────────┼────────────┬─────────────┐
▼ ▼ ▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌─────────┐ ┌──────────┐ ┌───────────┐
│ Auth │ │ Patient │ │ Consult │ │ Video │ │ Audit │
│ Service │ │ Records │ │ Booking │ │ Session │ │ Logger │
│ (no PHI)│ │ (PHI!) │ │ (PHI) │ │ (PHI) │ │ (append- │
└─────────┘ └──────────┘ └─────────┘ └──────────┘ │ only) │
└───────────┘

The design principle: minimize which services touch PHI at all. Your auth service should know a user exists but nothing about their health. Your notification service should send "You have an appointment tomorrow" — never "Your cardiology appointment about arrhythmia is tomorrow." Every service that avoids PHI is a service you don't have to defend in an audit.

Access Control: RBAC With Context

Role-based access control is the baseline, but healthcare needs contextual RBAC: a doctor shouldn't see every patient — only patients with whom they have an active care relationship.

javascript
// middleware/authorize.js
async function canAccessPatientRecord(req, res, next) {
const { userId, role } = req.auth; // from verified JWT
const { patientId } = req.params;

if (role === 'patient') {
if (userId !== patientId) {
await audit.log({ actor: userId, action: 'ACCESS_DENIED',
resource: patient:${patientId} });
return res.status(403).json({ error: 'Forbidden' });
}
return next();
}

if (role === 'doctor') {
// Care relationship check — the piece most implementations skip
const relationship = await db.query(
SELECT 1 FROM care_relationships WHERE doctor_id = $1 AND patient_id = $2 AND status = 'active',
[userId, patientId]
);
if (relationship.rowCount === 0) {
await audit.log({ actor: userId, action: 'ACCESS_DENIED',
resource: patient:${patientId} });
return res.status(403).json({ error: 'Forbidden' });
}
return next();
}

return res.status(403).json({ error: 'Forbidden' });
}

Note that denied attempts are logged too — under HIPAA, an access attempt is an auditable event, and denied-access patterns are exactly how you detect a compromised account probing for data.

Encryption: In Transit, At Rest, and In the Column

TLS 1.2+ everywhere is assumed (terminate at the gateway, and use TLS between internal services too — "internal network" is not a security boundary HIPAA recognizes). Disk-level encryption (AWS RDS encryption, for instance) is also assumed. The layer teams miss is column-level encryption for the most sensitive fields, so that even a leaked database dump or a misconfigured read replica doesn't expose diagnoses:

javascript
// crypto/phi.js — AES-256-GCM with per-record IVs
const crypto = require('crypto');
const KEY = Buffer.from(process.env.PHI_ENCRYPTION_KEY, 'hex'); // from KMS, never hardcoded

function encryptPHI(plaintext) {
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', KEY, iv);
const enc = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
return {
ciphertext: enc.toString('base64'),
iv: iv.toString('base64'),
tag: cipher.getAuthTag().toString('base64'),
};
}

function decryptPHI({ ciphertext, iv, tag }) {
const decipher = crypto.createDecipheriv('aes-256-gcm', KEY,
Buffer.from(iv, 'base64'));
decipher.setAuthTag(Buffer.from(tag, 'base64'));
return Buffer.concat([
decipher.update(Buffer.from(ciphertext, 'base64')),
decipher.final(),
]).toString('utf8');
}

Two operational rules: the key lives in a KMS (AWS KMS, GCP Cloud KMS, Vault) and is rotated on a schedule; and GCM's auth tag gives you integrity verification for free — if the ciphertext was tampered with, decryption throws instead of returning silently corrupted health data.

The Audit Trail: Append-Only or It Doesn't Count

An audit log that the application can UPDATE or DELETE is not an audit log. Enforce immutability in the database itself:

sql
CREATE TABLE audit_log (
id BIGSERIAL PRIMARY KEY,
actor_id UUID NOT NULL,
actor_role TEXT NOT NULL,
action TEXT NOT NULL, -- VIEW, CREATE, UPDATE, EXPORT, ACCESS_DENIED
resource TEXT NOT NULL, -- e.g. 'patient:uuid', 'consultation:uuid'
ip_address INET,
occurred_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- The app role can INSERT and SELECT. Nothing can UPDATE or DELETE.
REVOKE UPDATE, DELETE ON audit_log FROM app_role;

Log every PHI read — not just writes. "Who viewed this record and when" is precisely the question an Office for Civil Rights investigation asks, and it's the question most systems can't answer because they only logged mutations.

Video Consultations: Keep Media Off Your Servers

The video call itself carries PHI (the conversation is health information), but you can architect so the media never touches your infrastructure. Use a WebRTC provider that supports HIPAA workflows and will sign a Business Associate Agreement (BAA) — this is non-negotiable, and it applies to every vendor in your stack that could touch PHI: video, cloud hosting, email, SMS, error tracking, analytics. Your API's job is only session brokering:

javascript
// POST /consultations/:id/video-token
// API issues a short-lived room token; media flows peer-to-provider, not through us
router.post('/consultations/:id/video-token',
canAccessConsultation,
async (req, res) => {
const token = videoProvider.createToken({
room: consult-${req.params.id},
identity: req.auth.userId,
ttl: 900, // 15 minutes — short-lived by design
});
await audit.log({ actor: req.auth.userId, action: 'VIDEO_JOIN',
resource: consultation:${req.params.id} });
res.json({ token });
});

If you enable recording, the recording is PHI at rest: it needs the same encryption, access control, and audit treatment as a medical record — a detail that's easy to miss when the video SDK makes recording a one-line config flag.

The Pitfalls That Actually Cause Breaches

PHI in logs. console.log(req.body) on a symptoms endpoint just wrote diagnoses into your logging pipeline — and your log platform probably hasn't signed a BAA. Scrub PHI fields at the logger level, not by developer discipline.

PHI in URLs. GET /patients?name=John+Smith puts PHI into server access logs, browser history, and proxies. Identifiers go in the path or body; health data never goes in query strings.

Tokens that live too long. A 30-day JWT on a shared family tablet is an unauthorized-access finding waiting to happen. Use short-lived access tokens (~15 minutes) with rotating refresh tokens, and implement server-side revocation.

Error messages that leak. A stack trace returning "column diagnosis_code does not exist" tells an attacker your schema. Sanitize error responses in production; log details server-side only.

Skipping the BAA on "minor" vendors. Your error tracker, your email provider, your push notification service — if PHI can reach them, they need a BAA. This is the compliance gap auditors find first because engineering teams don't think of Sentry as a "healthcare vendor."

Backups nobody tested. Availability is a HIPAA requirement. Encrypted backups you've never restored are a hypothesis, not a disaster recovery plan.

Wrapping Up

HIPAA compliance isn't a feature you add — it's a set of properties your architecture either has or lacks: minimal PHI surface area, contextual access control, encryption with managed keys, append-only auditing, BAAs across the vendor chain, and operational discipline around logs, tokens, and backups. Build these in from the first commit and compliance becomes a natural consequence of the design. Bolt them on later and you'll rebuild the system under the least pleasant deadline there is: a regulator's.

How to Build a HIPAA-Compliant Healthcare App: Architecture, APIs, and Security Best Practices

Arpit Mishra — Fri, 24 Jul 2026 09:14:12 +0000

Healthcare apps have transformed the way patients connect with providers, access medical records, and manage their health. From telemedicine platforms to patient portals and remote monitoring solutions, digital healthcare is now a core part of modern care delivery.

However, building a healthcare application is fundamentally different from creating a typical mobile or web app. Developers must protect sensitive patient information, comply with regulations like HIPAA, and design systems that are scalable, secure, and reliable.

This guide walks through the technical architecture, essential APIs, and security best practices required to build a HIPAA-compliant healthcare application.

Why HIPAA Compliance Matters

The Health Insurance Portability and Accountability Act (HIPAA) establishes standards for protecting Protected Health Information (PHI). Any healthcare application that stores, processes, or transmits patient data in the United States must implement safeguards that ensure confidentiality, integrity, and availability.

Failure to comply can result in:

Data breaches
Legal penalties
Financial losses
Reputation damage
Loss of customer trust

HIPAA compliance should be considered during architecture planning—not after development.

Planning Your Healthcare App

Before writing code, clearly define your application's objectives.

Typical healthcare applications include:

Telemedicine platforms
Patient portals
Appointment booking systems
Electronic Health Record (EHR) apps
Medication reminder apps
Pharmacy delivery apps
Mental health applications
Remote patient monitoring platforms

Each type has different compliance and technical requirements.

Recommended Technology Stack

A modern healthcare application should prioritize scalability and security.

Frontend
React
React Native
Flutter
Swift
Kotlin
Backend
Node.js
Java Spring Boot
.NET Core
Python Django
Go
Database
PostgreSQL
MySQL
MongoDB (for selected use cases)
Cloud Platforms
AWS
Microsoft Azure
Google Cloud Platform

Choose cloud services that provide HIPAA-eligible infrastructure and sign a Business Associate Agreement (BAA) when required.

System Architecture

A scalable healthcare platform generally follows a layered architecture.

Mobile App / Web Portal

│

API Gateway

│

Authentication Service

│

Business Logic Layer

│

Healthcare APIs

│

Database + Secure Storage

│

Monitoring & Logging

Separating services makes maintenance easier while improving scalability and security.

Core Features

Most healthcare apps include:

Patient Features
Registration
Secure login
Appointment booking
Video consultations
Medical history
Prescription access
Payment gateway
Notifications
Doctor Features
Dashboard
Calendar management
Patient records
Consultation history
e-Prescriptions
Clinical notes
Admin Panel
User management
Provider verification
Reports
Audit logs
Analytics
Compliance monitoring
Authentication Best Practices

Authentication is the first line of defense.

Recommended methods include:

OAuth 2.0
OpenID Connect
Multi-Factor Authentication (MFA)
Biometric login
JWT with short expiration
Session timeout

Never store passwords in plain text.

Use:

bcrypt
Argon2

for secure password hashing.

Secure API Design

Healthcare APIs should follow REST or GraphQL best practices.

Example endpoints:

POST /patients

GET /appointments

POST /consultations

PUT /medical-records

GET /prescriptions

Every API should implement:

Authentication
Authorization
Input validation
Rate limiting
Logging
Error handling
Use FHIR Whenever Possible

FHIR (Fast Healthcare Interoperability Resources) has become the preferred standard for exchanging healthcare information.

Benefits include:

Easier EHR integration
Standardized patient records
Better interoperability
Faster integrations
Future-proof architecture

FHIR resources commonly used:

Patient
Practitioner
Observation
Medication
Appointment
Encounter
Database Design

Healthcare databases require careful planning.

Example entities:

Users

Patients

Doctors

Appointments

Medical Records

Prescriptions

Payments

Notifications

Audit Logs

Sensitive data should never be stored without encryption.

Encrypt Everything

Encryption is mandatory.

Data in Transit

Use:

HTTPS
TLS 1.2+
Secure WebSockets
Data at Rest

Encrypt:

Database
Backups
File storage
Images
PDFs
Medical reports

Use strong encryption such as AES-256.

Role-Based Access Control (RBAC)

Not every user should access every record.

Example roles:

Patient

Doctor

Nurse

Receptionist

Administrator

Support Team

Permissions should be granted using the principle of least privilege.

Audit Logging

Every important action should be recorded.

Track events like:

Logs should be immutable and securely stored.

Secure Video Consultations

Telemedicine requires secure communication.

Popular technologies include:

WebRTC
TURN servers
STUN servers

Security recommendations:

End-to-end encryption
Secure meeting tokens
Session expiration
Waiting room verification
Notification Strategy

Healthcare notifications often include sensitive information.

Instead of sending:

"Your blood test result is positive."

Send:

"You have a new update in your healthcare app."

This minimizes exposure if a notification is viewed by someone else.

Third-Party Integrations

Healthcare apps commonly integrate with:

Payment gateways
Insurance providers
SMS services
Email providers
Video platforms
Laboratory systems
Pharmacy systems
Wearable devices

Always verify that vendors meet your security and compliance requirements.

Common Security Mistakes

Avoid these common pitfalls:

Hardcoded API keys
Weak passwords
Missing MFA
Unencrypted databases
Public cloud storage
Excessive user permissions
Missing audit logs
Insecure file uploads
Poor session management

Security should be built into every development phase.

Performance Optimization

Healthcare applications must remain responsive under heavy load.

Recommended practices:

API caching
CDN for static assets
Lazy loading
Database indexing
Background job queues
Horizontal scaling
Load balancing

Performance directly impacts patient experience.

Testing Strategy

A healthcare application requires extensive testing.

Include:

Unit testing
Integration testing
API testing
Load testing
Security testing
Penetration testing
Accessibility testing
Compliance validation

Automate testing within your CI/CD pipeline whenever possible.

Deployment Best Practices

Production deployments should include:

Infrastructure as Code
Automated backups
Continuous monitoring
Disaster recovery planning
Secret management
Centralized logging
Zero-downtime deployments

Monitor your infrastructure continuously for unusual activity.

Future Trends

Healthcare applications continue to evolve with emerging technologies such as:

AI-assisted diagnostics
Voice-enabled clinical documentation
Remote patient monitoring
Predictive analytics
Wearable health integrations
Ambient clinical intelligence
Personalized healthcare recommendations

Developers who design flexible architectures today will be better prepared to adopt these innovations.

Final Thoughts

Building a HIPAA-compliant healthcare application involves much more than developing user interfaces and APIs. Security, privacy, scalability, and interoperability must be integrated into every stage of the software development lifecycle.

By following best practices for architecture, implementing secure APIs, adopting standards like FHIR, encrypting sensitive data, and maintaining detailed audit trails, development teams can build healthcare applications that are both compliant and trusted by patients and providers.

Whether you're developing a telemedicine platform, patient portal, or medical records system, investing in a secure and scalable foundation will help ensure long-term success in the rapidly evolving healthcare technology landscape.

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.

DEV Community: Arpit Mishra

The Classroom Fit in Your Pocket the Whole Time

Building a HIPAA-Compliant Telemedicine API: Architecture, Code, and Pitfalls

How to Build a HIPAA-Compliant Healthcare App: Architecture, APIs, and Security Best Practices

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

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

Why Most Healthcare Apps Fail Security Review — A Technical Breakdown

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

Twilio vs WebRTC: Choosing Video Infrastructure for a Telehealth App

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

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

Find out whether you have a problem

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

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