Startup: A Long and Winding Road

It has been awhile since I wrote about my attempt at launching an Internet startup.    Things are progressing more slowly than hoped, but not for the expected reasons.   Obviously, creating a successful web app from scratch is challenging; however, the purely technical aspects are not, in themselves, the most problematic ones.     Seemingly, one can select a development stack, create a design, build it, then select a host, and voila!  It’s a startup.    Uh…not so fast.

In the time since I decided to jump into the startup realm, I have built a series of mini-projects (three to be exact), one of which even made it to a live-server for testing   So far, all worked as planned.  None were production quality, and each left me with a nagging sense of,  “It’s not quite what I had in mind.”   Each had conformed to my specifications, but once built, were lacking in some way.    This brought me back to the drawing board once more.   Having had time to mull over what caused my disquiet, briefly here is the wisdom I have gained so far:

  • Too much information, even if it is good, is indistinguishable from noise
  • Data stores deserve more consideration
  • Be sure everything in your junk mail folder is really junk
  • A good book is a wonderful thing

Too much information, even if it is good, is indistinguishable from noise
There is always something newer and shinier than whatever you are using.   An unexpected pitfall of being able to build from scratch is being able to choose any tools you want for development.   As Mr. Monk would say, “It’s a blessing and a curse.”

Language, framework, ORM, data store, cloud host, mobile vs web, JavaScript library, API… the number of possible combinations is bewildering and paralyzing, enabling the perfect setup for second guessing.    Knowing that each development stack permutation has its plusses and minuses only makes things worse.   Why? Because when faced with a problem that requires all sorts of contortions with one set of tools, and yet seems dirt simple with another, switching stacks seems reasonable (at least until the next switch-worthy issue arises). The downside of stack-angst is that whether or not a switch is made, time will be wasted evaluating alternatives.    I’ve gone down this road twice and not switched.   Perhaps this is one reason developers are so loyal to their development stacks—either learn to love the one you’re with (warts, hump, and all) or develop perpetual stack-envy.

The good news: I have settled on the final product feature set and stack.  The bad news: Shiny things show up in every third email, which brings me to data stores…

Data stores deserve more consideration
For most of my adult life, relational databases have been the main data store.   They made it to LANs and PCs early in my career and have dominated the industry ever since.   I have a certificate in database development, and actually find discussions of normalization interesting.   Like so many, when given a data storage problem, I tend to think in terms of relational designs.   Sometimes this means creating a complex schema and wonderfully brilliant queries to solve a problem (not that there is anything wrong with that).  However, sometimes I don’t want to be brilliant; I simply want to be finished.

When I began looking at NoSQL stores, it was simply out of curiosity (they are shinier than RDBMS).    After pouring over as much information as I could stand, I choose MongoDB, a document database, and Neo4j, a graph database, for evaluation.    Having used MongoDB (Investigating NoSQL for EHR Systems: MongoDB), I like the flexibility that it and JSON offer (Exchanging Data with JSON).  MongoDB is not a replacement for an RDBMS, but it definitely makes solving some types of problems easier.    Neo4J is on my laptop and will appear in a series of posts within a month or so.    So far, I like it!

Using NoSQL databases has allowed me to see how much my approach to solving data storage problems has been influenced by relational thinking.   Healthcare data are rich and diverse, and NoSQL tools offer additional flexibility in addressing clinical data management problems.

The good news: I now have a saw and a pair of pliers to supplement my relational hammer.  The bad news: There is another entire category of shiny things to play with.

Be sure everything  in your junk mail folder is really junk
From the time I began teaching graduate-level informatics courses, I have advised students to read outside materials.  Included in the suggested reading list are the Harvard Business Review (HBR), Business Week, and a few other business and technical journals.    This has helped me as well.   Two topics that have been great food for thought are blue oceans and long tails.   Both of these topics found their way into my junk mail, which I usually delete en masse.   The odd titles made me read them.  An article on blue oceans?  Isn’t that pointing out the obvious?  And long tails…well.    As it turns out, both concepts have made me consider new ways of generating revenue in the internet-age.

The good news:  I have identified a few new  approaches to turning my ideas into income. The bad news: I get a lot of junk mail.

A good book is a wonderful thing
A medical school classmate told me that I once said, “An intelligent person can learn just about anything from a good book.”   This had more to do with hating lectures than trying to be clever.   I could never understand why I should spend an hour listening to a lecture when everything being said was available, in greater detail, in a book. A well-written book can fill in a lot of gaps quickly.   When faced with learning anything sufficiently complex, I start by looking for a good book.

My search for startup advice ended successfully with two great books, which I recommend –The Startup Owners Manual by Steve Blank and Bob Dorf and Starting a Tech Business: A Practical Guide for Anyone Creating or Designing Applications or Software.    Both books are brimming with practical information that can be put to immediate use.   The Blank book focuses on techniques that help to build a customer base and market share.  Cowen addresses the stages of product design and development.  There is little overlap in content between the two.   Fortunately, I found them before wasting too much time.  Both  books have helped me in terms of pointing me to resources (Blank offers a MOOC on Udacity) and convincing me of the need to keep my business plan dynamic by continually revisiting my underlying assumptions.

The good news: Even though the project is behind schedule, it seems to be on the right track.   The bad news:  The project is behind schedule.

See you next week…



Leave a Reply

Your email address will not be published. Required fields are marked *