Building a startup is hard work. Especially when you are going it alone. I am no genius. Neither am I omnipotent. So PomsApp went into hiatus. From September 2011 to April 2012.

One thing I am not afraid to do is share my ideas openly without fear of ridicule, pity, or idea-theft. My philosophy is if I share my idea, you have it too – and that is a good thing. So it stayed on my blog. No one seems to have built a similar system. There may or may not be a market for a purchase order managment system as a Saas application. We will see in a short while. But simply by being out there on the blog, I’m already getting first page results on google for relevant keywords! And starting from this blog post, I’m going to link Purchase Orders and all relevant keywords to http://www.pomsapp.com

Destiny calls: Given that I get hits on google for keywords related to POs, it does make sense to go ahead and build PomsApp. So I have teamed up with Sam. We are going to build this together. For PomsApp, I don’t have pipe dreams of billions or even several millions flowing in. In fact, during the public beta the product will be free. After that the tiers may be $10, $20, and $30 per month. Unless we can get companies to shell out $100 per month. That will be awesome, but I am happy with 10. Plus Sam and I are both approaching this as a learning exercise.

Getting started: Sam and I have worked on this for a month now. We are not in a hurry yet. We are only doing this in our free time. But already we have the basics set up. No, we did not get it all right. We made some mistakes already, but that is a good thing. It means we have made some decisions along the way. And making decisions every day is very important in a start-up. And the great thing is, once we realize our mistakes we can make better decisions that avoid, replace or fix those mistakes in the future. I don’t like starting a sentence with “and” either, but some mistakes are good to make and get over, even if I repeat them, because they will not get in the way.

Customer experience: I have not got any feedback on the workflow or structure of PomsApp, so I cannot assume it is right or wrong. I am going to actively try to validate the workflow and features by asking members of the purchasing community. I’ll do this because I believe it is very important to start with the customer experience in mind, not build something and try to figure out a way to sell it. In my next post, or thereabouts, I will write up the design I have so far. The design is by no means going to be like PO software that is in existence in many companies. It will be a departure from tradition. But it will also be one that my customers will love.

Why we will create PomsApp: We will build and deploy PomsApp, not because it is easy, but because it is hard. We will make it a product that small companies will love to use, not because it is cheap, but because it is right. We have this goal, because this goal will force us to do things we have not done before, this challenge will stretch the limits of our abilities, and if we succeed in this mission, it will give us the right to say, “I climbed that mountain too.‘ (pun intended – check the link)

What we have so far

Progress has been steady. Just the way we like it. We are both dedicated to its success, our learning, and a product that our customers will love. Given that, here are some of the decisions we have made. They we not made in this order, I’m just writing it that way.

Ruby: We thought long and hard about what language to use for the web part. We finally decided to use Ruby. We are both new to Ruby. But that is what makes it better. Plus, ruby is really the best language available today for this anyway (other than Python.) Ruby’s focus is on simplicity and productivity.

Sinatra: Naturally, Rails tried to butt in. Yes, rails is very organized, but it is complex. It has even succeeded to assimilate Merb which tried to be a simpler alternative to Rails. But if you get anything from the title of my blog, I like Simple Solutions. When Sam researched and suggested Sinatra as the simple alternative to rails, I was sold.

Redis: Any good web application needs a database. The wold is moving towards nosql dbs. After all DB2 – the first RDBMS is older than me. We decided to go with nosql as well. We considered the rich and famous – casandra, mongo, couch, whatnot, etc. We also considered other newcomers. We finally decided on redis. Again, simplicity was the deciding factor. In addition, redis was clean. Squeaky clean. It is in-memory with an option to persist everything.

Data Mapper: Redis, though simple and squeaky clean, has not been field tested much yet. Apparently, it is not yet production ready. But we liked it. So enter data_mapper. Data Mapper is an ORM - basically an abstraction to database functions. DM has adapters for most of the popular databases. Fortunately, DM also has an adapter for Redis. (We have found a bug in the adapter. Sam has developed a fix for the bug and will be pushing it to github soon.) The advantage that DM provides with its redis adapter, is that we can code for DM now and use the redis key store (just think of it as another name for database). If we decide later that redis will not work for us, we can quickly switch to mysql or sqlite with very little effort.

Haml: This is html for Ruby. Writing html and erb is almost like writing assembly. Haml is a higher level abstraction for the same thing. The advantage it offers us is a visual sense of hierarchy enforced by mandatory indentation. Their official site says that haml is based on the principle that markup should be beautiful. Yes, haml looks beautiful. I still find it hard to write. In fact I generate much of the initial haml with a converter. After the initial part is done, it is much faster to edit.

Sass: Right in the heels of haml, it is very appropriate to mention sass. Sass does to css what haml does to html. Sass can be considered like a compiler that takes a sass program and generates css – much like a C compiler takes C code and compiles it to object code. Sass is a god send. We did evaluate compass and blueprint, but decided sass plus yui are better for us – simpler.

YUI3: Yahoo User Interface library. It is an open source framework for java script and css. We chose it over jQuery for JS, and over blueprint, 960 grid, yaml, etc for CSS. It is both simple and intuitive. Also well supported by yahoo. And there is a good gallery of widgets.

Amazon: Which start up worth their name hosts their own servers? None. When Amazon’s EC2 goes down, all the start ups go down. We like that bandwagon. We briefly considered Google’s app engine and Microsoft’s Azure.

Customer Support: I considered several customer support engines. Freshdesk was the one I liked most. Not just because the product is very well done, but also because it was built by a few guys from Chennai – my hometown. We already have a fully functional support site, thanks to Freshdesk.

Development Infrastructure and tools:

1. Private Wiki:Google sites
2. Project Mangement:Basecamp. We have not started using it actively yet. We are able to get by with email.
3. Defect tracking: Not needed it yet. But will probably use bugherd considering this is a web app and bugherd is built for web apps. We will evaluate it for a while and decide whether to stay with it or switch.
4. Git repository:Assembla
5. Text editors: Depending on the computers and OS we have used these so far – Text Wrangler, vi, vim, emacs, sublime text 2, text edit, even notepad and some editors offered by scp clients!