Die, Matrimonial PHP Scripts!

Our B2B beta is live at BureauBuilder! BureauBuilder is Shopify for online matrimony.

BureauBuilder provides a SaaS alternative to self-hosted PHP Scripts that are commonly used to set up online marriage bureaus or matchmaking websites.


Next up: making online matrimony more transparent

Update (15 Oct 2013): Our landing page is up! Welcome to TrustedRishta.com.

We've been fascinated by relationships and marriage in the Indian context for several years now. So when we decided to do a new product a couple of months ago, we started researching this space to understand if there were any major pain points that a startup could address.

Let me quickly summarize for you what we learned.

  • Indian weddings create an industry worth $38 Billion annually
  • Matrimony in India has four distinct verticals (the first two don't exist in the west to the best of my knowledge)
    1. Discovery: I need to find matches for my son/daughter (driven almost exclusively by parents)
    2. Verification: Is this a good match? (handled by the so called "aunty networks" and private detectives, with Facebook/LinkedIn research slowly on the rise)
    3. Retail: Where do I buy stuff for this wedding?
    4. Operations/Event Management: What do I need done for the event?
  • Only the discovery vertical has gone online in a big way (shaadi.com, bharatmatrimony.com), functions pretty much like any online classifieds service (no algorithm based matching etc.), has less than 20% market penetration, generates ~$100 Million in revenue and is growing at a phenomenal 30% year on year
  • Like almost any other similar space in India (like jobs), misrepresentation of facts is rife leading to a 30% year on year growth in matrimony focussed detective agencies and a substantial rise in divorce rates as reported by the BBC and the Economic Times.

So for us, the big, unaddressed need of the matrimony market lies in the verification stage. Indians depend on a family based trust network to achieve goals and make important decisions. Marriage, expensive purchases like real estate and cars, finding jobs, hiring - all this and more has traditionally depended on a close, tight knit network of family members.

As people migrate to the cities in incredible numbers, these networks are breaking down. We suspect that re-establishing these ties of family and friends and re-building the trust network using digital tools is the way forward.

If anyone can nail verification using such a network, they can easily expand out into discovery. But the reverse isn't necessarily true.

Personally, I think anyone contemplating marriage needs all the information about their prospective better halves they can get. The most effective approach to this is to spend time together. Lots of time. Years.

However, across the 60 or so people we polled, a few facts popped up consistently irrespective of community, caste or religion. All those we spoke to were middle/upper-middle class, most had masters degrees from top Universities, all used the internet and had Facebook accounts.

  • The discovery stage is driven entirely by parents
  • Facts available at this stage typically include a few carefully curated photos, age, community, caste, horoscope, and salary
  • Typical workflow followed by a family looking to find a match for a son/daughter:
    1. Generate a lead through offline/online matrimony bureaus or "aunty networks"
    2. Initial filtration based on community, caste, salary, height, address, skin colour (oh yeah, that happens), general appearance and horoscope (if available)
    3. Ask around to find out more about the family's financial health and general reputation; if possible, have a trusted friend or relative visit the address supplied with the lead and make enquires in the neighbourhood about the family
    4. The head of the families call one-another and chat; a meeting is set up
    5. The families meet; the man and woman that are the subject of the meeting get to talk to each other in private for a couple of hours
    6. Over the next couple of days, the two families separately decide if they'd like to proceed
    7. If it's a green signal from both families, the engagement is announced and the shopping begins
  • The people getting married restrict themselves to a veto on leads generated by parents that they find unattractive but otherwise prefer to stay uninvolved until they have to meet the other party
  • Communication between the prospective groom and bride before a formal engagement is prohibited (but encouraged after)
  • Average number of proposals considered seriously before a match is found : 4
  • Average time from discovery to meeting: 2 weeks
  • Average time after meeting for one family to give a yes/no answer to the other: 3 days (asking for a second meeting is rare)
  • Average time after a "yes" answer to a public commitment ceremony (like an engagement): 1 month
  • Average time from engagement to the wedding: 4 months

In other words, things move quickly. The people getting married don't have even days to get to know one another before making a commitment, leave alone months or years. This is an even greater pain point for the bride as the typical Indian couple moves into the groom's parents house, so the bride's family worry a great deal about not just the groom, but also the personality and background of the groom's parents.

A family in this situation has just two choices when it comes to verification: ask around, or (very rarely) hire a detective. Worse, they only have a few days to do this.

This is the problem we're going to take a stab at. We want to make "asking around" enormously powerful by building it on top of existing networks like Facebook (80M users in India) and LinkedIn (20M users in India). We want to make it quick, cheap and painless to find out how one family is connected to another through friends or relatives. We want to collate and organize the substantial amount of publicly available information so that families can make decisions quickly and effectively.

We should have an alpha out in a few weeks and start figuring out which of our hypotheses are correct and which aren't. With luck, we'll have a market and a real need we can build a product for.

If you or someone in your family is looking out for a match through traditional channels, please do consider helping us by signing up as an alpha customer. We'll be deeply grateful.

Find The Thing You're Most Passionate About, Then Do It On Weekdays And Weekends For The Rest Of Your Life

The Onion just published a post that satirizes the desire to chase one's passion while being stuck doing something else for a living.

I've re-written a portion of it from the other side as an experiment, just to see how much greener the grass really is.

Turns out it doesn't read all that differently. See if you can spot the differences.

I have always been a big proponent of following your heart and doing exactly what you want to do. It sounds so simple, right? But there are people who spend years — decades, even — trying to find a true sense of purpose for themselves. My advice? Just find the thing you enjoy doing more than anything else, your one true passion, figure out how you can make a living from it and do it for the rest of your life, every day and even on nights and weekends, because making money from your passion is hard work. When you’re exhausted and cranky and just want to go to bed, you go back and work some more, because that's what it takes to keep your head above water.

It could be anything — music, writing, drawing, acting, teaching — it really doesn’t matter. All that matters is that once you know what you want to do, you dive in a full 100 percent and set aside a small amount of your time for the luxury of self-pity because you know that without luck it’s unlikely to give you a steady income, allow you to buy a house, afford decent healthcare and send your kids to college.

Is there any other way to live?

I can’t stress this enough: Do what you love... in between family commitments, and commitments that tend to pop up and take immediate precedence over doing the thing you love, and things you may not enjoy but have to get good at so you can continue do what you love. Because the bottom line is that life is short, and you owe it to yourself to spend the majority of it giving yourself wholly and completely to something you absolutely love, doing what you feel you were put on this earth to do.

Object Oriented Javascript for views

This is a mail that I recently sent out internally that I thought might be useful to a larger audience. I haven't polished it much, so it's rather specific to the context of this particular project.

Here are a few rules of thumb that I've come up with over the years for simple client side javascript - i.e. your typical web application that is not a GMail style single page app, but still requires fairly complex js for some areas and routinely uses AJAX. Much of it would still apply even within a framework like backbone.js but YMMV.

General:

  • Always use a namespace
  • No free standing functions, always use objects
  • _.extend or $.extend copy functions, they don't do inheritance
    • Understand when a function is a function and when it is a constructor and how a prototype chain works
  • Never use anonymous callbacks (unless it's a truly trivial usage), always bind to a method of an object
  • Use utilities and libraries that don't do "this" hacks as far as possible. Thus prefer _.each over $.each
  • Understand scoping. You have exactly two choices to manage "this" correctly (and don't mix them)
    • Any function that in turn uses anonymous functions (for, say, iteration) should set "var self = this" in the first line as a closure based hack to reduce ambiguity
    • Any function that need to be called later (like an event handler) should use _.bind to set "this" correctly
  • All objects have an "initialize" method as a convention that is invoked in the last line of the constructor
  • The constructor just assigns values, any complicated state setup is carried out in initialize
  • Test drive everything except methods that affect the DOM

View code:

  • You are writing rich client view code. All of this has been done over and over again in the '90s. Go read up the patterns that emerged instead of re-inventing the wheel. The observer and decorator patterns are especially important.
  • All ViewModels accept one target (or wrapper) dom element. It will eventually render itself into this.
  • All ViewModels have a template that adheres to a structure that is also a contract. The ViewModel will render this template as its viewElement, and append it to the target when appropriate. The ViewModel can look up sub elements within its template based on selectors, hence the need for a standard structure-as-contract.
  • $("selector") or domElement.find is only permitted in the initialize method. No dom lookups anywhere else.
  • ViewModels always use a template library like Mustache. Never hand-roll your DOM, it gets brittle and hard to maintain.
  • All dom related lookups should work perfectly without it being appended to the browser dom (ie without render() being called)
    • This allows render to be stubbed without the object breaking (as in, the object is perfectly valid without having to be rendered first) so TDD is easy
    • This also means that you don't need shared view fixtures for specs
  • render() simply appends the objects viewElement to its wrapper (or target) element
  • Never tunnel data through the Dom. No looking up links from hrefs (it's ok to have them for usability though, but don't depend on them). Definitely no custom data attributes. Everything comes through the constructor or from an ajax API call.

Custom events:

  • jQuery's eventing is pretty nice, and works for custom events on non-dom elements. You can decorate any object like so $({}) and that object can now have events registered and triggered on it.
  • Avoid binding and triggering events on global variables like "document" or "window" unless it's absolutely necessary.
  • Every object that publishes events should have a registerForFoo() and notifyFoo() pair of methods for every event. Internally, this should delegate to jQuery's events. This keeps the string based event keys internal to the observable object.
  • Follow a clear, consistent naming convention for everything event related, both event keys as well as method names.
  • Like so much else in jQuery, the APIs to manage event payloads are different for on and trigger