DEV Community: Disha Kedia

Why two riders never get the same driver BD intern at Miracuves, not an engineer. Ride apps lock a driver so two riders never share one. Otherwise: two strangers, one Corolla. Engineers, thoughts? #miracuves #think #webddev #architechture

Disha Kedia — Thu, 15 Oct 2026 09:38:52 +0000

Engineering AI Fit Engines: Computer Vision, Body Feature Embeddings, and Privacy Compliance published.

Disha Kedia — Thu, 08 Oct 2026 08:52:39 +0000

Author: Disha | Business Development & Tech Strategy at Miracuves

Amazon's recent privacy data exports revealed how AI sizing engines analyze body shapes, utilizing computer vision, purchase history, and user feedback to generate body-attribute vectors (categorizing proportions like shoulder-to-hip ratios, torso length, and seat flatnesses) to optimize garment fit scoring.

System Insight: Engineering a scalable apparel recommendation system requires transforming raw body measurements or 3D image scans into high-dimensional feature vectors while maintaining strict data privacy, encryption, and GDPR/CCPA compliance.

High-Dimensional Body Mesh & Feature Extraction Data Architecture Challenge: Rather than storing static categorical labels in SQL tables, modern computer vision systems construct 3D body meshes from user photos or inputs to compute parametric feature vectors.

The data pipeline consists of three core layers:

Parametric Mesh Estimation: Extracting 3D surface vertices from 2D images or user-provided measurements.
Vector Normalization: Converting raw millimeter metrics into normalized scalar ratios (e.g., waist-to-hip ratio, shoulder breadth, seat contour index).
Garment Elasticity Mapping: Cross-referencing normalized body vectors against 3D fabric tension matrices to calculate a deterministic fit score.

Sizing Recommendation Engine & Vector Search

Real-Time Inference Workflow: To recommend the best size in real time across millions of SKUs, the system maps user body vectors against garment measurement vectors using vector similarity search.

User Embedding Storage: Store body profiles as encrypted float vectors inside vector databases.
Similarity Measurement Scoring: Calculate cosine similarity between the user's vector and the garment's dimensional profile.
Feedback Loop Training: Adjusting vector weights based on post-purchase return logs.
Privacy-Preserving Architecture & Biometric Data Compliance

Data Governance & Anonymization: Anatomical profiling creates severe compliance requirements under global privacy regulations.

To build a compliant recommendation stack:

Zero-Knowledge Profiling: Hashing and encrypting sensitive body metrics on the client device before sending feature vectors to central servers.
Granular Privacy Exports: Providing transparent JSON endpoint exports allowing users to audit, modify, or erase their stored body vectors.
Differential Privacy in Training: Applying noise injection when retraining sizing models on aggregated user purchase datasets to prevent individual body re-identification.

Accelerate Your E-Commerce , AI Engineering with Miracuves

🛠️ How Miracuves Simplifies Complex AI & Retail Backends: Building computer vision pipelines, vector recommendation engines, and privacy-compliant marketplace architectures from scratch takes months of specialized engineering.

At Miracuves, we build production-ready, white-label e-commerce platforms and custom AI solutions (Amazon clones, Shopify clones, custom ML recommendation suites) for growing startups and enterprise teams:

Turnkey Production-Ready Codebase: Modular microservices with 100% source code ownership.
Pre-Engineered AI Modules: Vector search integration, recommendation engines, and privacy-first user management.
6-Day Guaranteed Deployment: Launch fully customized, branded web and mobile apps on your own AWS/GCP servers in just 6 working days.

Debate: How is your team handling biometric/body feature data storage and privacy compliance in recommendation engines? Do you prefer on-device vector generation or server-side ML pipelines for personalized e-commerce fit?

Drop your architecture thoughts and system design questions in the comments below!
Explore our full catalog of modular microservices and custom dev solutions at www.miracuves.com

Bitchat was recently delisted from the Apple App Store and Google Play Store in India following government orders under Section 69A of the IT Act

Disha Kedia — Mon, 05 Oct 2026 07:27:40 +0000

Author: Disha | Business Development & Tech Strategy at Miracuves

System Insight: Bitchat’s core innovation—using Bluetooth Low Energy (BLE) mesh networking to route encrypted messages peer-to-peer without internet infrastructure or central servers—made it highly resilient to network shutdowns. However, its delisting highlights an engineering vulnerability: a decentralized protocol tied to centralized app stores.

The Mechanics of Bluetooth Mesh & Offline-First Messaging Architectural Concept: Standard messaging relies on Client-Server HTTP/WebSocket gateways. Bitchat and similar protocols utilize ad-hoc peer-to-peer mesh networking to relay packets across physical distance without cellular towers.

Key components of an offline-first mesh stack include:

Peer Discovery & Handshaking: Devices continuously broadcast encrypted BLE advertising packets to detect neighboring nodes within range (10–30 meters).
Multi-Hop Relay Routing: Message payloads hop across intermediate devices (nodes) using store-and-forward mechanisms until reaching the recipient device.
Ephemeral Key Cryptography: End-to-end encryption generated directly on client hardware using public-private key pairs, ensuring intermediate relay nodes cannot inspect packet contents.

Solving the Single Point of Failure: Multi-Channel Distribution
⚡ Distribution Engineering: When an application is removed from centralized stores (iOS App Store / Google Play), engineers must support alternative installation pathways to preserve user onboarding:
1. Progressive Web Application (PWA) Fallbacks: Utilizing Web Bluetooth APIs and Service Workers to run mesh discovery directly inside modern mobile browsers.
2. Direct Android APK Bundling, Web-APKs: Providing self-hosted, signed APK downloads hosted on distributed storage networks or private mirrors.
3. Enterprise; TestFlight Alternatives: Deploying via custom Enterprise Provisioning Profiles or alternative open marketplaces (F-Droid, AltStore).
4. Regulatory Hybrid Messaging Backends Architectural Balance: Building production-grade communication apps often requires a hybrid approach—combining server-assisted WebSocket channels for high-density traffic with offline mesh fallback protocols.

Server-Assisted Relay: For standard operating conditions, WebSocket channels over TLS provide millisecond delivery latency.
Ad-Hoc Peer Fallback: When central server connections time out or local networks drop, client apps automatically fall back to local BLE or Wi-Fi Direct mesh routing.
Decentralized Identity (DID): Mapping user identities to cryptographic wallet addresses or public keys rather than centralized phone numbers or server-managed IDs.

Accelerate Your Communication Stack with Miracuves

How Miracuves Empowers Engineers & Founders:
Building real-time messaging gateways, end-to-end encryption protocols, and multi-tenant admin engines from scratch requires hundreds of developer hours.

At Miracuves, we build modular backend architectures and white-label communication applications (WhatsApp clones, ChillChat clones, live streaming suites) for startups and enterprise teams:

Turnkey Production-Ready Codebase: Modular Node.js / Laravel backends paired with native iOS/Android or Flutter client apps.
100% Source Code Ownership: Delivered in writing with complete freedom to self-host, customize, and deploy on your own servers.
Guaranteed 6-Day Delivery: Go live with fully branded, secure messaging platforms in just 6 working days.

How are you handling offline-first capabilities, BLE/Wi-Fi Direct mesh routing, or alternative distribution pathways (PWAs / Web-APKs) in your current stack? Have you faced app store delisting or distribution hurdles with decentralized protocols?

Drop your architecture thoughts, code snippets, or system design questions in the comments!

Explore our full catalog of modular microservices and custom dev solutions at Miracuves.com (https://miracuves.com)

Tinder recently announced Group Hangouts a feature enabling groups of 3 to 15 friends to select a shared activity.

Disha Kedia — Thu, 01 Oct 2026 10:33:16 +0000

Core System Shift From an engineering perspective, moving a social platform from 1-on-1 single-entity matching to N × M group-entity matching requires a fundamental redesign of your database schema, state management, matching algorithms, and real-time room routing.

Database Scheme & State Management

📌 Key Data Challenge: In traditional dating applications, matches exist as simple paired user connections. For Group Hangouts, systems must introduce dedicated group profiles, member mappings, and group match entities while handling user presence and privacy states seamlessly.

Instead of tracking two individual users, the database structure manages:
Group Container: Storing group metadata, activity tags (e.g., Bowling, Concerts, Pottery), active status, and maximum participant caps (up to 15 members).
Member Mappings: Tracking individual user roles (creator vs. member), join timestamps, and privacy/block states.
Group Interaction Logs: Recording group-level likes, passes, and reciprocal match triggers.

Group Matching Engine Logic ⚡Reciprocal Matching Rule:Unlike individual swiping where both individuals must like each other, Tinder's Group Hangouts connects two groups if at least one member from each group likes the target group profile.

The backend matching workflow follows four key steps:
1.Swipe Logging: When a member swipes on a target group, the system logs the interaction against the actor group ID.
2.Reciprocal Check: The engine immediately verifies if the target group has already logged an active like toward the actor group.
3.Channel Provisioning: If a reciprocal match is confirmed, the system instantly provisions a shared group chat channel.
4.Real-time Notifications: Multi-party push notifications and socket events are dispatched to all active members across both groups.

Real-Time Group Chat & Individual Participant Controls Privacy & Safety Controls: Tinder allows a user to leave a group chat conversation without exiting their off-app friend circle.

To handle this cleanly in real-time messaging pipelines (Socket.io, MQTT, or WebSockets):

Dynamic Room Subscriptions: When a participant opts to leave or mute a chat, their messaging state updates to inactive without breaking the overall group profile. *Selective Broadcast Filtering: Real-time event gateways route incoming messages exclusively to active chat participants while excluding muted or departed users.

Accelerate Your App Build with Miracuves

🛠️ How **Miracuves Simplifies Complex Social Backends:**
Engineering multi-tenant group matching, real-time messaging sync, and geospatial discovery pipelines from scratch can take hundreds of engineering hours.

At Miracuves, we build modular, high-performance backend systems and white-label mobile app solutions (Flutter / React Native + Node.js / Laravel / AWS).

Turnkey Production-Ready Codebase: Modular microservices with 100% source code ownership.
Pre-Built Social Engines: Real-time messaging, video/audio streaming, and geospatial matching modules.
6-Day Guaranteed Deployment: Launch fully customized, branded social apps to the App Store and Google Play in just 6 working days.

👉 Explore our full catalog of turnkey app solutions and custom dev engineering at Miracuves.com.

Quick Commerce Was Never Just About 10-Minute Delivery

Disha Kedia — Tue, 29 Sep 2026 11:24:57 +0000

The more I look at quick commerce, the less I think the interesting part is the “quick.”

For a long time, I thought the entire quick-commerce story was basically:

Need something → open app → order → someone brings it to you ridiculously fast

That one ingredient you forgot while cooking and suddenly decided was absolutely essential at 10:30 PM.

Simple enough.
But then the category started expanding.

And now I'm starting to wonder if we've been looking at the wrong part of the story.

Blinkit recently started piloting products made by artisans under the PM Vishwakarma scheme in Bengaluru, including products such as pottery, toys, dolls and decorative items. At the same time, quick-commerce platforms are becoming increasingly important for product discovery and advertising during major shopping periods.

That changes the question.

It isn't just:
“How quickly can you deliver something?”

It's:
“How many different kinds of things can you make discoverable, purchasable and deliverable through the same system?”

And from a technology perspective, that's much more interesting.
Because groceries are actually the easy version

Okay, maybe “easy” is unfair.

Running a massive grocery delivery network is obviously not easy.

But the products themselves are relatively predictable.

You have:

standardized SKUs
predictable packaging
known inventory
established categories
repeat purchasing patterns
relatively straightforward fulfillment

Now take something like a handmade product.

Maybe there's one seller.Maybe they have 17 pieces.Maybe every piece looks slightly different.Maybe the product needs special packaging.Maybe inventory changes manually.Maybe there isn't even a standard product code.

Suddenly the beautiful little:

Add to Cart → Pay → Deliver

button is sitting on top of a much messier problem.

This is the kind of distinction I've started noticing more since working as a BD intern at Miracuves. A business requirement can sound incredibly simple when you hear it from the outside.

The technology underneath it usually isn't.
The interface lies to you.
But a good interface makes a complicated system look ridiculously simple.

You search.You click.You pay.Done.

Behind that:
Seller → Catalog → Inventory → Pricing → Order → Payment → Fulfillment → Delivery → Notification → Review

And all of those systems have to agree with each other. That's where marketplace technology gets interesting.
At Miracuves, I've started seeing how a seemingly simple product requirement can quickly turn into a much bigger conversation about workflows, users, permissions, inventory, payments, dashboards and integrations.

The customer doesn't care about any of that. They shouldn't have to.They just want the button to work. And quick commerce is quietly becoming a discovery engine

This is probably the shift I find most interesting.

Quick-commerce apps aren't only being used when people already know what they want.

They're increasingly becoming places where people discover things they didn't plan to buy.

Business Standard recently reported that quick-commerce advertising is becoming a significant part of festive-season spending, while research cited in the report found that a substantial share of online shoppers discover products through quick-commerce platforms.

That changes the customer journey.
Discovery-driven commerce:
I open the app → I see X → I suddenly want X → I buy X.

Now your marketplace isn't just managing transactions.

It's managing attention.

And that's where things get really interesting.
The marketplace has to understand more than inventory

Imagine putting thousands of completely different sellers onto one platform.
Their products don't behave the same way.Their inventory doesn't behave the same way.Their fulfillment doesn't behave the same way.Their customers don't behave the same way.Yet the platform has to make all of them feel like part of one coherent experience.

This is something I keep coming back to when looking at marketplace products at Miracuves

The hard part isn't necessarily creating another product listing page.
It's designing the systems around it.
This is where I think marketplace software gets interesting

One thing my time at Miracuves has changed for me is how I look at product ideas.

Earlier, I'd naturally focus on what the user sees.
The app. The screens. The buttons.The features.

Now I find myself asking:
What has to happen behind this screen for the feature to actually work?

Take a basic marketplace search.

It looks like:
Search → Results → Product → Buy

A marketplace isn't really a website
This is probably the biggest thing I've learned while being exposed to different product conversations through Miracuves.

A marketplace isn't just a website where sellers upload products. It's an agreement between multiple systems and multiple types of people.

The customer wants convenience.The seller wants visibility.The platform wants healthy transactions.The delivery partner wants efficient routes.The business wants reliable data.And everyone expects the system to keep working when thousands of transactions happen at once.

That's why:
“We want to build a marketplace”

isn't really a technical requirement.
It's the beginning of one.

The interesting questions come after that.
Who are the users?
What are they buying?
Who controls inventory?
How does discovery happen?
What happens when something is unavailable?
Who handles fulfillment?
What happens when something goes wrong?
Those questions are much less glamorous than “build an app.”

They're also much more important.
Maybe “quick commerce” is becoming a misleading name

Because if the category keeps expanding, speed might eventually become the least interesting part.

The real value could become:
Discovery + availability + trust + convenience + fulfillment
all inside one experience. At that point, we're not really talking about a faster grocery store.
We're talking about a new kind of local digital marketplace.

And that's a much bigger idea.
The engineering question I'd actually be watching

Not:
“Can they make delivery five minutes faster?”

But:
“Can the infrastructure handle a marketplace where almost anything can become instantly discoverable and purchasable?”

Because once you move from predictable products to millions of different products, sellers and use cases, the complexity doesn't disappear.

It just moves underneath the interface.

That's probably the part I'll be watching most closely.

Working in BD at Miracuves has made me appreciate that side of technology much more than I expected.

A product can look incredibly simple on the outside.

Sometimes that's the biggest clue that something complicated is happening underneath.

And honestly?
That's the part of software I find fascinating.
Written from the perspective of a BD intern learning to look beyond the product screen and into the systems that make the product possible.

Maybe AI Didn't Make Developers Faster.

Disha Kedia — Mon, 28 Sep 2026 07:26:32 +0000

I've been thinking about something lately.

AI has made it incredibly easy to turn an idea into a prototype.

A few prompts.
A little debugging.
And suddenly, there's something you can actually show.

But then comes the interesting part.

Making that thing reliable

That's where the story changes.

You start thinking about:

→ What happens when the user does something unexpected?
→ What happens when an API fails?
→ Who should have access to what?
→ Can this scale beyond the demo?
→ Can another developer understand the code six months from now?
→ And most importantly, do we actually need all this code?

It made me realise something while exploring a few product ideas:

The bottleneck may no longer be building the first version.

The bottleneck is figuring out what deserves to become a real product.

AI can help us move from idea → prototype much faster.

But going from prototype → something people can actually depend on still requires a lot of human thinking.

Maybe that's the next interesting phase of software development.

Not:

“Can AI build it?”

But:

“Should we build it, and what should it become?”

Still figuring this one out myself.

Would love to hear how other developers are thinking about this.

We often start product conversations with: “What should we build?”

Disha Kedia — Wed, 23 Sep 2026 05:59:23 +0000

I’m starting to think the better question is:
“What do we actually need to learn?”
Because an MVP can become surprisingly large.
Login.
Payments.
Admin dashboard.
Notifications.
Analytics.
Multiple user roles.
Before you know it, the “MVP” has turned into a full product roadmap.
But if the purpose of an MVP is to validate an idea, shouldn't the first version focus on answering the biggest unanswered question?
From a product/business perspective, I’ve started looking at development differently:
Not everything needs to be custom-built.
Some parts of an application are already well-understood engineering problems.
The interesting engineering work is often in the parts that are specific to the product:
— the workflow
— the business logic
— the user experience
— the integrations
— the thing that actually makes the product different
That doesn't mean “never build from scratch.”
It means being intentional about where you spend development time.
Working around Founder’s Office conversations has made me realise that development speed isn't only about how fast engineers write code.
Sometimes, it starts much earlier:
with deciding what doesn't need to be built yet.
Curious to hear from developers and product people here:
What's one thing you think teams overbuild in their first version?