Startup Thoughts: Realty and a Dream

Everyone wants to be a big bad rock star entrepreneur, wake up to that morning when your bank account is flooded by plain cold cash, you are making millions while sitting at home and watching the download meter of your software or user count of your web site flying sky high every day.
Well, it's possible, many people have done that, and the nice thing about the web/internet world, is that there will be always, always, enough to share.
But it's a long way, and as the nature of things that take long, they tend to break our spirit, get us bored and insecure and afraid of competition.
I have gathered around a few misconceptions about startups and entrepreneurship, misconceptions that most people around this business seems to posses, but those who won't, these are the ones who break forward.

Misconception #1 - "Fast, Fast, Fast"
Well, shortly.. NO!
Nothing is more important than keeping your startup organized, Clear and planned ahead. Programming fast does not guarantee a better product, Designing, looking around a bit and gathering the baseline on which your consist your product, does guarantee a better product.
Get yourself a clear milestone plan, point out Alpha version (Standalone POC), private beta (for users you self pick) and a public beta, and stick with this plan!.


Misconception #2 - "We'll grow with it"
Scaling... people seem to forget about it, more like avoid it until the "twitter/dzone/digg affect" hit's their home page.
Web application tend to collect more users in a period of time than a downloaded software, web applications are also a single point of service (in case of SaaS), so you'd better get your system infrastructure ready and available for a user boost one day or another, viral marketing can be a dangerous thing.

Misconception #3 - "I've had enough"
i've heard people say "if this project doesn't go public in 5 months, i am out" or "i can't work with this people, i'm out". There's a word for people like that.
quitters.
and quitters don't get rich.
The people you work with may be annoying as hell, stupid as hell or useless as hell, if you truly believe in the concept of the idea, don't let anyone else's negligence to take what is yours and do everything you can (and you ALWAYS can) to get the startup up and running.

Misconception #4 - "We need more money"
Sometimes you do, sometimes you don't.
In order to get a website up and running these days, ready and eager to handle thousands of users, you only need AWS, which if you exaggerate like hell with your configuration, you'll get to 1000$ a month.
So following my previous post, you should know that one or more of your partners must be able to supply you with technical solutions (system administration, coding) so this should almost never be counted as an expense.
Most of the most successful startups were not founded, ever. keep that in mind.

Startup Thoughts: Sharing the cake

I've been involved in several startup projects lately. I the majority of them, one of the main reasons why founders and equity owners start to fight one another, is the moment in which someone thinks some equity needs to be shared with someone else, out side the current equity holders circle.

Well, nobody likes to give out equity and it's hard to know when and tho whom such company/project holdings should be granted.
The option of giving out equity, is mostly driven by the fact the founders need money to make their idea come to life, money or an equivalent needed resource (advisers, tech people). When there is no money, you need to ask yourself one question.
Do i REAALLLY need it?.
They say that holding 100% of 0, is 0.. and they are right, if you will hold your equity holdings close to the chest and refuse to share no matter what, you'll probably heading straight down the hill. But on the other hand, giving out equity for anyone who wants some, or giving unreasonable amounts for that matter, is same as bad.

You can't do anything by yourself, you have to share your idea with some other people (unless you are really something special).
The first time you share your project equity with the other founders is simple and easy, most of the time the equity will be divided equally (and it doesn't matter who brought the idea, it's irrelevant) among the founders, stated in a partnership agreement later to be replaced by and incorporated entity legal documents.

Now when it gets to expanding the circle, there are two kinds of entrepreneurs that i can across with:

1. Hard - These guys are either possessed with a too-high-self-confidence and sure that they can make it to the finish line without sharing a 0.1% with anyone else except for the initial founder circle or people with a wise project-wide view of things and insists of not giving away equity until it's absolutely necessary. He believe that any problem can be solved either by finding other forms of getting the required service/resource and will do whatever necessary in order to make things work out without having to release equity or unnecessary funds.
   It's hard to distinct between these two sides of the Hard Core entrepreneur, but if you have the second kind of person in your team, you are a winner.
2. Soft - The soft entrepreneur is the the person who will be willing to give away anything for a little help. They will prefer to give away equity as much as possible like hot buns when it's not necessary and not required.
3. "Don't care" - people who prefer not to take a stand, and will leave everything in the hands of other founder or all the others together. While this can be very useful when he goes your way, it's a problem when he's not.
   
   

So how you make the decision?
I don't believe in workplace democracy, not all the time. Sharing equity should be unanimously passed if it is taken in a vote matter, or by a single responsible position holder (CEO for ex.).
Each one of the initial founders holds his share for a reason, he earned by contibuting to the success of the project and therefore should not be downsized unless he agrees.


You are not giving out equity to whoever comes your path, this list of people you should consider giving equaty to in exchage to their services.

• External CEO - You know how to program and design, but you don't know nothing about the business world and need someone else to guide your project to success. An external CEO is a good solution for that as long as he really understands what your idea is all about, what rarely happen.
  Nobody knows your product better than you or your fellow founders for my opinion, but if you need a CEO, grant out about 10-12%.
• Venture Capital Firm - The start-up Messiah, will generally have their own demands but it will move around 20%-60%.
• Strategic Investment - Someone who has the capabilities to bring your product to your desired market, audience and exposure. Depends on what he can give you, the appropriate share for such a service is 13-17%.
• Angel - A small financial investment that it's entire purpose is to get things running. 10%-15% is enough, but note that if it's a first financial investment, it's also sets your company value. (10% for 25K, brings your company to a 250,000 value, and your share grows as well.
• Tech Services - If you are going for a tech related project, such as a website or a software, make sure the other founders can supply as much as possible from the project's technical requirements, if you didn't (bad) and still need these services, grant about 0.2% for a programmer and 3%-4% for a team leader.
  

Kinds of people that should never get an equity share are: lawyers, advisers, sales persons and such.
Keep in mind that anything that can wait, should wait and the Internet is a pretty big place for you to find what this people will probably charge 100$ an hour to tell you.
When you do need a lawyer or counseling, pay the money and that's it, no equity for counseling.

Last thing, keep in mind that there are wolves out there, people who seek to only find young, naive entrepreneur to which they can sell any dreams they want.
Consider every offer, but make the most to avoid sharing if you can, and if you do, share as little as possible.

How to avoid screwing up a software project

Run Programmer, Run

When developing a new application, mostly when it's being done personally and alone, can sometimes be a very complicated process. you'll need to handle a whole bunch of other stuff than just coding (marketing, server setups even investors hunt) and it can sometimes lead you to a software neglection.
Don't let it happen, run/compile your application every few days, keep it living in your head.

Sometimes you'll start work on some big shiny feature (e.g. adding a kewl Google maps integration), but stop because you hit a technical bump ("What? no maps for Israel?"), or don’t have the time to finish it ("Need to finish this Company profile by tomorrow") and The source code is left in unfinished state.
You can’t do anything with any of your code until this is fixed, and the longer you leave it, the more you’ll forget and the harder it will be to get started again.
This is called a "broken build", and is a big landmine because it impacts other peoples ability to work (And your ability to continue as well).

TIP #1: You started something? finish it before moving on to something else.
TIP #2: Stay in touch with your software.

"I Sure could use a time machine right now...."

Know these times when you wished you had a time machine? well, it can happen in the process of developing and application too.
People make mistakes, Always. When people make mistakes in the kitchen, the food comes out really bad and you call the local pizza delivery services and solve the problem. When a programmer makes a mistake or is doing a system wide change... you'll need a ready to use Plan B around.
Source Control is the software world equivalent of a time machine, you can go back to a certain version of your application and rollback any changes made to your code and application, and by that, maybe reversing a very serious threat to your code.
If you haven’t taken the plunge with revision control yet, I highly recommend looking at some of the free SVN or GIT hosting services post.

TIP #3: Save yourself, use a source control service.

"Look at this cooooooolll JQuery accordation!"

Features are fun, Javascript magic is amazing, but you'll need to focus on what's really important
Focusing on things like validation, cool eye candies or extra functions is a great way to build up a large complex code base that doesn’t do anything useful yet.
Focus on the core functionality of your software first — your main features should be complete before you start thinking about WOW stuff.
Wasting trying to think of the perfect name, designing a logo or an icon, choosing the perfect open-source license and making a website won’t get you any closer to having a working application.

TIP #4: Core functionality first, fun - later.

Throw your code away and start from scratch - The Netscape mistake

As Netscape famously discovered a few years ago, throwing away existing code to start afresh is almost never a good idea. Resist the urge and make a series of small, manageable code re-factoring instead.

TIP #5: Never sink your own boat, pickup a bucket and start pulling out water

Pull yourself together before you sit down

"mmm, Rails? or maybe Adobe Air? or maybe... maybe we'll do the cool gears thing?"
Before doing anything ask yourself a simple question - "What are you actually trying to achieve?", Spend some time with a pen and some paper coming up with a really clear vision of what you’re trying to create — e.g. screen mock-ups, basic core functionality (yes, again) and if there is a process you are trying to imitate, go through it too.

TIP #6:  If you don’t know what you’re doing from the beginning, you’ll have no chance of finishing it.

Get the right men for the job

You maybe a coding genius, a super-programmer (Mike it's you) or other superior programming entity. but unless you are a really something no one had ever seen before, you don't know anything there is to know about every aspect of developing a new software and a products.
If you can't tell the difference between red and green, get a designer to work for you. if you don't have a clue in CSS or DB infrastructure, get someone who know this art to do it.

TIP #7: Do what you know, not what you don't know.

Marketing is Important, but when it's time

Tell people about your product when you have something to show, open a product twitter account when you have something to say, don't rush yourself forward and try to stick the product or create a hype when you can't back it up by at least screenshots or an actual product on the best scenario.

TIP #8: Invite people in when you have something to offer them to eat.

The difference between a lie and a promise

Users don't mind waiting for features, they mind finding out you promised them something and didn't deliver.
Stand up to your words, and update your users about development progress and new features on the way, as long as you really intend to do it and not just saying to make them download or register.

TIP #9: Users are like your mother, lie to them, and they'll know.

Looking for a RoR team

Well, it's time to move on and work on marketing my new application (can't tell you what it is yet :) ), but i need a dedicated, professional Rails+Client Side development team to support the final stage of development, and to continue supporting further changes.
I heard about people getting teams in India, and some companies offer services for out-sourcing code, but i prefer at the moment to find a team (india, USA doesn't matter) that will support my application and will be ready to put some real work into it.
anyway, if anyone is interested, post me a message on linkedin.
basically the skills i need are

* Ruby on Rails experience (2.x)
* Client side (JQuery, MooTools, MochaUi is a great plus).
* CSS and some basic design capabilities.
* DBA (MySQL, Oracle experience will be a great advantage).
* Amazon AWS+S3+EC2 experience.
* ability to work remotely.

i will prefer a whole team, rather than finding these skills in specific programmers and building the team myself.

UPDATE: All positions are filled, thank you everyone!

How to save money in your startup company

• Buy Macs, They are a little more expensive, but worth a hell lot of money in productivity terms


• Buy a second monitor for every programmer, passing through windows (a.k.a: browser to Textmate and back) take a lot of time. worth the money.


• Buy everyone food, all week long. when people go out to work it takes a lot of "extra" time, by buying them the food, you'll cut off about 20 min. per lunch break.
  
  
• Expensive chairs, crappy desks. most of the programmers i know, appriciate their chair more than their table, their chairs are those big high-backed cousins, while the desk looks like a dump, besides everything you buy should be ergonomically designed
  
  
• Programmers don't need phones, don't buy an expensive phone system, most of the programmers i know talk to each other across the room using Skype :), save the money for an executive phone system, if needed at all.


• Rent to grow, don't rent offices with no space to grow (expected growth is something you need to calculate prior to renting an office). rent 100% more than what you need.


• Outsource HR, YOU DON'T WANT THE HEADACHE, assign a professional employee to view the final candidates


• You don't need an office, you need Google. Don't buy Microsoft office for everyone, buy for 4-5 stations and the rest can use Google Docs of one of those Java based editors (OpenOffice or Neo Office)


• Use Google Apps, Emails, Documents, Wiki.. why hiring a system programmer for those? or even waste your employees time on building a wiki


• Key programmers should get a laptop, do i need to expain?


• Hire devoted programmers, these guys (when payed to the full) will work harder and faster than anyone else in the crazy startup life, compansation via paycheck will be required, but these are valuable employees.


• Refrigerator, everyone knows that programmers drive on Coffee, Coke and Bamba (in Israel at least, in USA it's Cheetos or something:) ) so i suggest a Coffee machine and a snack drawer in the kitchen, a chocolate bar can do wonders to code.


• Just finish, allow your employees to work in their own hours, (within reason and except the situation a bunch of programmers is needed to work together) when they are aware that they have a deadline, some people need to sleep until 10:00am, this does not mean they are not right for you


• Cars, very important, an employee that needs to drive around buses for 2 hours in the morning traffic, is not a happy man


• Clients don't speak to programmers, they don't speak the same language, use a dedicated person to bridge between the programmers and the clients, or if possible, hire a support personnel


• Source Control, use Svn, Git or something, just do it...


• Allow remote connectivity, you can hire people from abroad and still not to micromanage them, think about online collaboration too


• Task management, use an online application, like basecamp or something, they keep your life easier and cost almost nothing.


• Open Source, use open source software when possible.


• (No) power to the people, empower a power saving policy in your startup, turn off screens and hibernate stations on the end of work for starters


• Big Bad Bandwidth, there is nothing more annoying than slow connections so buy the biggest bandwidth possible, BUT, keep an open eye for Emule connections and such, you don't want it around.


that's it for now, thank to all of my programmer friends that helped me composed this one, i'll view the comments and update if necessary

Unveiling the new startup

I am currently up to an exciting new skeem, me and some of my fellow programmers are working for some quiet time on an amazing, innovative music related startup.

What is it about?

Sorry, can't tell ya yet, hold on and don't be so indomite. :)

What am i doing there?

I am 99.5% responsible for the server side (yap, Ruby on Rails!),what seems to be emerging as my finest work. Barak Edry which helped my on Pdfetch.com and worked with me on Creopolis is busy working on the GUI for both the client and the server (yaii, no views for me... i think) and since Ohad Asulin is our Oracle-ninja-C++-shark and therefore too busy to help me on Rails, i was left responsible for the server side. no sweat :)

OK, but you didn't tell us nothing yet

Right, and i am not going to... just wait and see.

When?!

Soon, every on who is playing on ANY kind of instrument, please e-mail me and you'll be notified as sooooooooonn as the public beta goes out.

more on the secret-amazing-startup to come.