Engineering

A startup is a business built to grow extremely fast. Rapid growth requires using a new technology to invalidate the assumptions of incumbent politicians and businesses.

An internet startup has the ability to grow very, very fast and scale to large markets. It can start in a dorm room and scale to the entire world, accepting payments and providing services to anyone on the planet, without need for natural resources, expensive permits, or human clerks.

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.

These seven stages are like a map for making ideas into reality. At each stage, many startups fail to make it to the next stage because of time requirements or some unseen flaw.

Stage	What’s required to complete?	Minimum Time
Idea	Napkin drawing of billion-dollar concept	1 minute
Mockup	Wireframe with all the user screens	1 day+
Prototype	Ugly hack that works for single major use case	1 weekend+
Program	Clean code that works for all use cases, with tests	2–4 weeks+
Product	Design, copywriting, pricing, physical components	3–6 months+
Business	Incorporation, regulatory filings, payroll, etc.	6–12 months+
Profits	Selling product for more than it costs to make	1 year + onward

Startup engineering means getting something to work well enough for people to buy it. Engineering in this sense is distinct from academic science, which requires something to work only well enough to publish a paper. Startup engineering is also distinct from engineering theory of a different kind: planning for an infinite number of users before the very first sale. Between the extremes of zero customers and infinite customers lies startup engineering, where the concern is shipping a sellable product.

One of the primary things a startup engineer does is systems integration—keeping up on new technologies, doing quick evaluations, and snapping pieces together. Some say choice of programming language doesn’t matter because a good engineer can do anything with most reasonable technologies. In theory, this might be true; Turing-Complete languages can perform any action. In practice, choosing the right tool or language can be like the difference between going to the library and using Google.

In the early days of a startup, you want to choose the best technologies available and innovate on only one thing: your product. Building version one of your product is unlikely to mean creating a new web framework, for example (unless you are a company that sells the web framework). Outside of your business’s core technology, you want to be as boring and vanilla as possible until you begin to make a serious profit from your first product.

You can quantify the quality of a user interface by the number, type, and duration of user inputs required to achieve a result.

To ship a product, a startup engineer needs versatility. If you are a founder, you will need to handle things you’ve never thought about before. When you walk into an engineering class, the lights are on, the rent is paid, and you can focus on understanding code that someone made simple for instructional purposes. But when you start a company, you’re responsible for calling the electrician to get the lights working, finding the money to pay the rent, and pushing the envelope of a new technology no one else understands.

At the beginning you have no product, no money, and the lights are off. Getting people to quit their high-paying jobs to work with you for free can be challenging. You’ll need to be able to produce a passable logo, design the first landing page, and do initial sales calls—all while moving technology forward.

When building and selling your early product, sometimes changing direction is the right answer. But sometimes you just need to persist. How do you balance these? One approach is bounded commitment.

List your options, choose your best one, and commit for a predetermined period of time—like a week or a month. Then revisit. This is similar to how sprints work in agile software development and similar to balancing depth-first versus breadth-first in search algorithms. The key is thinking of your time as a resource to quantitatively allocate, like capital.

SaaS first, code second, hire last.

If at all possible, do your first version with off-the-shelf SaaS tools, even if the interface is ugly. People will tolerate it if it’s functional. If you get some traction, you can code a nicer version or automate. Only then, if you can’t automate a process, should you hire someone.