Selecting the right technology

I mentioned about the idea that I had for an application. Since an idea not executed, is just that, I was keen to at least test drive this idea. And that meant it had to be built.

If I was sitting on a pile of money, I would have hired a team that would have gone about building this app, dedicated to it. But since that was not the case, there were a few decisions that I had to make in selecting the technology.

There were a few criteria whatever the technology I select had to fulfill.

1. It has to be a lasting technology stack. I don't want to build a new app using a technology that is deprecated or on its way out. This application will be (hopefully) going through many iterations and improvements. And I don't want to be forced to do a complete ground up re-write anytime soon.
2. It has to be something that can be run on a shared or cheap hosting platform. It is not going to be launched in its own servers. I will have to bootstrap the operational costs for sometime and that means hosting has to be cheap.
3. It has to be easy to learn this technology stack or framework. The key reason being, since this is going to be built as a side project, I want to minimize the time spent learning a new technology rather than building the app.
4. It has to be cutting edge. This is a key requirement as as much as the solution, I am attracted to elegant and cutting edge solutions. I want this app to be a case book of good practices and cutting edge technologies.

There were two choices. RubyOnRails (RoR) and ASP.NET MVC.

I have been interested in RoR for quite sometime. I like it’s elegance and the design principles like convention over configuration. I think RoR is a great framework to build web apps. I wanted to learn this framework and move beyond the standard ToDo app that the learning examples provide.

Developing a real world application is a great way to master a new technology. And this would have been the perfect opportunity for me to master RoR.

BUT, I decided to take the ASP.NET MVC path instead. And my justification goes like this:

Developing with RoR will require a significant learning curve. While one may argue that RoR is really easy to learn, from my experience the caveats are hidden in little details. When you want to move beyond the standard example application that’s where the learning curve gets steep.

Secondly, I am not familiar with the hosting environment RoR requires. I am a little scared of Linux/Apache still. (Yup, I am a MS junkie)

Then there is S#arp Architecture (pronounced sharp). This is framework built by integrating some of the best open source frameworks and built on top of ASP.NET MVC. And it has a huge RoRness. So I am getting some benefits of RoR in a framework that I am already partly familiar with. My experience with nHibernate was also another force that pulled me towards S#arp.

So it is final, I am going to build my new app using S#arp and oh did I mention MySQL. Yeah, MySQL it is. Nothing beats free!

An idea keeps hounding me!!!

I am a man of ideas. I have a lot of ideas floating in my head, and most of the time, they remain just that, ideas. I am a dreamer, but when it comes to executing my ideas and giving them birth, I lag. I have a lot of applications, which I wanted to build, designed on paper, even some of them have a sort of an elevator pitch written. But they never saw the light of the day.

That is not necessarily a bad thing. When an idea takes root in my head, I would go ahead with the design and even envision how the final product would look like. Then I start to think about the monetization plan. I know there are some apps that gets built and takes the world by storm, without a clear idea of how they are going to make money in the long run. Twitter and Facebook are two such examples.

But keep in mind I live in Sri Lanka, not in the Silicon Valley. We have no Venture Capital scene here. So any idea that I decide to give birth to, has to be done with my own funding. That would mean for the most part, it will be my time. Time that I could otherwise use to earn money, in the short term. So unless I can figure out a way to make money, at least to cover the cost and investment, I am not going to last long or go very far. I will very quickly have to abandon the killer app and concentrate my time on working on billable hours to start paying the bills.

One such idea that I have had for sometime, an idea that I sketched into a notepad at that time, then it was eventually laid to rest, popped up in my head on Friday night, out of the blues. But this time, it had taken shape a bit more. Earlier, the idea was to build a sort of a portal offering this service. Now it had taken the shape of a service that can be offered through third party or the potential customers own web sites. This simple shift in the model, made that idea a whole lot more feasible and attractive. The earlier challenge was how to convince the customers to route their customers to our portal for this service. But now, that is no longer a necessity.

Also, a couple of years back, offering the service using the current model would have been really cumbersome and personally I was not aware or very fluent with the required technology. But though my recent assignments I have become conversant with a technology stack that makes it possible in an attractive and manageable way.

I have not worked out an exact monetization plan as yet, in terms of what exactly are the parameters of the service and what dollar amount to charge. But there is a very clear monetization plan, and a very flexible plan that can grow and fit a wide spectrum of customers.

Now the challenge is to build it. I have been scanning the technology stack and the what not and also sketching the software architecture over the weekend. In parallel I have started to realize the model in code. There is a lot to be done, but I am trying to follow a model of incrementally building an application that will grow based on the feedback. My systems architect mind is forcing me to think of all possibilities and design a system that incorporates everything. That is probably the way that the software was built for a long time. But it is also the ‘old way’.

Something I read recently on ‘Lean Startups’ lingers in my mind. There are essentially 4 questions to ask.

1. What should I build?
2. How should I build it?
3. What should I measure?
4. What should I optimize first?

And the answers:

1. ‘The Service’ (I am keeping the actual nature of the service under wraps until I am ready with a beta version).
2. There are some decisions made here. They will have definitely have a major impact on the projects success. I will discuss them in another post.
3. To be determined. I will be thinking of these when I get closer to the launch of the beta.
4. That will be based on what I find out under 3.

Finally, please say a prayer for me. I have left too many ideas and projects unfinished. And my sincere and feverish hope is that I find the determination to see this on through! I know it will mean a lot of sleepless nights and also balancing the expectations of my family and my current clients. Something has to be sacrificed, and I have a very strong feeling that it is going to be my sleep!

Technorati Tags: Start Up,Entreprenuership,Idea,e-business