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
- Industry
- SaaS & Startups

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.
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.
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.
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.
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.
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.
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.
Free 30 minutes · no obligation
Related work
- Education / Internal SaaS
Little Lumos School Management Portal
Custom-built school management SaaS that automates end-to-end school operations
- AI Workflow Platform
Little Lumos — AI Monthly Progress Reports
A preschool was hand-writing 70+ monthly progress reports, costing 3–4 working days every month. Softivum built the full workflow: teachers speak, AI drafts, admins approve, and branded letters reach both parents with per-recipient delivery tracking.
- Food & Beverage / Internal SaaS
Pizza Theory POS
Custom POS and operations system: order to invoice in under 10 seconds, with a payment-gated kitchen queue and live order tracking