Archive for the ‘Business Development’ Category

Network

Saturday, June 28th, 2014

Silicon valley is generally considered by most as the best place to build a technology company, due to the large concentration of talent and capital, unmatched anywhere else in the world at that scale. But it's the valley's dirty little secret that it's really the network of people that make it all happen.

Every successful person in the SV tech scene is highly connected to talent and capital through their network. It is that network that makes seemingly random M&A deals, capital investments or recruiting top talent happen on a daily basis. And it's that network, more than anything else, that makes Silicon Valley so special for building high-growth companies.

Why a network is important

I've recently found myself quite often advising founders who are new to the valley or are thinking of moving there. The most common questions generally revolve around how to raise money. I've already collected my thoughts and experience on the topic of raising a seed round, so I have a few prepared answers, but in person I'm definitely putting much more emphasis on network building compared to everything else.
(more…)

Solving the wrong problems

Wednesday, October 17th, 2012

As a power user and an entrepreneur (not to mention a developer), I often look at a software product or service and think how I would've done it differently. If the concept is interesting enough, I might dive into some initial research to understand the market and the needs of the target audience.

Most often the process stops at that point as I realize that -

  • The product is not as simple as it seems on the surface,
  • There are reasons it is built the way it is, which were not immediately apparent,
  • There is already strong competition in that space

I went through a similar progression when I came up with the idea for my startup, Binpress. I had just finished yet another client project rather quickly, thanks for the most part to the mature code-base I've been building for several projects up to that point. I was thinking to myself - instead of continuing to provide custom development for one project at a time, wouldn't it be more efficient to just license the code stack I've been using as reusable components?

That was the initial idea, anyway. From there it grew to an idea of building a marketplace for developers to do the same, with the major competition at the time being codecanyon. The reason I felt codecanyon were "doing it wrong", is that they focused on low-end, low-cost components mainly for designers and beginning developers, without any kind of quality control. They did seem to be making significant revenue (I scraped all their sales data and I can say with confidence it is significant).

Understand first, build later

Alright, so why am I bringing this up now, and how does it relate to the title of the post?

The research process I went through when I decided to build Binpress took close to a month. I used codecanyon for a while as a publisher and sought out additional similar services. I talked with freelance developers and codecanyon sellers, gathering as much insight as I could. The goal was to understand why codecanyon was built the way it is, and if my take on it is valid.

Not everyone shares the same process - I just read a blog post on a new service called Gitiosk, which is termed "Building a Binpress challenger in 48 hours". In it, the team explains why they think it is better than Binpress -

  • It is not a marketplace
  • They don't do any marketing for you
  • No review process or quality control
  • You basically sell your code yourself

Basically, they looked at all the main value points of  Binpress and decided they are expendable. As someone noted in a HN thread on the blog post, the value offered by such services is everything but the actual sale. There is marketing and reach, which is difficult for everyone and developers especially suck at it, there is licensing which is difficult and confusing and you better have some legal authority, there are conversion and trust issues with prospective clients, if your code component costs something significant (we have components on Binpress that sell up to 1500$), or even if it costs at all - don't underestimate the barrier of getting someone to hand over his credit-card details online.

We solved all of those problems (through a long, iterative process), and despite the opinion of the commentator on HN, we did take off - since the value of quality, ready-to-use code is not zero as he suggests (a surprising viewpoint). Gitiosk looked at the same market and decided to solve a very different problem. In my opinion, as someone with close to 2 years of experience with this market, they solved the wrong problems - and it's probably only because they didn't understand it enough.

On the bright side, it did take only 48 hours for a team of 4, so no major time loss there. Time will tell if their approach is better than ours (though I feel we already made our point, with many developers making a living from being Binpress publishers).

 

Suggestion to Twitter: Here’s how you monetize without ruining your ecosystem

Saturday, September 1st, 2012

As you probably heard, Twitter recently tightened the noose around API developers with new limits and restrictions. Twitter is possibly the biggest public API provider today, with 13 billion API calls a day in 2011. This makes sense if you're Twitter, and are trying to increase your revenue from ad sales - you need people on your site, consuming those ads, not using API apps to consume their feed indirectly. At the same time, they reduce their biggest cost - supporting their API infrastructure.

But if I were Twitter, I'd go about it a different way - why put hard limits when you can just add tax instead? charge a small amount for every API request over the limit (or sell bulk packages) - suddenly you have a major revenue stream, and API developers still get a chance to scale using your API.

Soft cap vs. Hard cap

If you're into sports, this is somewhat similar to the difference between the salary cap system implemented in the NFL vs. the one implemented in the NBA. The NFL has a hard cap, which means teams have to stay under a specific total number for player salaries at all times. The NBA on the other hand, has a soft cap, which allows teams to exceed the cap number by paying increasingly larger tax for every dollar spent over the cap.

Both of those cap system exist as an attempt to create competitive parity in those leagues, by preventing teams from bigger markets outspending teams from smaller markets. Each has its own merits in the context of sports competitiveness, but in Twitter's case there is no reason for a hard cap at all. What does Twitter gain by putting a hard limit on API usage?

(more…)

Building an app does not make you a startup

Thursday, August 16th, 2012

I just read Andrew Chen's Mobile app startups are failing like it’s 1999. He raises a good point about the closed nature of mobile app development, which for the most part is a reflection of the Apple way of doing things and especially the appstore review process.

Most software products are not a billion dollar business

Before I touch on how that process can be improved, I want to talk about what I see as the core problem here - many of those VC backed apps, are not in fact, startups. They are startups in the old-school sense, in that they are a new business starting up, however they are not what VCs are claiming they want to back - in short, they are not appropriate for VC funding.

Once you take VC money, the game and expectations change completely, and the vast majority of those failed mobile "startups" never had any chance of living up to those expectations in the first place. Some of those actually have decent launches in relative terms, if they were considered as normal software products and not as startups that were hailed as the "next big thing". If they had just raised regular funding, via friends and family, loans and personal funds, they could have been a nice small business that generates a decent revenue stream for their founders.

As it stands though, with VC money, those apps will be considered a failure, which is too bad. The mobile trend, just like any other funding trend (social, local, offers etc), makes VCs take a leap of faith and buy into the dreamy future the creators of those apps are painting, while in fact they are just building regular software that is derivative of existing products with a small, fairly insignificant twist. There are exceptions, but most of the apps I see founded leave me wondering how someone can consider them a possible billion dollar business.

In fact, I'd go further and say that the fact those founders have no initial product actually helps them raise - as it's easier to sell dreams than reality. I have a post coming up on that exact topic, which I call the funding paradox.

Reducing costs and time to market

What can do we do to combine the agility we learned in the past decade with the requirements of the App Store?

Back to the original point of Andrew's article - lack of agility and relatively high time to market in the mobile space. This problem is not unique to mobile and many software products have this process - despite the introduction of more agile development models in the last couple of decades.

I co-founded my current startup, Binpress, to counter that exact problem. While each app has its own concept and core features that are unique to it, the fact of the matter is that many features are shared across apps. Things like in-app notifications, sharing options, review reminders, UI elements and so forth - are developed from scratch at each company. Those are solved problems that do not need to be developed over and over again.

At Binpress we build a curated inventory of code components for any development vertical, including mobile apps (our fastest growing category right now). We are a marketplace and a discovery tool for free and commercial mature code solutions that solve common needs in software development.

Our main goal in building such a service is to promote code sharing as a business that improves the software industry as a whole. There's no need for every app dev team to build their own solutions for everything, when much of it has already been done to death before. You waste time and money building it, and you waste time and money debugging and QA'ing it, when mature solutions are already available.

I like to make the analogy to car manufacturing which is a mature market compared to software development. Consider that no car company makes their own wheels, or their own screws, and some don't even make their own engines. They focus on designing cars that best integrate those various components which are built by companies that are experts at it.

I am convinced that this kind of component-based development is the future of the software industry. Cherry pick mature solutions to fill out necessary but not unique core features, shorten your development cycle and concentrate on the unique value your product delivers to your target audience. It's really a no brainer.

Check out Binpress and let me know what you think is the solution to the app development life-cycle.

 

Don’t Mix Business And Personal – Why Facebook Comments Is A Bad Idea For Your Site

Wednesday, August 15th, 2012

I like to leave comments on articles and blog posts I find interesting, and interact with the author. However, if the only option to leave a comment is through Facebook comments, I probably won't use it for the following reasons:

  • My professional persona is separate from my personal persona. I don't want my friends and family reading my comments on "How To Make A Two-Sided Business, One-Sided". It's not relevant for them, and I'd like to keep my feed clean of those messages.
  • I don't want people I interact with for business / professional reasons to view or connect to my Facebook profile. I have a linkedIn profile for those purposes.
  • I have no idea if the author is notified when I post using Facebook comments. One of the main reasons I comment on an article is to start a conversation with the author on the subject. If I can't tell if he's even notified, I probably won't bother.

I understand why people think adding Facebook comments will help drive traffic to their site. Perhaps in some contexts it makes sense, but if you were wondering why no one is commenting on your articles, consider if better engaging your readers is more important to you than polluting their social feed. Also - visitors might not even have a Facebook account, or they are not logged-in at the moment. Don't make this a barrier for engagement.

If people do feel they want to share your article on Facebook, use social sharing buttons, like the ones you see on this blog. Don't force commenting and sharing as a bundle package to readers.

Edit:

After reading and responding to the comments below, I understand it was not completely clear what my stance is. First, I'd like to make it clear I have nothing against Facebook, or its comment widget. I was questioning the appropriateness of having the comment widget on sites / blogs where I read for professional reasons, and would like to keep it separate from my personal Facebook profile.

Keep it separate doesn't mean just that my friends on Facebook will read it, but also whether other readers of the blog will have access to my Facebook profile, which I'd rather avoid.

In addition, I was writing the post from the viewpoint of a site visitor who's been frustrated by having no recourse other than using Facebook comments - not from the viewpoint of the publisher. Content publishers have their own objectives which might not align with mine, and it might be perfectly fine with them that I don't leave a comment on their site. There's nothing wrong with that.

To sum it up - if you care about people who want a separation between their Facebook profiles and their professional reading, you should think twice about using Facebook comments in your site.