Marketplace Platform

A marketplace where strangers trust each other with their homes and their money

Softivum built the complete technology platform behind Helpora — the consumer app, the marketplace engine, the operations command centre and the brand site — wired into India's payment and identity infrastructure.

Client
Helpora
Helpora app showing nearby tasks on a live map, with a helper's route and escrow payment status

What was the problem?

Helpora came to Softivum with a brand, a market and a clear vision, and no product. A task marketplace is not one problem but three, each able to sink the product alone: trust between strangers when nobody has a reputation yet, money moving between two private individuals with the platform as guarantor, and a live event moving through the real world that both parties must see identically. All of it had to work for the Indian market specifically — phone-number identity, UPI, Aadhaar, and the everyday realities of connectivity and device quality — and be ready for an app-store launch on a schedule.

What made it hard

Commercially

  • No reputation data existed at launch, so trust had to come from verified identity instead
  • Marketplace economics needed to change at the speed of the market, not the release schedule

Technically

  • Three simultaneous hard problems — identity, money and realtime coordination — each capable of sinking the product alone
  • One shared foundation had to serve a web app, an operations console and native apps built by a different team
  • Live location had to reach the right person, in real time, and nobody else

Operationally

  • A non-technical operations team had to review verifications, oversee money movement, process withdrawals and resolve disputes unaided
  • A specialist mobile team would arrive later and needed to build without reverse-engineering the platform

At scale

  • The design had to carry Helpora from a single neighbourhood to a national footprint without a rewrite, expanding as the community grows and contracting when it is quiet

Security

  • Aadhaar data is among the most sensitive identity data in India and carries real liability if stored
  • Money moving between private individuals demands that a retry never charges twice or pays twice
  • Conversations and live locations are private to exactly two people

What we built

Four products were delivered: an installable consumer application with map discovery, escrow payment, chat, live tracking and door-code completion; the marketplace engine underneath it; an operations command centre where a non-technical team reviews verifications, oversees every movement of money, processes withdrawals, resolves disputes and tunes the marketplace economics; and the brand website with the full legal and compliance layer a regulated Indian marketplace must publish. A tested API package, integration guide and formal contracts for sensitive flows were delivered to the specialist mobile team in advance.

What it does

  • Map-based task discovery

    Tasks nearby shown on a live map, with true distance-based search and an operations-controlled radius.

  • Guided task creation

    Categories, photos, urgency and scheduling, plus recurring tasks that regenerate automatically.

  • Escrow-protected payment

    Funds collected when the task is posted, held during the work, released only on genuine completion.

  • Government-source identity verification

    Aadhaar via DigiLocker, plus bank, UPI, profile and face verification, with tiered eligibility.

  • Live helper tracking

    Realtime tracking of the helper en route, with routing and live ETA, visible only to the two people involved.

  • One-to-one chat

    Direct messaging with image sharing, typing indicators, read receipts and online presence.

  • Arrival verification by one-time code

    A code confirmed at the door, plus photo evidence of completion.

  • Earnings wallet and withdrawals

    A complete transaction ledger with payouts to bank account or UPI.

  • Dispute resolution

    Handled with full conversation context, with refund and release paths.

  • Runtime-configurable economics

    Commission, urgency pricing, referral rewards, escrow windows and search radius, all adjustable from the console.

  • Trust scores, badges and two-way reviews

    Reputation accrues once the marketplace has history.

  • Reporting, blocking and moderation

    Content and conduct moderation with an administrative audit trail.

  • Push notifications at every stage

    Both sides are told the moment anything changes, whether the app is open or not.

  • Saved addresses and autocomplete

    Address search and autocomplete with saved addresses.

  • Data export and deletion

    Automated purging of personal and biometric data on account deletion, and data export on request.

Engineering decisions

Choices that could have gone another way, and what each one bought.

  1. The payment gateway is a replaceable part

    Two fully working gateways sit behind a single internal contract. Payments already in flight continue to settle correctly with the provider that began them.

    Why it matters. Payment providers change their pricing, their approval outcomes and their reliability. Switching becomes a business decision rather than a development project, and Helpora is never tied to one vendor's terms.

  2. Identity verified without ever being held

    Aadhaar verification runs through DigiLocker, the government's own consent mechanism. The user never types an Aadhaar number and Helpora never stores one — the platform receives a verification verdict and the last four digits.

    Why it matters. Enough to prove a person is real, and nothing left worth stealing. The liability of holding India's most sensitive identity data simply never arrives.

  3. Provider downtime means 'not yet', never 'rejected'

    Identity providers go down, payment notifications get lost, phones lose signal mid-verification. Each is handled as a deferred outcome rather than a failed one, and payment confirmations are re-read from the gateway rather than trusted from the browser.

    Why it matters. A genuine user is never locked out of earning because someone else's service had a bad afternoon, and a lost callback never silently loses a payment.

  4. One platform, not three

    The web app, the operations console and the native apps all draw on the same marketplace engine and inherit the same rules — one definition of who may cancel a task, when escrow releases and who may read a conversation.

    Why it matters. Rules cannot drift between surfaces, features arrive everywhere at once, and a third-party mobile team cannot accidentally implement a different marketplace.

  5. The business controls the business

    Commission, urgency pricing, referral rewards, escrow windows and search radius are all adjustable from the operations console, with no developer and no deployment.

    Why it matters. Marketplace economics are the product. Tying them to a release schedule means the market moves faster than the business can respond.

Technical detail

Collapsed by default. Open whichever part you are evaluating.

Frontend
  • Installable PWA consumer application
  • Operations console
  • Brand website
Backend
  • Shared marketplace engine serving every Helpora surface
Database
  • Managed PostgreSQL with geospatial extensions
Authentication
  • Phone-number identity via MSG91
Authorization
  • Single platform-wide permission model inherited by every client
Background processing
  • Background processing designed to expand and contract with community activity
Messaging
  • Google Firebase for realtime, messaging and push
Deployment
  • Google Cloud
  • Vercel

Frontend
  • Progressive Web App
Database
  • PostgreSQL with geospatial extensions (managed)
Cloud
  • Google Cloud
  • Vercel
Integrations
  • Cashfree
  • Razorpay
  • Surepass
  • MSG91
  • Google Maps Platform
  • Google Firebase

Authentication
  • Phone-number identity
  • Tiered eligibility — light requirements to post, full verification to earn
Authorization
  • A single platform-wide definition of who may cancel a task, when escrow releases and who can read a conversation
Data protection
  • Aadhaar numbers are never typed by the user and never stored by the platform — only a verification verdict and the last four digits are retained
  • Payment confirmations are checked directly with the gateway rather than trusted from the browser
Abuse prevention
  • Reporting, blocking and conduct moderation
  • Identity verification as the barrier to earning
Auditability
  • Full administrative audit trail across the operations console
Privacy
  • Live location is visible only to the two people involved in a task
  • Automated purging of personal and biometric data on account deletion
  • Data export on request
  • Conversation retention limits with automatic archival

Mechanisms

  • Payment gateway abstraction with two live providers behind one internal contract
  • In-flight payments pinned to the provider that began them
  • Server-side payment verification against the gateway rather than trusting the browser
  • Idempotent critical operations
  • Graceful degradation of identity verification during provider outages

Failure scenarios handled

  • An identity provider goes down mid-verification
  • A payment notification is lost
  • A phone loses signal during verification
  • A payment provider changes pricing, approval outcomes or reliability
  • An operation is retried after an uncertain outcome

Idempotency. Critical operations can be retried safely, without charging twice, paying twice or notifying twice.

Recovery. The outside world is assumed to fail. Provider outages resolve to 'not yet' rather than a rejection, payment truth is always re-read from the gateway rather than accepted from the client, and gateway choice is a swappable business decision rather than an architectural commitment.

Before and after

Before

  • A brand, a market and a business plan, with no product
  • No mechanism for trusting a stranger at the door
  • No way for one neighbour to pay another with any protection
  • No operations capability
  • No mobile foundation for the incoming specialist team

After

  • A live consumer application installable on any device
  • Identity verified against government records before anyone can earn
  • Every payment held in escrow and released only on genuine completion
  • A non-technical operations team running the marketplace from one console
  • A documented, tested platform the mobile team could build on immediately

The build, by the numbers

What was built, at what scale. These describe the system's size, not its business results.

products delivered
4products deliveredConsumer application, marketplace engine, operations command centre and brand website
external platforms integrated
6external platforms integratedCashfree, Razorpay, Surepass, MSG91, Google Maps Platform and Firebase
live payment gateways
2live payment gatewaysBoth fully working behind a single internal contract, making provider choice a business decision
Aadhaar numbers stored
0Aadhaar numbers storedVerification runs through DigiLocker; the platform keeps only a verdict and the last four digits

What changed as a result?

Helpora moved from a brand and a business plan to a complete, launch-ready platform: a live consumer application, an operations team equipped to run the marketplace, payments and identity verification wired into India's financial and government infrastructure, and a mobile team building on foundations that were ready before they arrived. One partner. One platform. Every layer.

  • Delivered a complete launch-ready marketplace platform from a brand and a business plan
  • Verified identity against government records without ever storing an Aadhaar number
  • Made the payment gateway a replaceable part, with two live providers behind one contract
  • Put commission, pricing, escrow terms and search reach under business control with no deployment
  • Handed the native mobile team a documented, tested integration package before they started

Why does this matter in SaaS & startups?

Most first builds are too large. The useful MVP is the smallest thing that tests whichever assumption would sink the business if it were wrong. Both of our internal SaaS builds — a multi-tenant school portal and a restaurant POS — started as the narrow system one operator needed, then earned their scope.

  • Scope that assumes the idea is already validated

    Settings screens, admin tooling and dashboards feel like progress and prove nothing. Building them before anyone has paid is the most common way a runway disappears.

  • Multi-tenancy retrofitted too late

    Serving a second customer from a system built for one is an expensive rewrite. Where multiple organisations are clearly coming, tenancy belongs in the first architecture.

  • No route to a real user

    A product that exists only on a laptop cannot be tested. Deployment, accounts and access need to work from the first week, not the last.

  • Handover that leaves you dependent

    Code you cannot access, hosting in someone else's account and no documentation turn your own product into a negotiation. Ownership from day one avoids that entirely.

More on what we build for SaaS & startups

See it running

helpora.app(opens in a new tab)

Need something like this for SaaS & startups?

Tell us what is slowing the business down and we will tell you whether software is the right fix. If it is not, we will say so.

Ask a Quick Question on WhatsApp

Free 30 minutes · no obligation

WhatsAppCall