
It's worth briefly setting the context for these essays. Much ink has been
spilled on the topic of finding a good startup idea, validating a product
hypothesis, marketing, sales, and the host of other startup-related topics.

My goal with these essays is not to beat that particular drum.

Rather, these are a response to the numerous times I've been asked over the
years:

- "How do I actually go about building my idea?"
- "How do I find/hire developers to build this for me?"
- "What features should I build next?"
- "How does software development actually work?"

Most developers have faced these questions many times, often from people with
relatively little experience or appreciation for just how hard it can be to
build something from nothing.

The goal of _Zero to Live_[^1] is to go beyond the typical platitudes and give
you concrete rubrics for decision making, ideas for hiring, and practical
insights into how to start building your dream. Real, useful tactics that dig
into exactly what _"just go hire a developer"_ actually translates to in
practice.

[^1]:
    A nod to Peter Thiel's Zero to One book. These essays aim even smaller -
    before you can go from zero to one customer, you need to go from zero to
    live product.


What is Zero to Live?


Hiring your first developer to help you build your company is a critical moment
in your startup journey. There's a big downside risk here - the wrong choice can
have big ramifications down the line, resulting in lost time, wasted effort, and
potentially even taking down your business with it.

It's challenging though - how can you evaluate someone with a skill set
completely foreign to you? How do you know if they are a good developer?

## Get help

The easiest answer here is: have someone you trust who _is_ technical evaluate
the candidates for you.

This is a great option, but unfortunately not viable for a lot people. What
happens if you don't have a network of trusted developer friends to tap?

## But first: do you need to?

It's tempting to dive into hiring ASAP. There's a sense in which building out
the team makes this thing you're working on _real_. Plus, it's exciting! Seeing
your vision become a reality, rallying people to your cause - this is why your
playing the startup game, right?

I've got some bad news: if you're early on (i.e. pre product-market fit), **this
attitude is a siren song**.

It's a romanticized picture that will lure you into wasting time and energy
cycling through ideas and pivots and features while you burn cash.

Instead, you need to focus on how to _learn as fast as possible_.

90% of startup ideas out there **don't need developers to get started**.

I've talked with dozens of people trying to get their idea off the ground that
were convinced that they needed an entire engineering team to get started, when
in reality, a couple spreadsheets and some manual labor would be more than
enough.

Let's look at some hypothetical examples, and show how you might get started
without a developer:

- **Airbnb for RVs**: a spreadsheet of people with RVs, an email address where
  renters can reach you, and you sitting in the middle manually playing
  matchmaker.
- **Appointment reminder SMS service for dentists**: ask for a login to their
  scheduling software, and each morning manually text reminders for the next
  day.
- **Tax & accounting software for cryptocurrency**: offer personal 1:1
  consulting sessions and manually produce tax documents

You can prove out the concept **before you ever write a single line of code**.

This approach does a couple things:

1. It de-risks the project for you, before you go spend a bunch of money hiring
   developers.
2. It helps you learn what really matters to your customers, vs. what you
   _think_ matters.
3. Perhaps most importantly, **it signals something valuable to developer
   candidates**. Most good devs know that engineering talent is in high demand.
   They can be picky about where they work. And you probably can't pay what
   [FAANG](/zero-to-live/glossary#faang) companies will. So when you approach a
   developer with an idea that you've barely made any effort to validate, it
   looks a lot riskier.

## The right mindset

Early on, the ideal developer candidate is one who thinks outside of just the
codebase.

Some developers get into the profession because they love hard, technical
problems. They want to write beautiful code that elegantly solves complicated
puzzles.

You want to avoid this kind of dev.

You want to find a different kind: someone who likes writing code to solve
business problems. Who likes seeing the value they create for customers. Who
doesn't mind shipping slightly messy code if it means hitting the business
goals.

Your first developer needs to be someone who recognizes that **every line code
is a liability, not an asset**.

How can you assess this? Try asking open ended questions about how they would
suggest building out the product.

Do they focus on technology choices ("oh I'd definitely use database X, and
frontend framework Y") or on product choices ("we could probably test product
hypothesis Z without even writing any code by just doing ...")?

And when it does comes to technology choices, do they rationalize their opinions
with reasons why their choices would be good _for the business_? Or is it more
about what's fun / new / exciting? For example: "I'd probably go with this new
framework called FizzBuzz, it's super clean code and lightweight", vs. "I'd lean
towards using Ruby on Rails - it's pretty easy to hire Rails talent, and should
help us get something out the door quickly".

Keep an eye out for someone who talks a lot about scaling concerns early on.
It's _extremely rare_ that a startup needs to care about scaling early on, and
it's usually a far better tradeoff to make technology choices focused on what
lets you _ship_ faster vs. _scale_ faster.

## Contract

If you really think you need developers on board now, consider contracting.
You'll typically pay a premium on an hour-by-hour basis vs. a full time employee
(for good devs, anyway). But the flexibility might be worth it. You can start
and stop contractors, and there's no overhead of dealing with benefits and other
HR concerns.

Contractors also tend to be more experienced at working with you to figure out
requirements and what exactly needs to be built. Full time employees might be
used to having an engineering leader above them setting priorities, roadmap, and
scope; these folks can struggle when dropped into a relatively directionless,
unstructured early startup.

## CTO vs. Lead Developer

You might think you need to hire a CTO as the first engineering hire. It has
that we're-a-real-company ring, and feels like an important step.

But here's the truth: **you probably don't want a CTO**.

It's important to understand some of the nuance in job titles here. Silicon
Valley tends to downplay their importance, but there's something here worth
paying attention to.

Typically, a "CTO" is someone who specializes in running an engineering
_organization_. They know how to balance competing priorites, how to negotiate
with a VP of Sales over the product roadmap, how to hire, how to structure an
engineering org, what metrics to track internally, how to watch for technology
shifts on the horizon, etc.

That is emphatically **not the person you need right now**.

You don't need someone adept at managing and scaling _organizations_ - you need
a hustler who can ship code tomorrow.

Someone who loves rolling up their sleeves and getting in the coding trenches.

Often times, this kind of hustler is the exactly _wrong_ kind of person to
eventually become CTO. Other times, you get lucky and find someone that can grow
into the CTO role as the company grows.

But the skill sets are significantly different, and it's important to set the
right expectations early on.


Hiring a dev as a non-technical founder


It's tempting to think that the code you or your team writes is the biggest
asset the company has. After all - you're a software company, right? You make
software. A auto manufacturer would probably think of the cars that roll off the
factory line as assets, right? Your code is the same thing!

Wrong.

**Your code is a liability, not an asset**.

This is tough for a lot of folks to wrap their heads around initially. Every
time I mention this to people outside the SaaS industry, or to newcomers, I'm
greeted by confused looks.

"Liability - huh? Isn't writing code the whole point?"

Well, if you're reading this blog, that's probably the wrong way to think about
your business. The fundamental problemYou're **not** a software company. Your
company does not exist to write software - it exists to provide a service (the
"Service" in Software-as-a-Service). The "Software" part is an **implementation
detail**.

In a SaaS business, **software is** **the Wizard of Oz**. Pay no attention to
what's behind the curtain. The value you provide is the service the software
enables.

## Why?

Code is a liability because every line you write has an ongoing maintenance
cost, indefinitely. As nearly any developer will attest, code is never
"finished". It never "just keeps on running".

This can be surprising for those without a programming background. It's just
code, right? If it runs once, why doesn't it just keep running?

### Infrastructure

One big reason it doesn't just keep running is infrastructure. To run a SaaS,
you have to host your application somewhere. Some servers need to run your code,
and those servers need to stay running.

### Limits

Sometimes it's inherent hardware limitations. Databases run out of space
eventually, and need to be upgraded. Especially if you continue to grow, you'll
slowly need more of everything: bandwidth, servers, storage, support.

### Bugs

It's extraordinarily difficult (impossible?) to write completely bug free code.
Some of this is attributable to simple human error. Programmers make mistakes -
it's inevitable.

But often times the "bugs" that require ongoing maintenance are the ones that
developers are fully aware of from day one.

You'll see this often when a startup hits the scaling-up phase. Building a
system that handles hundreds of customers is very different than building one to
handle hundreds of thousands. You can cut a lot of corners with hundreds of
customers. These cut corners save you time in the short run - less complexity
means faster to implement.

But in the long run, those cut corners have to be revisited. Your single tiny
database server that worked fine with 50 customers will fall over with 150,000
customers.

## Implications of "code is a liability"

This might sound like a bit of trite wordplay at first - okay, congrats, code is
a "liability" because it has ongoing maintenance costs. Big whoop.

But this distinction actually matters. If you think of code as a liability, it
changes nearly everything about how you approach your SaaS business.

Suddenly, the oft-repeated advice about iterating quickly, learning fast, not
over investing too early in a product before you understand the pain point - all
that advice becomes much more poignant.

Lean startup principles aren't just about _moving faster_. They are also focused
on _avoiding downside risk,_ i.e. ending up with a big codebase on your hands
that isn't solving a real pain.

If code is an asset, that big codebase for a product that doesn't quite fit the
market need is just a smaller win - you didn't quite hit the mark, but hey, at
least we build _something_, right?

But if code is a liability, then that big codebase is **worse than no codebase
at all**.


Code is a liability


A common question I get from non-technical founders is whether to outsource
development of their product, or hire a full time developer.

There's several factors at play here - I'll break them down, along with how each
one contributes to the outsource vs. hire decision:

## Have you validated your idea?

It's easy to fall into the trap of thinking that your app or business idea isn't
"real" until you've hired developers, built out a team, and shipped a product.

In reality, you can do a lot before ever paying a penny for software
development - in house or otherwise.

If you are just starting out, outsource vs. hire is the wrong question to be
asking. The right question is: how do I figure out whether this idea is worth
pursuing? The vast majority of the time, this question can be answered without
any coding.

For example, one founder I worked with was trying to build a kind of Carfax for
specialized industrial equipment. He had various data sources he was planning on
using to build out reports on the history of a given piece of equipment that
would help inform buying decisions. He came to me asking about where he could
hire developers.

My response? Don't.

Start small. You don't need custom software for this - just sell the reports
one-off, and fulfill orders by hand. See if you can sell 10, 20, 100 reports and
compile all the information manually.

This does two things:

1. It validates the space, which gives you the confidence to go spend money on
   building out software to meet the need, and
2. It gives you a product roadmap, for free. Rather than floundering around
   guessing what needs to be built, you just build the features needed to
   automate the most painful parts of your existing manual process.

So - if you haven't validated the idea, don't jump the gun. Focus on what you
can test first, and only once you've reached your threshold of confidence in the
concept can you continue on to building.

## Is your product your moat?

If your product's implementation is what separates you from your competition -
whether that's a great user experience, a truly novel technology, a wide range
of compatibility, or something else - then hiring in-house might be a better
approach.

You'll want to build up that kind of team knowledge in-house, rather than trying
to bring a potentially rotating roster of contractors or agencies up to speed
each time a new feature needs to ship. Building that tribal knowledge in-house
will ensure that any moat you dig stays your own.

On the other hand, if you differentiate yourself by something other than product
implementation - maybe through network effects, fantastic customer support, or a
novel sales strategy - then outsourcing might work quite well. If one
implementation of your product is interchangeable for another, then the
flexibility and scalability an outsourced development team offers can be
appealing.


Outsource vs. Hire


A classic tradeoff faced in early stage companies is "build vs. buy": when
should you build custom, bespoke software vs. buying off the shelf solutions
from third party vendors?

This is important. Choosing incorrectly can lead to months of wasted runway, or
backed into a corner where the next feature needed suddenly involves a massive
rewrite.

If you're a non-technical founder, this can be especially difficult. If you have
devs on the team, how do you know if they are making the right choice?

## Be Aware of the Biases

First let's recognize the biases at play here - if you're a developer, these are
the things to watch for in yourself. If not, these are things to look for in
your team.

### Biased towards Building: Not-Invented-Here (NIH) Syndrome

Developers - especially on the junior side, but even veterans fall prey here -
often suffer from **Not Invented Here** syndrome. And it's understandable - I
catch myself doing this all the time. When you look at third party solutions,
it's easy to see the occasional flaw or shortcoming and get frustrated.

"Why did they add that feature here?"

"These docs makes no sense"

"This would be trivial to build ourselves - there's nothing complicated here"

These reactions all flow from the same underlying attitude that drives lots of
developers: we want to be masters of our craft. To write elegant, efficient code
that solves exactly the problem at hand.

Third party solutions will never be as good as the imagined solution in your own
head. You'll conveniently gloss over the inevitable bugs you'd ship, features
you'd never get to, etc.

This attitude is **dangerous** in startups. What matters more than writing
perfect code is buildinga product that _ships_. A product you can _learn from_
and *iterate on. "*Good enough" is the mantra here.

### Biased towards Buying: Avoiding the Ugly Work

Just as developers want to write beautiful code that solves tough problems,
often times I find myself wanting to avoid the plumbing. A UI developer might
view infrastructure as a boring plumbing problem. A devops engineer might hate
getting bogged down in the fiddely bits about button colors and shadow offsets.

This is probably less common than Not-Invented-Here Syndrome, but it's
stealthier. While NIH manifests as loud complaints about buying XYZ software,
this bias to avoid the ugly work often shows up as calm, mature
acknowledgements:

"Well, \$VENDOR does this far better than we could, might as well leave it to
them"

"\$TECHNICAL_SKILL isn't really in our team's wheelhouse, better to outsource
that to a vendor"

While these can be valid, meaningful responses, it might also be masking core
weaknesses in your dev team's competencies, or a hesitancy to put the business
objectives ahead of working on the more interesting tech.

## Decision Criteria

There's no quick and easy rule of thumb for these build vs. buy decisions. But
there are a few contributing factors worth weighing as part of the decision
making process:

### Is your primary resource constraint time? Buy.

If you're a typical venture-backed startup that has raised an institutional
round - you likely are **cash-rich but time-poor**. Your runway is your
significant constraint, and if spending a bit of cash helps you get to
product-market fit, revenue, and profit faster, it's well worth it. **Consider
buying**.

But if your bootstrapped or early enough that you haven't raised a significant
round, you're in the opposite situation: you're **cash-poor but time-rich**. You
can afford to spend a bit more time if it means you don't have to spend the cash
right now. **Consider building**.

### Is this a core competency or unique value prop for you? Build.

If the functionality you are considering is core to the business, either as a
core value proposition that differentiates you from the competition, or as a
competitive advantage that helps build a moat, that should drive you towards
building.

Often this is most relevant if you are pushing technical boundaries. Building a
new facial recognition service that is better than anything before? Designing a
self-driving car? You probably will need to develop these skills in-house rather
than relying on third party vendors for your core competencies.

But if this functionality is tangential to your core business, and doesn't
really set you apart from the competition or build a better moat around your
business, then buying is the better option. Don't waste time and resources
building something that doesn't meaningfully move the needle on your core
business.

### Do you need to be highly flexible and nimble? Build (maybe).

This one is highly dependent on the buy options in your space, but the
fundamental concern is essentially vendor lock-in.

If you buy a third party solution, you lose control over the functionality and
roadmap of that solution. If you need to rapidly iterate on that functionality
and experiment to find product-market fit - you could find yourself backed into
a corner where the vendor doesn't support your use case any further.

On the other hand, if this functionality is secondary to your core value
proposition and you won't be iterating on it rapidly - that's a great argument
in favor of buying.

### Do you need this ASAP? Buy.

Buying is almost universally faster than building. If you need this
functionality in your product yesterday, than buying is likely the fastest path
to get there.

But weigh carefully what it means to need it faster. Path dependence is a big
deal in engineering, and you can end up kicking yourself a year later that you
went with the penny-wise but pound-foolish buy option to save a little bit of
time.

### Is there significant ongoing maintenance? Buy (probably).

One of the most commonly misunderstood ideas in tech startups (especially by
non-technical founders) is that every line of code is a liability, not an asset.

Code must be maintained. Indefinitely. There is no "finished" point. It's never
"done".

But some kinds of code introduce more or less maintenance liability than others.

Want to add commenting functionality to your app? Congrats, now you need to
maintain a list of profanity that isn't allowed, along with potential machine
learning algorithms to scan for malicious posts, spamming, etc. Or you could
outsource this ongoing effort to a vendor and not worry about it again.

## Example: adding community to Crash

At [Crash](http://crash.co), we wanted to introduce a community element to users
of our platform. Building some kind of chat or discussion forum is one of those
features that seems deceptively simple at first, but rapidly turns into a hairy
mess. Cross device notifications, multi-language support, access roles, mobile
apps, ... it could have easily become a multi-month effort (buy).

But we knew that community features, while a great addition, were not the core
value of our app. It was the icing on the cake (buy). Furthermore, we knew that
we were probably not going to try to innovate there. Standard community features
would be more than enough, and we'd be fine with whatever a good vendor might
provide (buy).

So we ended up using a couple different solutions (Mighty Networks, and then
Slack), all without needing to spend a single engineer's day on it.


Build vs. Buy


What to build next is a perpetual challenge for early stage products. There's a
universe of possible features to build, bugs to fix, tests to run - **how do you
know what to prioritize?**

In my experience, there's **2 factors** that go into prioritization decisions
early on:

## First factor: Customer demand

What are customers asking for? Hopefully you're talking with your customers on a
regular basis - what are they wishing existed? There's a couple things to keep
in mind here:

### Niche down to prioritize

Balancing and prioritizing the various feedback you get from customers is
tricky.

If your feedback has some common theme across most of your users, that's a great
sign - it means you've found a cohesive market segment, with similar pains that
your product could solve. Double down on those pain points (assuming the align
with your strategic direction).

But what about when the feedback you get varies wildly? It seems like every user
you talk to wants something different, and there's very little overlap. This is
usually a sign that your product is too "horizontal" - that is, it serves many
different possible use cases. For early stage products this is usually a bad
idea. Horizontal products are difficult to make into truly _amazing_ product
experiences, because you can't serve all use cases equally well.

When you find yourself in this "horizontal product" trap, it's often best to
niche down further. Pick one promising subset of your audience and build for
them. Keep narrowing down until you start to see consistency in the feedback -
that's when you know you've found a cohesive segment you can build for.

That doesn't mean you have to restrict yourself long term to that niche either -
this approach makes for a great "land and expand" strategy, where you focus and
dominate one niche first, then expand to adjacent niches gradually.

### Pressure indicating UI

There's a valuable lesson to be learned from the House M.D. show:

> ~~Patients~~ Users lie

Joe User says he loves your product, and can't wait to use it as soon as you add
feature X. You dive in, spend days or weeks on engineering time building it,
excitedly email him that his wish has been fulfilled, and ... crickets.

Or worse: he replies with "Looks great - now I just need feature Y to get
rolling!".

What happened?

_Users lie_.

It's often not intentional. Sometimes people lie to be polite, or to avoid
embarrassment, or simply when they don't have a good answer to your question. No
one enjoys being the fool.

But those lies distract you.

Then send you down rabbit holes, chasing phantom features that won't actually
make a difference.

**Pressure indicating UI** is a tactic to help cut through that noise, and get
to what users _really_ want. It's based on the concept of **stated versus
revealed preferences**.

We often do things that contradict our stated preferences. We say we want to
lose weight, but we don't exercise or eat better. Our revealed preference is to
keep the weight, eat what we want, and not exercise.

Pressure indicating UI is designed to avoid the trap of chasing stated
preferences, and instead get at the true, revealed preferences of your users.

There's two kinds of pressure indicating UI to know about: **pressure gauges**
and **escape valves**.

### Pressure Gauges

A pressure gauge UI is a piece of user interface that tells you, the product
owner, what people are interested in. It's the weaker form of pressure
indicating UI, in that it doesn't help the user achieve what they want right
now. But it's easier for you to ship quickly.

Let's take an example: you are thinking about adding an "invite a co-worker"
feature to your app that would send the co-worker an invite with a link that
sets them up in the app.

You're not sure if this will be valuable - you've had some requests for
something like this from existing users, but you aren't confident people would
actually use it. Maybe it's really useful, or maybe when it comes to it, users
don't actually mind copying invite links manually.

A pressure gauge for this might be a simple "Invite a Coworker" button you add
to the UI that records who clicks on it. When it's clicked, you pop up a message
saying the feature is coming soon, and offer the user the option of getting
notified when it ships.

This lets you get a **real, unvarnished** sense of who wants to use this
feature. And it even builds a list of eager early adopters - great candidates
for beta testing or evangelizing the feature when it ships.

The danger, of course, is abusing this pattern to mislead users. Be careful that
your pressure gauges don't deceive users into assuming certain critical
functionality exists, just to have them realize it doesn't right when they need
it. In other words, don't test your "restore from backup" feature this way.

### Escape valves

Escape valves are features that give those users desperate for some
functionality a "way out". It lets them get what they need out of the product,
at the cost of a bit more legwork on their part and with very little investment
from you.

My favorite example of this is the humble "notes" field. Just a simple, plain
text input that lets users add their own notes to records in your app.

It's great.

And **it's great precisely because it's not good UI.**

A notes field is a fallback. A catch-all.

It's an admission that your app doesn't let the user track everything they need
to, so it's giving them an escape valve to add a little bit of their own
functionality to things.

This gives you two main benefits: first, it lets you support users who love your
product except for that one missing feature - that one missing field or value
they want to track. They can track that on their own now!

But more importantly: **it lets you see the pain**. How people use the notes
field will show you what's missing. And as you start to see patterns ("Ah, looks
like lots of people are adding the last phone call time to the contact note's
field"), it gives you a roadmap of what to bake into the product as a
first-class feature.

## Second factor: Strategic direction

Building great products is a balancing act. There's a equal measure of meeting
people where they are today, juxtaposed with building for the better future your
users aren't even imagining yet. As the apocraphyl Henry Ford quote goes:

> If I had asked people what they wanted, they would have said a faster horse -
> (not) Henry Ford

This first factor of prioritization is customer demand: what your customers want
today. The second factor is strategic direction: the better future you are
building towards.


What to build next


[Eating my own dogfood](/zero-to-live/glossary#dogfooding) here!

This page is a form of
[pressure indicating UI](/zero-to-live/what-to-build-next). If this topic
interests you, drop your email below to get notified when the essay goes live!


Should we build with X?


Your product development is chugging along, the team is chipping away at the
roadmap, and things are looking good. Then your lead developer approaches you
saying they need to take the next week or two to do some major "refactoring" to
clean up some "tech debt" (whatever that means). What gives?

## Technical Debt

As software is built, features are added,

[Eating my own dogfood](/zero-to-live/glossary#dogfooding) here!

This page is a form of
[pressure indicating UI](/zero-to-live/what-to-build-next). If this topic
interests you, drop your email below to get notified when the essay goes live!


Beware of technical debt and rewrites


So you've started to hit some traction: you're seeing new customers roll in, new
demands and feedback, new revenue - everything is up and to the right.

But you've probably started to notice a few things:

- Your customers are finding more bugs. Not just because it's more customers,
  which means more eyeballs to discover problems, but there seems to be actually
  more problems occurring as well.
- Your developers are stressed, trying to keep up with the growing demands and
  traffic.

Congrats - you've got a good problem to have. But it's still a problem, so let's
dive in and talk about scaling ...

## What is scaling?

"Scaling" is the process by which a software product grows to handle growing
activity levels. This can mean different things for different apps, but it's
usually pretty intuitive: more users = more your app has to do.

Today, most people have experience using apps that routinely see _massive_
amounts of activity. Think: Facebook, Google, Twitter. These apps easily serve
_millions_ of users _per day_ without breaking a sweat.

So why is your app struggling under the load, when these other sites don't have
a problem?

## Scaling is complex

It can be tempting to compare your app with these tech heavyweights, and get
frustrated when your app seems to fall short. But it's important to remember the
different in resources: these tech heavyweights each have entire _departments_
within their engineering organization devoted to keeping the app up and working
24/7.

You're working with a much smaller set of constraints.

But it's also important the different ways software can scale:

## Why can't we throw money at it?

Especially if you have some funding, it's tempting to think you can just throw
money at scaling issues, at least for now. Buy more servers = handle more
traffic, right? It's the cloud, after all ...

The problem here is that software can't always scale by simply throwing more
hardware at it.

Think of your app as a restaurant kitchen: up to a certain point, you can simply
hire more chefs or buy more ovens to increase your food production ability. But
eventually, you're going to hit certain realities that can't be circumvented:
the rice won't cook _faster_ because you have another range.

Similarly, software can sometimes scale by simply buying more capacity, but
eventually bottlenecks will be revealed, and it will require more significant
engineering work to grow further.

### To be continued ...

[Eating my own dogfood](/zero-to-live/glossary#dogfooding) here!

This page is a form of
[pressure indicating UI](/zero-to-live/what-to-build-next). If this topic
interests you, drop your email below to get notified when the essay goes live!


How software scales


Here's a brief rundown of some vernacular that's helpful to know when talking
with developers.

### Dogfooding

_Also: "eating our own dogfood"_

Using your own product as a customer might. This helps you discover bugs,
missing features, and other issues that your customers might encounter.

### FAANG

Stands for Facebook, Apple, Amazon, Netflix, and Google. Usually used as a
shorthand for referring to stereotypical large, tech-heavy Silicon Valley
companies.

These companies tend to pay high salaries and attract top tech talent, so you'll
need to think about how to position yourself vs. them when hiring.


Should we build with X?

How to respond when your developer wants to use a particular code framework