From 4627a6c59ed8b649ea8d7eb89ced29bfff602906 Mon Sep 17 00:00:00 2001
From: Ben Sima <ben@bsima.me>
Date: Mon, 10 Jan 2022 14:55:14 -0500
Subject: Add stub of dragons bizplan

---
 Biz/Dragons.md | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 Biz/Dragons.md

diff --git a/Biz/Dragons.md b/Biz/Dragons.md
new file mode 100644
index 0000000..30a3d33
--- /dev/null
+++ b/Biz/Dragons.md
@@ -0,0 +1,116 @@
+---
+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.
-- 
cgit v1.2.3