SPIRIT — Accessible Matrimony & Social Platform for Persons with Disabilities
A matrimony platform where accessibility isn't a compliance checkbox — it's the reason the product exists.
Matrimony platforms are built for a default user who can see the photos, hear the voice notes, read dense profile text at small sizes, and operate a fiddly interface with precise touch. For persons with disabilities, that excludes people from one of the most personal things software mediates. And the exclusion isn't one problem — a low-vision user, a colour-blind user, a screen-reader user, a Deaf user, and a user with limited motor control each need something different, sometimes conflicting. Bolting an accessibility mode onto a finished product doesn't solve it, because the information architecture, the colour system and the interaction model all had to account for it from the start. There's also a real privacy dimension: disability details are among the most sensitive information a person can put on a profile, and how they're stored, shown and consented to matters more here than on any general dating platform.
A Django REST backend and Flutter client designed around five disability categories — visual, auditory, speech, learning and cognitive, and physical — with accessibility treated as the product's core differentiator rather than a settings page. The design system was built token-first from Material 3, with multiple visual modes including high contrast and black-and-white for colour blindness, each available in both light and dark themes, and scalable text throughout. Per-user accessibility settings are a first-class model, not a preferences blob. Disability details and partner preferences are separate models from the base profile, with explicit privacy-policy consent recorded, so what's disclosed is a deliberate act rather than a side effect of signing up. The platform is hybrid matrimony and social: alongside matching there's a feed with posts, comments and likes, and real-time chat over Channels, because a community is what makes a matrimony platform usable rather than transactional. Subscriptions and payment transactions support the business model. Security was specified up front rather than retrofitted — OTP request throttling per phone and email, login attempt limits with lockout, short-lived JWT access tokens with refresh, device attestation via Play Integrity and DeviceCheck, and server-side signature verification on payment webhooks.
Outcome
A complete, endpoint-tested REST API across fifteen API groups, considered stable enough to build clients against, with the Flutter app's development path finalised against it. Documented end to end — accessibility specification covering all five disability types and their distinct requirements, entity-relationship and data-flow diagrams, API documentation, Figma mockups, and a running project log. The accessibility work went through review and a deliberate mid-project pivot, when the initial design-system focus was redirected toward the five disability types that actually define the product.
Key features
- Accessibility settings as a first-class per-user model, spanning five disability categories
- Multiple visual modes — normal, high contrast, and black-and-white for colour blindness — in both light and dark themes
- Scalable text and screen-reader compatibility targeting JAWS, NVDA and VoiceOver
- Token-based design system built on Material 3, with a shared component library
- Disability details and partner preferences held separately from the base profile
- Explicit privacy-policy consent recorded per user
- Matching engine with partner preference criteria
- Social feed with posts, comments and likes alongside matrimony features
- Real-time chat over Django Channels
- Subscriptions with payment transaction records and webhook signature verification
- OTP throttling per phone and email, and login lockout after repeated failures
- Two-factor authentication
- Short-lived JWT access tokens with refresh rotation
- Mobile device attestation via Play Integrity and DeviceCheck
- Admin accounts with an action log
- Dockerised deployment with Compose
Tech stack
Build something similar?
Tell us about your project. We'll share how we'd approach it.
Start a project
