---
title: Dragons Biz Plan
---

Mission: to minimize developer inefficiencies.

# Problem

Tech debt is a costly liability for medium-to-large developer teams. It's also
mostly hidden: the only people that can identify tech debt are the ones tasked
with fixing it, and by that time it is too late.

# Value proposition

Dragons.dev makes tech debt explicit, by identifying it, quantifying it, and
making it visible even for managers that are not familiar with the codebase.
This way, it can be mitigated and managed before it becomes a problem.

# Growth plan

## Unicorn requirements

Let's assume a 7x valuation multiple. If each user brings in $500/yr of revenue,
then, if we want to be valued at $1B, we need around 285k users.

- $1B / 7 = $142,857,142.86 revenue per year
- $143M / 500 = 285,715 active users per year

According to [Slashdata][], there were 13M software developers in 2019.
Therefore, a 1B valuation would require capturing 285k / 13M = 2.1% of the total
market.

[Slashdata]: https://slashdata-website-cms.s3.amazonaws.com/sample_reports/EiWEyM5bfZe1Kug_.pdf

Of course we would not start with the total market, rather we would plan to grow
out of a niche market to begin with. But this is a good estimate of the upper
target.

### Sales penetration

To get into the market, we'll have to sell on a team-by-team or
company-by-company basis. It does not make sense for an individual developer to
use Dragons.dev anyway. The size of each "sale" then is highly variable, because
team and company sizes vary, so modeling sales penetration on a discrete axis is
not likely to work. Instead, a continuous exponential function can be used. Lets
say after 10 years we want to be a unicorn with 285,715 users, to get there
exponentially:

    10 = log_x(285715)

Solve for x:

    10 = log(285715)/log(x)
     x = 3.5123

For an arbitrary year:

     n = 3.5123^x

where x is the year and n is the number of users.

This means we need to be growing at a rate of 3.5123x per year. If we explicitly
lay out the user growth on a 10-year timeline, we get something like this:

| year | users needed | revenue     |
| ---- | ------------ | ----------- |
|   1  |           4  |       2,000 |
|   2  |          13  |       6,500 |
|   3  |          44  |      22,000 |
|   4  |         153  |      76,500 |
|   5  |         535  |     267,500 |
|   6  |       1,878  |     939,000 |
|   7  |       6,594  |   3,297,000 |
|   8  |      23,160  |  11,580,000 |
|   9  |      81,344  |  40,672,000 |
|  10  |     285,704  | 142,852,000 |

## Support requirements

In order to support 285k users, what would we need?

### Tech infra

Each team is probably 10-30 users, and they will be pushing code probably 10x
per day. So lets assume with 285k users there will be 285k analyses submitted to
our servers every day. If they are mostly US-based, then let's say the time of
peak submissions will be between 9am EST and 9pm PDT, or about 15h total. The
submissions won't be evenly distributed, but lets just assume they are. This
comes out to:

- 19,048 submissions per hour, or
- 318 submissions per minute

Our existing codebase can probably handle this if run on dedicated hardware in a
colo, but as we grow we can do load testing to ensure we are ready, and upgrade
subcomponents of the codebase as needed.

### Customer support

How many customers can one support staff person handle? 100? 1000?

In order to be profitable, one support staff person would need to cost less than
the number of customers they can handle. So if we pay a support person $100k per
year, then they must handle 100000/500 = 200 customers _at least_. Ideally it
would be closer to 5x that amount, or 1000 customers, so we have room in the
budget for engineering and other things.

So lets assume one support person must handle between 800-1000 customers, that
means to support 285k users we would need between 285-356 customer support
people. That seems like a lot.

Of course the load on support can be minimized at the product design stage,
where errors are automatically handled or guarded against to begin with. And
this only identifies the upper limit of how many support people we could need;
ideally, we would minimize this number as we grow through management techniques,
automation, creation of a self-service knowledge base, and so on.