1000 Days to start a successful software company

by alex 1. February 2013 21:42

Hi. My name is Alex.

Yesterday, my 5-year tenure as an employee of a multinational automation company came to an end. I filled many roles within this company, from providing personalized customer support to designing scalable frameworks and reliable, secure applications. We deployed code to customers with strict availability requirements, where an hour of downtime could result in hundreds of thousands of dollars in immediate manufacturing losses.

I learned a lot about how to write good software: foundations that can be extended and customized to meet the forever changing needs of the customer; applications that can be updated and patched without fear of breaking unrelated functionality; frameworks with API that can be cheaply maintained to continue to support applications compiled against legacy versions.

But, I found that a very basic tool was not available.

The team had code repositories to audit changes and to unite the group's collective code; we had a build script to automate the compilation and versioning of the software products; and we had a wiki to house documentation. But we used a folder on a shared network drive to store our releases. We had no way to associate change logs with our releases - the notes always got lost or if we put them in zipped archives with the builds then they weren't searchable. Our builds - the result of our painstakingly crafted and fiercely debated source code -- were left to rot on a network drive.

We found some products that offered solutions, but they were cumbersome. Many required detailed configuration that was more complex than trying to use tar. Oftentimes the product required full control over the application life cycle management - our team would need to learn a new version control system, a new item tracker, and a new build process. These software packages have a tremendous start-up cost and a high cost of failure.

This is why I left my job.

We needed a low-cost, simple release manager. We needed a tool to collect release, associate change logs and migration details in a searchable way. We needed a tool to help us avoid DLL-hell and to help us navigate the web of inter-product dependencies. From these needs Ginger was created.

Today is Day One of my 1000-day software business experiment. I have a functional and stable product, exactly 1 customer, and $0 in revenue. My goal is to bring this product to market and sell enough licenses to keep the company going (I'll get into this later, but at the current product cost and my current budget, that works out to 36 licenses sold per year). If I am unable to market my product well or if I fail to meet the needs of my customers, then in 1000 days my capital will have been nearly depleted and my source code will go to the highest bidder or to the open source community.

Let's hope that doesn't happen.

This blog is a meta-blog about running the company. What went well? What was a bad idea? I want to tackle topics of business management, taxes, SEO, customer satisfaction, marketing and branding and much more. I will do my best to help other like-minded developers shed their aversion to marketing and sales by providing data about my direct financial gains and losses based on my choices, good or bad.

That's the goal anyway. I hope this effort will be informative or motivating to someone. However, my next post might be along the lines of "OMG, Anti Chamber is the coolest game ever!"

I promise to keep the LOL Cats to a minimum.


Add comment

  Country flag

  • Comment
  • Preview

About the author

Something about the author

Month List