Two years is a long time, especially when spent building a startup from the ground up. My most exciting professional adventure to date has reached its conclusion last month when I decided to pull the plug on Nouncer, my attempt at building a microblogging web service. The Nouncer story started with an idea and hunt for logo, evolved into a business with some general directions about a financial model, and materialized into a big chunk of code – 150,509 lines to be exact.
Navigating the Business
Nouncer wasn’t an easy idea to explain to people 2 years ago, especially since microblogging didn’t exist yet. Twitter, Jaiku, Pownce, and other services were introduced while Nouncer was being developed. The new services made it easier to explain and communicate the idea, but at the same time took away the first-to-market opportunity as well as added competition, and raised questions about the business plan. Ironically, at the same time I left my day job to work on Nouncer full time, Twitter exploded after a huge SXSW exposure.
As Twitter received more attention, clones showed up everywhere. My decision was not to compete with a new and already crowded space, but to find a different angle. I decided to focus on scalable technology, making a bet that once Twitter and others will get popular, there will be a real need for that kind of technology by other players.
While forgoing the plan to build a consumer facing application, I still planned to focus on the enterprise world where I spent my 10 years exile from the web community. I still believe that microblogging is going to mature and change the way corporations communicate internally and with clients. As a Vice President at Citigroup managing a team, I was forced to read over 500 emails a day, spending at least 2 hours every morning just catching up. My plan was to start working on a product for the enterprise as soon as the backend framework was complete.
The business decision to focus on technology and avoid building a consumer application had a significant impact. It meant throwing away 3 months worth of consultant work building a Perl-based website that interfaced with the backend database and engines, and provided a user interface. But the most significant change, which I did not appreciate until it was too late, was the fundamental shift in the nature of the startup. I moved from building a consumer-facing website to a combination of infrastructure provider and software developer which made the overhead cost much higher, time to market longer, and resources much more difficult to find.
A month ago, half way through my angel funds raised from family members, I decided to review the progress I’ve made and figure out what still needs to happen to make this a viable business. I was also actively pursuing raising VC funds with the help of a very talented and well connected friend. At the end, I asked myself what are the most critical resources I need to be successful and the answer was partners and developers. I’ve been looking for both for about a year and was unable to find the right people. I realized that money was not the issue.
To me, that implied that raising funds is not going to solve my problem. While it might make the startup more attractive for others to join, I failed at building a team. I also approached people I know and respect with a what-if scenario. I asked them if I raised $1M, will they join me. I got a wide range of ‘no’ reasons and was still at square one. There are plenty good reason why people would not leave a job, especially a high paying financial services job where most of my friends work. This is New York after all.
With half my angel funds in the bank, and a couple of really promising VC meetings, I made a decision that surprised most people, and pulled the plug. This was actually an easy decision because the fundamental facts were easy to understand. I had no reason to believe I’ll do a better job finding a team with more money, and I couldn’t have moved fast enough without a team. So I gave the money left back to my family who supported me (which after some tax planning will hopefully turn into a very small loss), and explained why I thought it was the better move for me and them.
Looking back, it is amazing how much impact small decisions have. Halfway through the project, right around the introduction of the Facebook platform, the work on Nouncer produced an interesting side project. It wasn’t a perfect fit for the Nouncer services, but still fit in with the overall strategy and philosophy. It also looked like an easy thing to do with a big marketing potential. The result was JabAbout, a Facebook application using the social graph to propagate short messages by following the friends-of-friends paths. JabAbout failed to build a user base and was eventually shutdown.
The financial and schedule impact JabAbout created wasn’t by itself dramatic, which doesn’t mean to say it wasn’t a big waste of time and money. But it happened at the same time I was reshaping the product and the business strategy, and the two efforts combined, while still coding Nouncer, was too much distraction. The lesson, of course, is not to get distracted trying to accomplish small wins. When the Facebook platform was announced, it was such a significant event, that not coming out with some application seemed to create a disadvantage.
This brings me back to the underlying problem – I didn’t have a partner to balance me out and provide sanity checks for business and technology decisions made. And there were plenty of those to review and debate. I didn’t start solo. A few months after I came up with the initial idea for Nouncer, I recruited two good friends to join me. The three of us formed a partnership with a simple agreement and divided the work between us. We were all fully employed at the time and could only dedicate a limited amount of time to the startup.
As is common in such cases, not everyone was able to contribute at the same level. My personal motivation for putting in hours of work late at night every day after coming back from the office was, well, not to go back to the office. I was trying to create a viable alternative to my day job. My friends and partners did not share my sentiment, at least not at the same level and after a month of discussions, decided to dissolve the partnership. We were extremely fortunate to be able to accomplish that with no impact to our friendship, and I retained full ownership and control over the code and other intellectual property created together.
The decision to move on alone wasn’t by itself wrong. I’ve set milestones and committed myself to finding new partners and completing parts of the system by certain dates. As is often the case in projects with no risk management or review process, every single milestone was either missed or changed. This did not result from lack of project management experience or understanding as I am actually a certified project manager, but was the result of having no one to counter my decisions, questions them, and provide feedback. My ability to talk myself into anything was playing against me.
When working on the initial concept behind Nouncer, what today we simply call microblogging, I immediately identified the need for massive scalability. In early conversation I was worried about overnight success shutting the service down for months while we tried to build it again to sustain the load. Messaging systems are not trivial and require a big investment in infrastructure, both software and hardware. This, together with my decade-long experience building and architecting high-volume high-frequency trading systems, led me to choose C++ as the language of choice.
The technology decision to use C++ was well founded. However, it failed to take into account, or at least prepare for the inevitable reality of being unable to find people to join me. Any major web company reaching massive scale eventually turns to C/C++ for performance. Given the fact that Nouncer had no competition at all when the idea was first conceived (and I am not claiming to have invented microblogging – only that I came up with the idea independently), I decided to take a little bit longer before launching to build a solid foundation. This, of course, turned up as a big mistake – but it is far from clear that I would have been first to market either way.
Many people criticize the typical path Web 2.0 applications take in their development: putting together a poorly executed site, gauging the market, and only upon success building the service to actually scale and accommodate the market. However, the cost of building scalability ahead of time is extremely high, and for most startup is cost prohibitive. The decision to turn Nouncer from a consumer service to an infrastructure provider forced a significant early investment that had very little change of materializing. It is the kind of project entrepreneurs get to work on once they have established their reputation and funding connections.
A close friend reading my early business presentation told me he liked it a lot but was worried about one line. He said it sounded like I’m building infrastructure and that is going to create problems with most investors. At the time I was focused on building a website and the comment didn’t register. Now with more perspective I can certainly appreciate the advice. While I still stand behind my technical decision to choose C++, it was the wrong business decision. I should have started with a dynamic language with wide community support and moved components to C++ as needed.
Figuring Out the Product
In my head, Nouncer always had a clear vision. Funny how that is not enough to get other people excited about your project. The greatest benefit of turning Nouncer from a consumer website to a backend API service was that I no longer needed to hire a great user interface designer or developer. The product was now a set of API calls and a document explaining how to use them. Amazon proved beyond any doubt that this is a valid and powerful business model, but very few companies can afford to build such a service and then wait for people to come. It also helps that Amazon did not start with the goal of providing these services, but identified an opportunity once their own retail infrastructure was in place.
When I finished the first alpha release of Nouncer, I was eager to get people to try it out and play with it. However, the lack of front end turned out to be a major obstacle. Most people need a working piece of code as a starting point and since all I had was a list of API calls, the learning curve was too steep and the product failed to inspire and excite its target audience.
Talking about Nouncer I was constantly shifting the product message focus. I made little changes to the software roadmap throughout the project, and had a pretty solid understanding of what needs to be built to support all the various plans I had for the product. But when talking about it, I focused on the particular implementation or use case I was most excited about that day. One day it was enterprise software, another it was helping small retail stores reach their local community, and sometimes it was a tool to enhance existing social networks. All of these use cases required the exact same framework, but not sticking with a single message created a lot of confusion about the product. To this day most people I talked to don’t really understand what I was building.
Dealing with Location
My fellow NextNYers are all too familiar with the constant debate if New York is the right place to start a web company. Like most people, I decided to start Nouncer in the New York area because this is where I live. It is one thing to relocate a family while maintaining job security, but a whole different matter when considering relocation with the uncertainty of startup life. It also took some time, almost a year, to appreciate the differences between Silicon Valley and Silicon Alley, and to realize that the kind of startup I wanted to build was not being enabled by my environment. This doesn’t mean you can’t build successful web companies in New York, a statement I found fundamentally wrong.
Very few technology companies can compete with Wall Street when it comes to offering cash to developers. The reality of the job market in New York dictates a higher cost for many technical and creative roles. There is also something to be said about the lack of startup culture which is all too common in the Bay Area. When people look for a job in New York, they look for established players where they can build their reputation and business network.
In my case, New York didn’t lack money, community, able workers, or smart people with good advice. It lacked the audience my product needed to succeed – the early adopters web hackers looking for the next cool toy to play with. I can count on one hand the number of people I’ve met in New York meetups and events that fit this description. In San Francisco one can find hacking events on a daily basis, as well as many unconference events where people get their hands dirty playing with code. This is a very specific audience dictated by my decision not to build a consumer product.
One of the early decisions I’ve made building Nouncer was to use as many open standards as possible. I found microformats and OpenID extremely appealing and wanted to incorporate them into the platform which introduced me to the communities working on these and other standards. There are plenty of companies working in this area making significant contribution to web standards, but for the most part, these are done as part of large standard organizations. The work I was interested in was all community-driven, and that community was mostly centered in the Bay Area.
There is nothing wrong with starting a tech startup in New York. In fact, it is one of the best places to do so. People constantly complain about the lack of talent, the inability to compete with banks, the non-existent “hardcore” tech community, and other nonsense. I used to do it myself. It is so much easier to blame the city than take a deep look at what you are doing and realize that not every business fits every locality. After all, the point of a business is to sell products, and if you the target market is elsewhere, the best talent and resources are not going to make a difference. It all boils down to understanding your business.
It Wasn’t All Bad
Actually, it was all good. Most startups fail – that is a fact. But while Nouncer failed to deliver a product and lost some money, it was an amazing adventure. I was fortunate to have the financial stability and family safety-net to do this for this long. There were many sacrifices from a much lower spending ability to family stress and uncertainty. But life working for my former employers had other problems, most importantly that I wasn’t happy. Nouncer also have the distinction of stopping when it made sense, not when it ran out of cash.
Working on Nouncer created my need for standards that were not readily available, a fact that got me involved in OAuth and joined the open standards community I had no chance of entering without, as well as the local entrepreneurs community. Rebuilding my professional network outside the financial services industry would not have been as successful or even possible without the context of attempting to build a startup. Two years ago I was practically unemployed outside the financial services industry which was more than happy to offer me the exact same role over and over again.
There are many lessons learned from this experience. I cannot point to any single mistake or error in judgment as the most important one, but I can point to a single positive lesson learned without hesitation – participation and contribution to the community, local and virtual alike. Working within a community yields more valuable return than any other investment. It is also what will eventually protect you more than anything else if your startup fails. The lack of business success will pale in comparison with the relationship and reputation you build.
My next adventure is going to be even more exciting, and would not have been possible without Nouncer. I would like to thank everyone who offered advice, listened to my pitches, reviewed documents, was there for me when I needed help or just someone to bounce ideas off. I wanted to list the names of people who’s help meant the world to me but the list is just too long, and that by itself fills my heart with happiness.
I want to thank everyone from the OAuth and NextNY communities – my two virtual homes. It is hard to explain just how much I have learned and enjoyed being part of these two amazing communities (and hope to continue). But most importantly, I want to thank my family for supporting me, believing in me, just being there for me, and suffering through it all with me when things were not so clear.
As for what’s next, well, stay tuned… it is really cool!