Startup Engineering notes
Note: I'm currently taking a break from this course to focus on my studies so I can finally graduate
This course bridges the gap between academic computer science and production software engineering.
These notes are a combination of
the good parts of the lecture notes & assignments
outside resources (e.g. suggested readings not covered in lecture)
my own notes
Stanford's enrolment page - for Stanford students but some course material is publicly available
Notes for Peter Thiel's startup course - skim them early and return to them over the course of the class
Eloquent JavaScript - superb intro to JS with interactive examples
The general consensus is that a startup is a business built to grow extremely rapidly. Rapid growth usually necessitates the use of a technology that invalidates the assumptions of politicians and businesses.
Not only were capital costs low, at the beginning of each of these earlier startup eras, there was no permitting process. The initial pioneers in these startup eras thus had time to get underway before competitors and regulations alike started presenting barriers to entry.
A number of new technologies on the horizon point in the direction of continued decentralization and individual mobility.
Startup engineering means getting something to work well enough for people to buy. Startup engineering is concerned primarily with shipping a saleable product.
One of the primary things a startup engineer does is systems integration: keeping up on new technologies, doing quick evaluations, and then snapping the pieces together. The right tools can be like the difference between going to the library and hitting Google.
When building a startup, in the early days you want to first choose the best contemporary technology and then forget about technology [1] to innovate on only one thing: your product. Outside of the core technology, you want to be as boring and vanilla as possible until you begin to make a serious profit from your first product.
[1] At the inception of a company, or a new product, you will gain maximum advantage from selecting the best contemporary technology, one that is clearly rising but may have some rough edges. Today, that technology is arguably a full-stack JS framework based on node.js, making heavy use of AWS and Heroku. In 2-3 years it will likely be something different. But once you pick out the elements of your technology stack and begin developing your product, relatively little added value comes from radical shifts in technology (like changing frameworks), and switching technologies can become an excuse for not working on your product.
To ship a product a startup engineer needs versatility. If you are a founder, you will need to handle things you've likely never thought about. You’ll need to be able to produce a passable logo, design the first brochures, and do the initial sales calls - all while moving technology forward. You will greatly benefit from the ability to handle things, like the ability to design, market, and sell the product you’re building.
Amazon AWS is useful for having a centralized development environment that's accessible from anywhere and is easily clonable. There exist alternatives for cloning configurations, e.g. Puppet, Vagrant, Chef.
You may also choose 13.04+, which ships with mosh.
Go to My Account > Billing Alerts and follow the instructions.
If you're taking advantage of the free tier, you'll want to set the alert threshold to $0.
Set up an EC2 instance which allows HTTP connections on ports 80 and 8080. This will allow you to debug your webpages while previewing in a browser, rather than copying it locally or pushing to Heroku.
Go to the EC2 Dashboard to set up a new security group. Apply the new security group to an existing instance.
Instances > select your instance > Actions > Change Security Group > select the new security group
Note that you can also create a new instance with the new security group.
Don't forget to add the UDP rule for mosh to work.
Set your web app to run on port 8080 (e.g. in web.js
for a node project). Run your web app (e.g. node web.js
).
Open your browser and view your site. E.g. ec2-54-218-72-128.us-west-2.compute.amazonaws.com:8080
You can run a command with ssh and exit right away, e.g.
$ ssh -i Downloads/dideler-startupeng.pem ubuntu@54.218.21.238 uptime
03:17:15 up 17:00, 1 user, load average: 0.00, 0.01, 0.05
$ # mosh doesn't support this yet
Note that if you terminate or stop your instance, the hostname of your EC2 instance will change and your SSH config will fail to work. You can either a) not terminate the instance, or b) assign the instance an "elastic IP" from Amazon and reference that address instead.
For an elastic IP, go to "Network & Security" > "Elastic IPs" > "Allocate New Address" > "Associate Address" to your instance, then use the given IP. Each running instance is eligible for an elastic IP at no charge, but multiple IPs costs $.
Set up mosh for AWS (it ships with 13.04+ but AWS has 12.04). Open the UDP ports 60000-61000 in EC2. From the AWS console, go to your EC2 instance manager and click Security Groups in the sidebar. Select the security group your instance is using (probably quicklaunch):
Now connect to your instance
$ mosh --ssh="~/bin/ssh -i ~/path/to/your/ec2/keypair" ubuntu@ec2-xx-xxx-xx-xx.compute.amazonaws.com
Configure ~/.ssh/config
so you can just type a shortcut (e.g. mosh aws
or ssh aws
) to connect.
mkdir -p ~/.ssh
mv ~/Downloads/identity.pem ~/.ssh
chmod 400 ~/.ssh/identity.pem # if you haven't already
chmod 700 ~/.ssh
nano ~/.ssh/config # see below for content
chmod 600 ~/.ssh/config
Contents of ~/.ssh/config should look like this.
Host aws
Hostname ec2-54-218-72-128.us-west-2.compute.amazonaws.com # or use the IP address
User ubuntu
IdentityFile "~/.ssh/identity.pem"
man ssh_config
for more info.
You'll have to install all your core dev tools, such as npm and node.
sudo apt-get update
sudo apt-get install python-software-properties python g++ make
sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install nodejs
Don't forget to install git and set it up (use GitHub's tutorial). Also copy over your dotfiles.
Alternatively (and probably a better solution) is to use virtual environments and something to easily manage them (e.g. Vagrant + Puppet/Chef, Salt, Ansible (good for small jobs), virtualenv/virtualenvwrapper, etc). This allows you to easily create disposable development environments.
Vagrant is an established project that wraps around a number of existing virtualization providers (e.g. VirtualBox, VMWare, EC2) to allow for extremely quick provisioning of disposable, consistent environments. Create a single file for your project to describe the type of machine you want, the software that needs to be installed, and the way you want to access the machine. Store this file with your project code. Use vagrant up
to configure a new VM (using a virtualization provider) using that configuration. Then, Vagrant can use one of many configuration management tools -- Chef, Puppet, Salt -- to configure that disposable environment to mirror your production environment. Vagrant doesn't really do configuration on its own (unless you count running shell commands).
Copy files to/from the server using scp
(GUI options exist and one is built-in to Ubuntu). E.g. to copy a file from the server to your local machine:
scp -i identity_file.pem ubuntu@ec2-01-234-56-789.compute-1.amazonaws.com:~/foo/bar.txt .
Or to copy from local machine to AWS instance (and place it in $HOME):
scp -i identity_file.pem file1 file2 ubuntu@ec2-01-234-56-789.compute-1.amazonaws.com:~/
If you set up your SSH config file (see above), then scp becomes a lot simpler to use:
scp foo.txt aws:~/bar.txt
Some commands, like npm
, require superuser permissions. Instead of using sudo
every time, you can claim ownership of the appropriate directory. E.g. sudo chown -R ``whoami`` ~/.npm
Also called the application-service-provider (ASP) loophole. You can include GPL software in your non-GPL software (hence not having to release your code) if you're providing service over a network, i.e. it's server-side code (todo: verify). You can also use GPL code in your non-GPL code if you link the the code but do not use it's source directly in your source.
There's the professional open source model, which RedHat made popular. The problem with this route is that a model based on consulting is a service-business, not a product business. It doesn't scale as well (hiring more competent people vs buying more servers).
There's the freemium model (e.g. Dropbox, GitHub). Basic services are free and premium services are paid.
And other models, mentioned later.
Most common setup is to equip engineers with Macbooks (personally I think ThinkPad is just as good an option) for local development and servers running Linux (as a virtual machine) for production deployment. This is because OS X runs a BSD variant, so most code runs between OS X and Linux with little or no changes.
Gaining popularity is to use Chromebooks (which start at $200) and SSH to a server (e.g. AWS)
Infrastructure-as-a-service (IAAS) providers, like AWS, usually do not rent out single physical computers, but rather a virtual piece of a multiprocessor computer. Virtualization allows maximal physical utilization of expensive multiprocessor hardware. An 8-CPU computer split into 8 different virtual servers offers better utilization, even though the "virtual computers" are less powerful than native hardware.
A cloud computer is a remote computer accessible over the network (typically interent) and is used instead of running something locally. Many applications can tolerate a small degree of network latency and/or physical separation, making cloud computing quite useful.
There are 3 classes of cloud computing:
IAAS: AWS, Joyent, Rackspace, ...
Provide CLI access to the machine, but you have to take care of details for deploying code.
PAAS: Heroky, DotCloud, Nodester, Google AppEngine, ...
Provide an API that abstracts the CLI, but access to CLI is possible if absolutely necessary.
Note: Heroku began as a layer on top of Amazon AWS.
SAAS: Salesforce, Google Apps, Mint.com, ...
Provide GUI or API access, no CLI access (hence no control over h/w).
Intro to essential Linux commands, e.g.:
date
shows current date and timetime
useful for benchmarking (there's also GNU time, more sophisticated, can show max memory consumption: /usr/bin/time
)rsync
is generally a better alternative to scpln -s
for creating symbolic links (having a file in two places at once via a pointer)cut
commonly used for selecting fields (default is to delimit by tab)sort
for sorting, has many optionsuniq
for unique datawc
for many types of counts, e.g. words, chars, lines, longest line (for pre-allocating a buffer)split
splits files, handy for parallel processing jobshead
shows the beginning of a file (defaults to first 10 lines)tail
shows the ending of a file (defaults to last 10 lines)tail -n+4
paste
combines columns (commonly used with cut
)wget
& curl
for grabbing online resources; curl
is handy for APIsnl
prepend line numbersxargs
execute commands from STDIN, useful when dealing with a huge number of files (use -P
to enable multiple processors)find
non-indexed search, e.g. find /etc | nl
locate
indexed searchsudo apt-get install -y locate;
sudo updatedb;
locate fstab
grep
print lines matching a patternsed
stream editor for filtering and transforming text, useful for search and replace - one linersawk
pattern scanning and text processing language, useful for tab-delimited data - one linersShould also work in fish shell.
fg
sleep 10 &
screen
tab manager for remote sessionsAllows you to reconnect and resume your session where you left off. Useful if a remote connection drops or for any long-running computation (running as a background process--see above--is a viable alternative).
tmux
is considered a better alternative to screen
. Use it with teamocil to automatically create sessions, windows and panes with YAML files.
In screen
, type
Note: C-t ? means CTRL and t followed by ?.
emacs
environment for writing codeFirst execute the setup script.
sudo apt-get install -y git-core
# see https://help.github.com/articles/set-up-git for more help
git clone https://github.com/startup-class/setup.git
./setup/setup.sh
Launch emacs without windows and without customizations: emacs -nw -Q
Go to the command prompt with M-x, where M is the meta or alt key.
Type help-with-tutorial for a tutorial.
Exit with C-x C-c.
Note: I'm skipping the rest of the emacs section since I'm a happy vim user. You can view the rest of the emacs tutorial by reading the above linked PDF, or start by watching this lecture video.
git
distributed version control system (DVCS)Note: I'm also skipping this section because I'm already well versed in git. I once gave a presentation on git.
Tip: The crowdfunding site that we're building uses heroku/node-js-sample as a base. See here for more info. Don't forget to heroku create
from your project's git repo, then git push heroku master
.
You should have a setup.git repo (configures the machine) and dotfiles.git repo (configures the user environment). Setup.git will have a script that clones and sets up your dotfiles; you can also combine them into a single repo. These make setting up a new dev environment much easier and quicker by programmatically configuring an arbitrary machine.
For a business, it's better to use a more professional solution such as Vagrant (configures the [virtual] machine) + Puppet/Chef (configures the user environment & software) or many of the alternative options.
To fully automate setting up an EC2 instance, use the EC2 command line tools so you don't have to use the web GUI. Use in conjunction with a user-data-script for automatically running a startup script on each instance.
Any setup/configuration of a machine is code and should be treated as code. If the change is permanent, do not set it up manually on the dev machine. Instead, add it to the install scripts and config files and keep it under version control.
An idea is not a mockup
A mockup is not a prototype
A prototype is not a program
A program is not a product
A product is not a business
And a business is not profits
It’s useful to actually keep a single Google Spreadsheet with all your ideas, organized by stage in this manner. Expect most to stay at the idea stage!
When it comes to starting a business, the conventional wisdom is that the idea is everything, the rest is just a matter of details. This is how the general public thinks technological innovation happens. Remember how people felt about the Instagram acquisition?
Execution is everything. Ideas and inventions don't matter if you cannot make a single sale.
The rationale here is that it’s easy to come up with a trivial idea like “let’s build a social network”, but quite nontrivial to work out the many technical details associated with bringing that idea to market, from large-scale to small-scale decisions. It’s also extremely nontrivial to actually turn a popular technology into a profitable business.
If someone can steal your idea by simply hearing about it, you probably don’t have something yet that is truly defensible. You can usually be reasonably open about discussing your ideas with people who can give a good bounce, who can understand the idea rapidly and throw it back with modifications. The vast majority of people are busy with their own things, or aren’t uncreative sorts who are both extremely good at execution and just waiting around to steal your idea.
BEWARE: If you have a pure internet startup idea, you should think carefully about whether you want to promote it on HN or the startup community before you’ve advanced it to at least a prototype stage.
People will copy the idea as soon as the market is proved out. It is far easier to verify a solution than to find one in the first place. A product selling like hotcakes is the ultimate demonstration that you have found a solution to a market need. You’re going to need excellent execution to survive, because sometimes these “clones” far surpass the originals. Sometimes it makes sense to keep your head down and grow once you’ve hit product-market fit without alerting competitors to the scale of your market opportunity.
“It’s not the idea, it’s the execution”. From an investor's standpoint, “It’s not the product, it’s the team”. A strong team will execute on that idea and push through all the details (financial, regulatory, technical, legal) to get that product to market.
The newest conventional wisdom: market is the most important factor in a startup’s success or failure. Why?
In a great market – a market with lots of real potential customers – the market pulls product out of the startup.
The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.
The product doesn’t need to be great; it just has to basically work.
And, the market doesn’t care how good the team is, as long as the team can produce that viable product.
A good founder doesn’t just have an idea, they have a bird’s eye view of the idea maze. A good founder is thus capable of anticipating which turns lead to treasure and which lead to certain death. A bad founder is just running to the entrance of the maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies that are likely to move walls and change assumptions.
A good idea means a bird’s eye view of the idea maze, understanding all the permutations of the idea and the branching of the decision tree, gaming things out to the end of each scenario. Anyone can point out the entrance to the maze, but few can think through all the branches. Historical perspective and market research is key. Find a hidden door, a unique insight from deep thought that others did not see.
The execution mindset means doing the next thing on the todo list at all times and rewriting the list every day and week in response to progress. This is easy to say, extremely hard to do. It means saying no to other people, saying no to distractions, saying no to fun, and exerting all your waking hours on the task at hand - run the maze rapidly.
The most important tasks are those that get you to the maze exit.
One Thing
Everyone in the company should at all times know what their one thing is, and others should know that as well.
Anti-TODO list
Periodically write down what you just did and then cross it off.
Even if you get off track, this gives you a sense of what you are working on and your progress to date.
Implement “Thiel’s One Thing” with chat status. If there’s something that’s worth nagging people about, it’s keeping their Gchat status up to date with their latest Github issue. It constantly refocuses you on your one thing, and allows the entire company to know what that is without constant interrupts. Periodically, you too can scan what others are working on without disrupting their flow.
You can start to see why startups are associated with the internet and small businesses with physical storefronts. There are exception, e.g. "life-style business" internet companies like 37signals, and physical operations like McDonalds that aim for world domination.
Small businesses must usually generate profits right away, while startups often can be in debt for a while.
Should you take outside capital and try to grow the business more rapidly, or should you rely on steady organic growth? Most go for outside capital.
Do a simple calculation to determine whether a given business is capable of getting there, i.e. it exhibits an economy of scale.
The annual market size is the total number of people who will buy the product per year multiplied by the price point. To get to a billion dollars in annual revenue, you need either a high price point or a large number of customers.
Note that low price points require incredible levels of automation and industrial efficiency to make reasonable profits.
With all else held equal, you want to pick the project with the largest market potential. Among other things, market size determines how much money you can raise, which in turn determines how many employees you can support. Among other things, you won’t capture the entire market, but only a portion.
The best market size estimates are both surprising and convincing. To be surprising is the art of the presentation. But to be convincing, you want to estimate your market size in at least two different ways.
Top-down sizing: Start from the top (high-level numbers) and work down from that overall number to figure out what’s relevant to your company.
Use Fermi estimates to determine the number of people who will buy your product (top-down market sizing). This will require knowledge of general stats like 300M Americans, 6B world population, 6M US businesses, as well as domain-specific stats like 4M pregnancies.
Bottom-up sizing: Look at individual customers or competitors and roll them up to get the overall size of the market.
Rolling up the revenue from individual companies (e.g. using SEC filings) to look at the overall market can be a great approach when there is a relatively small number of public companies in the market (e.g. US car market). In smaller and more fragmented markets, adding up individual competitors quickly becomes painful, but it can still be your best option.
Bottom-up analysis is generally more reliable, but you have to be careful not to overstate the boundaries of the relevant market. Usually the addressable market won't be the overall market, but a specific sub-market. Be a little critical of your own estimate and make sure that you’re sizing the market that you or your client can actually address, not a general market that looks impressive but isn’t really relevant. Also keep in mind that bottom-up analysis is generally not exhaustive.
Every market sizing approach involves a good bit of uncertainty. Time and data permitting, you should triangulate among a top-down analysis, a roll-up of individual customer spending, and a roll-up of competitor revenue. In an ideal world, these numbers should all be in the same ballpark, but if there is a discrepancy, you can troubleshoot your analysis or do a weighted average of the estimates based on your most reliable information. The resulting number won’t be perfect, but you’ll have a good analysis to walk clients or investors through to get their buy-in.
Tip: If data is really scarce, you can do some very rough market sizing by estimating company revenue based on employee numbers (which is typically easy to find, e.g. LinkedIn, Wikipedia, company's team/about page, Google Finance). This approach doesn't work well for early stage or small (< 100 employees) companies.
Tip: Stats Canada is a good source for market sizing. US sources.
A full market sizing example for board games.
Time to market (i.e. how long until shipping) is everything in startup land, due to the compounding effect. This is a second and crucial consideration in addition to sheer market size.
VC's will often use the following formula to help deciding on investing:
((QMP) / (SNT))^(1 / T)
Where:
This can be thought of as the amount of money returned divided by the cost of generating that money. It measures a company's growth factor (because compounding is everything for investors). More accurately, it's the measure of first-year-revenue divided by cost to get to first-year-revenue, renormalized for time to market.
Establish that a market exists before building a so-called minimum viable product (MVP).
Get some news coverage or research papers to establish the overall frame and display in any pitch to investors. Use Google Books, Wikpedia, SEC filings, and so on.
Back of the envelope estimate of market size, googling as necessary for any statistics.
Further validate this market with some modern tools, including Google’s Keyword Planner and Facebook’s Advertiser Tools.
If that proves fruitful, develop a simple landing page by using a service like Launchrock, with some photos and icons. Use ConvertKit to improve conversion rates. For more resources on photos, icons, etc, check out my bootstrapping gist. You may also want to do some basic SEO.
Tip: how to measure success of your launch page
Allocate a small Google Adwords or Facebook Ads budget to test out the market, and see how many conversions you get.
You've got a market and product idea, what features do you build first?
Pricing tiers depend on what you're offering. On KickStarter, common high-grossing tiers (by percentage contribution) are:
$25
$50
$100
$250
$500
$10,000 (have some intermediate tiers to make this one seem more attractive)
People don't mind paying $50 or more for a project they love. Be careful, mindset changes for mobile apps.
Avoid tiers less than $25, they are statistically insignificant.
5 tiers maximum, too many tiers can put off supporters.
Create tiers for the exact same product with backer caps at each one until the highest one.
Bulk discount tier.
The average pledge is around $62.50 (based on old KickStarter data).
You're not just raising money, you're also building a community of supporters through the fundraising process.
For crowdfunding, keep your funding period to 3-4 weeks. Any longer and it will likely have stale periods.
Reach out to blogs, relevant news sites, social media, personal & marketing mailing lists early on. Send about two emails on the mailing list at the beginning, one midway, and one near the end (e.g. 3 days or less).
Think in terms of micro-seed capital not one-off money.
Use these steps to aid with selecting product tiers and prioritizing features/versions.
The basic idea is that the ultimate market research is a table with 7 billion rows (one for each person), N columns on their attributes (e.g. location, profession) and K columns (one for each product version), with each entry giving the amount that person will pay for those features. You won’t be able to sample all 7 billion, but you can sample a few hundred (e.g. with Google Consumer Research Surveys or Launchrock landing pages), and this gives you a conceptual framework for how to set up your product tiers
In particular, you want to confirm that you will make enough money on version 1 to pay for version 2. If this is not the case, you should rearrange the order of features until it is true, at least on paper.
The vast majority of people will pay $0 no matter how many features you add (or remove).
A big mistake software companies make is charging too little, but the biggest mistake is charging too much, so they don't get enough customers. People tend to believe that you get what you pay for. When you're setting a price, you're sending a signal. Price below your competition and people think it's crap, price significantly above and it's outstanding.
You're not trying to maximize units sold (i.e. sales), you're trying to maximize profits.
When calculating profits, disregard the initial/upfront costs, those are sunk costs. Instead, consider the incremental/recurring cost of selling each additional unit (i.e. marginal cost), which may include S&H, support, etc. Your actual profit is units_sold * (price_per_unit - marginal_cost)
. Plot your profits for different price points to figure out how to price your product.
You'll want to capture the consumer surplus from consumers who would spend more than your decided price point and sell to them for a higher price. You'll also want to email/call back and beg those consumers who were willing to spend at most some price under your asking price and offer them the product for cheaper.
Separating your customers into different groups according to how much they are willing to pay, and extracting the maximal consumer surplus from each customer is called segmented pricing.
Different ways to segment:
Be careful, segmenting pisses people off, they want to pay a fair price. It creates no loyalty. It's also difficult to pull off properly. Don't use segmented pricing if you want to avoid headaches.
The only way to determine how much someone will pay for something is to put it up for sale, and see how many people actually buy it. Seriously consider spending about $250 for a demographically targeted survey with 500 responses. If you genuinely can’t afford this, ask 10-20 of your friends how much they’d pay for different version of your product, or run a poll on Facebook. Any feedback on pricing and features, even biased, is better than none.
Once you feel that you have a market, you should design a mockup of your product’s website, also known as a wireframe. Your main goal is to produce sitemaps and detailed user flows.
Here's an example of wireframing a crowdfunding page.
Our crowdfunding site will use this basic layout.
Which can be made with the following HTML (which uses Bootstrap).
And it looks like this (not the final product of course).
High-level principles:
Homepage message Don’t expect visitors to figure out what the product is about on the third page in; your enemy is the back button. Go to a cafe and test your homepage message on people with the 5-10 sec rule. Only spend energy on the homepage if it’s a significant source of customers. If it isn’t (e.g. if your sales come through a salesforce), you can leave the homepage alone for a surprisingly long time. Testimonials and customers People feel more at ease when they see other real people and companies using the product and recommending it. Work backwards from the press release Amazon writes the press release before they build the product. Doing this, you will find yourself figuring out what features are news and which ones are noise. Someone is wrong on the internet Get a friend to pull up as many competitor webpages as possible. Write down your immediate gut reaction as to why those companies are terrible and your company and product is different. Put this into a feature matrix and then determine whether your new features really differentiate your product substantially. Simple and factual Do your best to turn vague features (“PageRank provides better search quality”) into concrete facts and statistics (“85% of searchers who used both Blekko and Google preferred Blekko. Find out why.”). Use Oracle style marketing: less is more, hammering one point above the fold (i.e. above the scroll line) and keeping the rest in the secondary copy. Alternatively, use a carousel to neatly hammer out multiple points above the fold (but be careful). Check out Dropbox's minimalist landing page. Call to action You want someone to do something when they come to your page, like buy something or sign up on an email form. Make sure you reiterate this “call to action” many times (at least at the top and bottom of page). Make the call to action button cartoonishly large and in a different font.Take a look at the landing pages of some of the current top startups for inspiration (for both what and what not to do).
Wireframe goals:
High-level principles:
Vector and Raster Graphics Understand the distinction between vector (dynamic resolution) and raster (fixed resolution) graphics. Whenever possible, work with vector images as they will scale well and are amenable to later manipulation. Raster images are unavoidable if you truly need photos on your site, but strive to minimize them for your MVP. Contrast, Repetition, Alignment, Proximity Become familiar with the four principles, CRAP, as mentioned in the Non-Designer’s Design Book. A good strategy is to look at the examples, create your design without thinking too much about them, and then re-apply them over the design at the end. Fonts and Icons In terms of getting something reasonably nice together quickly, you should make heavy use of fonts and icons. Because fonts are vector graphics specified by mathematical equations, they are infinitely manipulable with CSS transforms built into every browser. The FontAwesome library also gives scalable vector icons, which are often useful for quick mockups when enlarged in size. Also consider using Unicode characters for icons. Photos, Videos, Animations Often the key to a good presentation or webpage is to put an abstract concept into visual form. Stock photographers have actually thought about these issues. Don’t use stock photos in which people are looking at the camera! That’s what makes a stock photo look cheap. A good signal of a lower quality site is that it has inconsistent padding, doesn’t use https properly for checkout,
and/or uses stock photos of this kind. You might also consider reshooting a stock photo with your product so that
it looks custom.</dd>
Use Bootstrap, Themeforest, 99Designs, Dribbble
When it comes to turning your wireframes into HTML/CSS/JS, don’t reinvent the wheel.
Design is information and is becoming commoditized. Use Bootstrap + Jetstrap.
Themeforest is a set of slightly more expensive ($9-12) templates.
99Designs is a few hundred to a few thousand bucks for a logo or webpage revision.
Dribbble is an excellent resource for finding a contract or full time designer.
Any web app will include HTML, CSS, and JS files in addition to server-side code. One of the advantages of node.js is that the server-side code is also in JS. You should separate your HTML, CSS, and JS, such that you can change any of the three (or more) files that specify a webpage without worrying about the other two. In practice, you will need to develop all files (.html, .css. and .js) at the same time as significant changes to the structure of a page will often remove id attributes or CSS styles that your JS code depends upon.
When in doubt, err on the side of separation of concerns: use HTML for structure, CSS for appearance, and JS for behaviour.
The single most important thing to learn are the Chrome Developer Tools. With these tools, you can do the following:
Also familiarize yourself with jsfiddle (very useful for sharing examples) and reloading tools like Live Reload (alternatives) or Codekit.
Initial idea doesn't need to be great, but it has to evolve into a great idea. Ideas for fast growing companies are so rare that the best way to find new ones is to discover those recently made viable by change. The majority of startups will be working on something that's never going to go anywhere.
Growth drives everything in this world. In technology, companies that grow slowly tend not to grow as big. The company's growth rate is the measure of a startup. If you don't know that number, you don't even know if you're doing well or badly. A constant number of new customers every month means you're in trouble, because your growth rate is decreasing.
Measure growth rate per week, but only after you've launched. A good growth rate (during YC) is 5-7% a week. If you can hit 10% a week you're doing exceptionally well. If you can only manage 1%, it's a sign you haven't yet figured out what you're doing.
Focus on just hitting a growth rate every week. This focus reduces the otherwise bewilderingly multifarious problem of starting a startup to a single problem. Use that target growth rate to make all your decisions for you. Having to hit a growth number every week forces founders to act. Nine times out of ten, sitting around strategizing is just a form of procrastination.
Best thing to measure growth rate of is revenue for startups that charge initially, and active users for startups that do not.
Startups early on need frequent feedback from their users to tweak what they're doing.
Be aggressive when recruiting new users. Manually and individually recruit your initial users; go out to a coffee shop and have people try your product. Go door-to-door. Have people sign up for your beta in person. The numbers will seem small at first, but don't be fooled by compound growth - it starts slow.
The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things?" And the right things often seem both laborious and inconsequential at the time.
You should take extraordinary measures not just to acquire users, but also to make them happy. Send them handwritten thank you notes. Give them free stuff (e.g. DropBox gives free space). Your first users should feel that signing up with you was one of the best choices they ever made. One advantage of being small: you can provide a level of service no big company can.
You can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness. The feedback you get from engaging directly with your earliest users will be the best you ever get.
Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly.
Like paying excessive attention to early customers, fabricating things yourself turns out to be valuable for hardware startups. You can tweak the design faster when you're the factory, and you learn things you'd never have known otherwise.
Pick a single user and act as if they were consultants building something just for that one user. The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too.
Another consulting-like technique for recruiting initially lukewarm users is to is to use your software yourselves on their behalf. They might not want to make and setup an account, so do it for them with their consent. It can teach you how it would feel to merchants to use your software. Sometimes the feedback loop is near instantaneous.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks.
The Big Launch tactic doesn't work. Launches matter very little.
Partnerships usually don't work either. They don't work for startups in general, but they especially don't work as a way to get growth started.
Any strategy that omits the effort—whether it's expecting a big launch to get you users, or a big partner—won't work.
TL;DR recruit users manually and give them an overwhelmingly good experience, and founders need to work hard
Convince investors with your startup, not your pitch.
Be formidable founders.
A formidable person is one who seems like they'll get what they want, regardless of whatever obstacles are in the way.
Formidable is close to confident, except that someone could be confident and mistaken.
Formidable is roughly justifiably confident.
To seem most formidable as an inexperienced founder is to stick to the truth.
Convince yourself that your startup is worth investing in (not that it'll succeed), and then when you explain this to investors they'll believe you. And by convince yourself, I don't mean play mind games with yourself to boost your confidence. I mean truly evaluate whether your startup is worth investing in. If it isn't, don't try to raise money and change what you're doing.
Know everything about your market.
To evaluate whether your startup is worth investing in, you have to be a domain expert. If you're not a domain expert, you can be as convinced as you like about your idea, and it will seem to investors no more than an instance of the Dunning-Kruger effect.
The time to raise money is not when you need it, or when you reach some artificial deadline like a Demo Day. It's when you can convince investors, and not before. Work on your startup up until a week before your pitch before switching focus.
Founders think of startups as ideas, but investors think of them as markets. If there are x number of customers who'd pay an average of $y per year for what you're making, then the total addressable market (TAM) of your company is $xy. Investors don't expect you to collect all that money, but it's an upper bound on how big you can get.
Your target market has to be big (eventually), and it also has to be capturable by you.
Identify some specific trend you'll benefit from.
Usually you can find this by asking "why now?" If this is such a great idea, why hasn't someone else already done it?
Ideally the answer is that it only recently became a good idea, because something changed, and no one else has noticed yet.
The best investors rarely care who else is investing, but mediocre investors almost all do. So you can use the question "Who else is investing?" as a test of investor quality. The best solution is to tackle the problem head-on, and to explain why investors have turned you down (make it clear when you ask that you're not trying to dispute their decision—just that if there is some weakness in your plans, you need to know about it) and why they're mistaken. The most common lie is that while no investors have committed yet, several are about to.
Don't use vague, grandiose marketing-speak in your pitch. It not only doesn't work on them, but seems a mark of incompetence. Be clear and concise, use the words that convinced yourself.
Recipe for impressing investors:
After the 1999 crash, people in Silicon Valley overreacted and learned you had to do things differently to survive.
Believe and practice incrementalism. Grand visions and moving quickly fell out of favour.
Your startup has to be “lean.” You should not, in fact, know what you’re going to do. Instead, you should experiment, iterate, and figure it out as time goes on.
Zero advertising spend. If your growth isn't viral, it’s fake. Eg. PayPal paid new customers and paid for referrals, growth was exponential.
Anti-social was the new social. People wanted to withdraw into a new antisocial modality. Interact with computers rather than people.
Product needed elevation over business development.
Rapid monetization was to be distrusted. Better is a more protracted growth phase and later IPO.
You shouldn’t discuss the future. That will just make you look weird and crazy.
Bubbles arise when there is (1) widespread, intense belief that’s (2) not true.
To understand businesses and startups in present day, you have to do the truly contrarian thing: you have to think for yourself. The question of what is valuable is a much better question than debating bubble or no bubble.
APIs make a product into a Platform. The platformized product will always beat the unplatformized product, all else being equal. They enable third-party developers to predict what users want, and it would happen automatically. You don't need to waste time and money predicting what users want and delivering it, leave that to others.
The most important thing is Accessibility. A product with zero accessibility is a non-existent product. Accessibility and Platforms are basically the same thing, because platforms solve accessibility. A platform is accessibility.
The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything."
Ingredients of a startup:
A bad idea is still a bad idea. The idea doesn't matter as much as the execution, but is still a big factor. Pivot to find the right idea quicker.
Long term planning is a real advantage, as many startups don't think about it.
A good idea is also a business that's difficult to replicate.
If you have several ideas, work on the one you think most about when not working.
To get through the pain of a startup, the company should feel like an important mission.
Good ideas often look bad at the beginning. If they sound too good, too many people are already working on it.
You want to find a small market to quickly create a monopoly, and then expand. You've found it when people depend on it even when it's still a crappy incomplete product.
Reply to criticism: "I know it sounds like a bad idea, but it's not. Here's why..."
Sounds like a bad idea, but is a good idea.
Find a market that's going to be big in 10 years. Investors are obsessed with current market.
Why now? Why is now the right time for this idea?
If it takes more than a sentence to explain, it's almost certainly a bad idea.
Niche clone companies usually fail.
More important than starting a startup, is finding potential cofounders.
Great Idea -> Great Product -> Great Company
Make something people love, then focus on user growth. You'll know people love it when you see organic growth (e.g. word of mouth). If you're waiting on something like a partnership, your product isn't loved and you're wasting time.
Users love simple. You can always make something with a smaller subset than you thought possible. Worry about making it better later.
Recruit users by hand, not adwords. E.g. go to coffeeshops and ask to try product, set homepage in Apple stores, etc.
Ask them what they like and don't like. Ask them what they'd pay for. Ask if they'd be bummed if the company went away. Ask if they would recommend to their friends. Keep a tight feedback loop, super important in early days! Don't hire sales and support people right away - you need to do this yourself first.
Being a founder is incredibly stressful.
CEO has five jobs
Focus is super important.