Posts Tagged ‘startup’

How much money do you need to get started?

Tuesday, February 23rd, 2010

… You want to raise just enough money to solve a small problem for even a smaller set of customers to start with.

A lot of ventures start with a dream, a vision; to solve a problem in a specific Ruby Throated Hummingbirdway. The dream could be a INR 100 crore product or something as complex as an ERP on the web to a even more complicated, a Hospital Information Systems (.. search engines? they are easier to build these days).

The vision cannot be achieved in 6 months or even 2 years — Takes 5-7 years on an average to build an INR 100 crore company. So you want to start now, and want to start small, chiseling your idea, refining as you go, adding feathers in your cap and changing gears and accelerating as you move.

First, zero in on a handful of customers and a specific problem the customer may have. Do not worry if others mock you for building a feature & not a product. You know your destiny. You know where you want to reach. Validate what you have built. Give the customer something useful so that he can pay for what you have built. Iterate on your product.

There are a lot of examples where the companies started small and began by solving just one small problem and then morphed into gorillas; from companies selling PCs — to cloth merchants now with fully backward integrated perto-products chain.

A large amount of money spoils you, ties you up with your own experiments and forces you to deliver a product which does not have any takers outside your laboratory — You are forced to linger with the experiment because now you have a large amount of an external investor’s money and do not have guts to tell him that it is not working out. There are numerous examples. There are only a few brave entrepreneurs who took $5m only to tell the board in less than a month about change in the business model.

When you are starting out, you are building something and proving your hypothesis. The moment someone starts paying for what you are building, a part of the hypothesis gets proved. You continue to iterate.

Think 6 months, 3 people’s expenses.

Think 6 months, 2 people’s expenses.

Think the amount of first tranche you need to deliver to your first customer.

Think about knowing the sales process yourself before hiring a sales expert.

Think doing zero dollar marketing before doing SEM campaigns.

Think writing the code yourself before hiring a developer.

… start thinking about raising big money after your customer trusts you with his money.

(The thumbnail is of a Ruby-throated hummingbird. These are solitary. Have one of the highest metabolism, and as part of their migration, they fly non-stop across the Gulf of Mexico, a distance of at least 500 miles. Pic courtesy)

Poet Kabir on mentorship

Tuesday, February 2nd, 2010

I was reading some Hindi literature over the weekend. Found this doha (a kind of verse) from the great Indian poet Kabir on mentorship.

Kabirdas-ji says:

तारा मंडल वैसि करि, चंद बड़ाई खाई |

उदए भया जब सूर का, स्यूं तारां छिपि जाई ||

Shall update with the translation sometime later. Why don’t you attempt translating this in the comment section?

Laptop to Loadbalancer: Is your LAMP hardware infrastructure growing like this?

Wednesday, January 13th, 2010
Lamp Growth Plan

Lamp Growth Plan

The visual image conveys the thoughts. The data legends represent a hypothetical configuration using Webservers, Database Master and/or slave or DRBD, Memcached nodes, etc. The size of the circle represents the relative amount of money spent on monthly hardware lease.

How did your web presence grow?

Disclaimer: The above does not include security, disaster recovery, backup and other attachments which are a must.

10 Tips for Technology management in startups

Sunday, October 25th, 2009

This piece is for software technology startups (or startups using technology) with 2-5 developers, who are short on money, are on a continuous bouts of brain freeze, etc etc. However, for people who are managing 100 people teams, I’m gonna write one on how not to manage technology, but that’s coming after rebirth.

In my previous stints managing pieces of technology including developers, code base, release cycles, etc. — I was always hunting for tips for better sleep management. Huh, the solution was in managing the technology effectively to get a better sleep.

Here are some of them compiled (some learned after reflecting on mistakes!)

  1. Build Now. Scale later. More often than not we worry about whether this piece of code or even this atomic function will scale or not. Once I was writing a small function to convert time into the now famous “10 minutes/days/years ago” format.  I took the whole fraggin’ day on it. Back in my mind I was trying to optimize a small calendar look up which probably optimized the code by 10 ms for every HTTP request. Big deal — but totally stupid.  Essence: Build what you can build. Do not spend more than 10% extra time worrying about scalability & performance. The objective is to get the customer first within acceptable limits of latency. Also, look at your strengths — if you are a developer never worked on high performance computing but know enough chops about writing good code, then just focus on that.
  2. Release frequently, but not every day! The release early, release often is a myth which leads to disaster many-a-time in increasing code complexity, release cycles, etc. A good discipline is not more than one (yeah, 1) release every week (ideal is release every 2 weeks). Let the customers breathe, the QA breathe and stop wasting the time doing regression on the code. However, apply the exception to hot-fixes, security fixes and show-stopper bugs.
  3. Prevent public bugs. Another myth of release early, release often is a conception that it is okay to have a few bugs on the code. Depends on what kind of bugs. Database connect failures? or weird on the face JS errors. Acceptable public bugs are those which are not seen by more than 10% of your customer base & depends on what stage of maturity your product is in. However, bugs when monetary transactions are taking place are a strict no. Another theory is that the number of public bugs is inversely proportional to the number of users.
  4. Secure your web presence. This is getting complicated as the web matures & hacking is done using scripts instead of deep knowledge of software’s workings. In my previous stints managing technology, I thought & claimed to be ahead only to be humbled later with DDOS attacks. In my theory a 10 hour of Googling followed by 10-15 hours of fixing/implementing can take care of a good percentage of publicly known security holes.
  5. Code Now. Refactor later. This is a personal anti-thesis which goes against the philosophy of designing beforehand; thinking through of the architecture, etc. Why? Startup resources are extremely limited. The objective is to show/deliver products. As a developer/technology manager you want to put your best efforts in delivering code rather worrying about the best possible way to develop a piece of code. However, it is okay to postpone some design issues (not the security ones) and revisit them after hitting some milestones. You don’t use the “refactor later” mantra to avoid the issue; instead being pragmatic about it. Also the exception should be conveyed to the team, the options available, a path chosen; with the reason that this does not become a habit within the organization.
  6. Never outsource, but augment staff. The worst thing a startup could ever do is let someone else develop the technology and that too in someone else’s office! If you can’t hire full-time then hire contractors. Get them to sit with you, together. Have control and visibility.
  7. Production release not tested here! Developers will always make an assumption that if it works on their laptop/private environments, it will always work on the production environment. Do not ignore that — Have a discipline of testing the code after deployment.
  8. Automate everything, except your customer support. You want to automate/script as much as possible. Deployments directly from SVN, automated testing using various frameworks, log monitoring & alerting, server status, linting, database sizing, load, and every mundane tasks with actions like alerts etc. going to the team. However, you do not want to do an auto-reply to an incoming mail. OK to be slow by few hours but acknowledge/respond to each one of them. Put the startup resources to test.
  9. Code all night, but release after noon. Simple. You want to do a production deployment when the hangover from a night of coding is gone. You want to start before the day is ready to end. Never deploy at 5pm or 8pm or early in the morning. Best time to make a release is at least 24 hours after the developers have said “it is ready to go!”
  10. Secretly review a developers code. Highly effective. This is the best way to build opinions about a developers’ coding chops and get an edge in managing them. Find bugs in their codes, show it to them but never demean them publicly. All public code review in startups is actively discouraged.

If you can do the above well, then you can definitely sleep more using the 10 foolproof tips for better sleep management :)

Mine is a SaaS startup. We do…

Tuesday, September 15th, 2009

Scratch that. Delete that title.

Start with “Mine is a <insert product here like, finance, healthcare, etc> startup.” The only time you are a SaaS startup when you are solving a fundamental SaaS need like billing, metering, security, auditing, etc. It has become a fashion to use the latest technology to pitch your business and has been successful like, “We are <Java/Web2.0/SaaS/cloud/blah startup”.

Don’t move with fads.  India does not need fads.  India needs products.

The average consumer does not understand the technology stack. They need a solution. Whether the product uses cloud, SaaS, Java, Visual Basic — the consumer hardly cares. If it solves a need and must be on the internet then it does not matter whether it’s SaaS or BaaP or cloud.