Posted on

Platforms and Verticals—What to Build on and for Whom

An important decision is about development and deployment platforms. If your product is targeted for a specific operating system, the choice is obvious. When the solution has to be platform neutral, or if the deployment will be controlled by you (SaaS model), then the common options are Open Source (Linux) and Java or Microsoft Windows. Always keep in mind the Total Cost of Ownership (TCO) for the customer.

Open source in theory benefits from the availability of a huge number of re-usable components and tools contributed by an army of individual programmers. While open source is technically free, limited support and inter-operability between different open source products may lead to higher cost of development and support.

Microsoft now offers free development tools to start-ups for 3 years under their BizSpark program, but licensing cost of servers and other software for product deployment, may be high.
Other issues may impact platform choice. An implementation which is tightly integrated with specific platform features and interfaces will limit your ability to go cross-platform. Conversely, leveraging the tight integration and inter-oper-ability of various servers on a specific OS can substantially increase the product’s value and ease of use.

Web 2.0 ventures and CIOs have new options to develop applications with minimal investment. Salesforce.com is promoting the platform-as-a-service (PaaS) concept, which it says represents the start of Web 3.0. Called Force.com, it enables companies to build and deploy enterprise applications on-demand without having their own infrastructure. Core business applications, such as enterprise resource planning (ERP), human resource management (HRM) and supply chain management (SCM), can be developed in just 5-10% of the time that is normally required for custom development, and deployed almost instantly.

Your OS decision should be driven by business potential. If a specific platform dominates or is acceptable to a majority of your potential buyers, then opt for it. Spend your engineering bandwidth on providing maximum compatibility and inter-operability with other applications on this OS, to improve total value to clients.

Posted on

Platform Play Versus Product Play in an Indian Scenario-Part 1

From the beginning, we at Ozonetel had always wanted to build a platform. Initially, we did a VXML platform with off the shelf hardware. But VXML was not sexy enough and there were not a lot of takers. So in 2010, we did a pivot and built our own custom hardware( PRI cards) and built KooKoo and top of it. KooKoo was our attempt at Telephony Platform as a Service play. Once KooKoo was opened to the developers it took off and we got good traction. A lot of innovative telephony apps were built on top of KooKoo and telephony became cool again.
After 6-8 months, we started to think about building products and do a product play. A couple of things influenced our decision to do a product play. First was that though innovative telephony apps like connecting experts, water alerts, appointment reminders etc were being built on KooKoo, core telephony apps like PBX systems and call centers were not being built and there was a huge market opportunity. Second was that, being a bootstrapped company, market forces made us to look at alternative sources of revenue as the customer turnaround time in a platform play is longer. They have to first build their apps, market them, make money and then only they pay us 🙂
So with that, we separated out a product team in Ozonetel who would go on to build two core telephony products, a PBX on the cloud called asBizPhone and a full featured cloud call center product called as Cloudagent. So now that I have seen both the scenarios of a platform play and a product play, I thought I would share some pointers in both(no particular order).
Platform Play:
  1. Patience: You should have a lot of patience. Developers will take their own sweet time in building the application and marketing it. Many times, you will want to get in and help them develop. But that is not scalable. Though it will take time, it is better for them to figure out the solutions on their own as in the long run that will mean lesser support.
  2. Documentation: This is the most important part. You wont believe the amount of support calls that are reduced by having some decent documentation. Unfortunately, this is one area where we still have to improve and thats why we still get support calls.
  3. Logging: Your platform should explain what is happening behind the scenes to the developer through logs. It will help them in debugging the issue themselves before they reach out to support.
  4. API: Think through what and how you want to expose your API. Because, once you open it to the public and they start using it, it will be really hard to take back and you will end up supporting multiple versions.
  5. Evangelize: You should have a team of evangelists who should go to events, do live coding, help hacking communities etc to drive adoption. This is the hardest part, convincing developers to invest their time in learning your platform. It is much harder in India as the hacker community is in a nascent stage(though growing very very well).
  6. Star products: Every platform should have some star performers. They are the ones which will help in people believing in your product. Identify your star products and put all your efforts in making sure they succeed.
  7. Mashups and Blog: Build mashups on your platform yourself to showcase the capabilities. You know your platform best, so you will have to build very innovative and fun apps. After building mashups, blog about them and spread the word. Again, in India, its hard to build mashups with content from an Indian context. Till last year, we did not have a lot of APIs for Indian content. But now a lot of companies like Zomato have started opening up APIs and phone mashups can easily be built.
  8. Support: This will make or break your platform. Developers have very little patience. If they send a mail to support, they better get a response within 5-10 minutes. Otherwise, they will end up Googling for another platform which will solve their platform. Luckily, so far at least we have been able to keep our developers happy with our support. Support does not just mean technical support. Many times we have actually had to mentor a lot of startups building on our platform. You should be willing to listen to their problems and suggest advice if you have any.
  9. Developer events: You should conduct developer events and hackathons so that the new developers get to know about your platform. Unfortunately, being bootstrapped, we have not yet had funds to do this 🙂
  10. Sponsor events: In addition to conducting events, another way of getting mindshare of developers is to sponsor events. We are continuous sponsors of Startup Weekend events in India and have also sponsored hackathons in colleges like BITS where students have built very innovative applications.
In the next part I will discuss my observations on the product play.