diff options
| -rw-r--r-- | Biz/Dragons.md | 116 |
1 files changed, 116 insertions, 0 deletions
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. |