How to Prototype an Internet Startup

An illustration of how to prototype an internet startup using the generic business model prototype

• The prototype should be as SIMPLE as possible, yet still COMPLETE. We want to create the simplest possible prototype of a „generic“ business – the prototype should be easy to understand and not make any assumptions about a specific business, yet still, cover all aspects of a company’s value creation logic.
• The prototype should cover both BUSINESS MODELS and PROTOTYPING. The prototype should help us learn more about business models and also how to prototype different aspects of a business model, using the System Dynamics modeling and simulation approach.
• The prototype should be used as a BUSINESS EXPERIMENTATION LABORATORY. The prototype should allow as to experiment with different business scenarios. The idea here is to use the business prototype as a framework that can quickly be adapted to specific situations – experience shows that it is rarely necessary to model every aspect of a business in detail to answer a given question. So you can use the framework as a basis and elaborate those aspects of the model that are relevant to the problem at hand and thus rapidly create a business simulation.

• How much money should we be spending on marketing?
• How much capital should the company have initially?
• Will we need debt financing?

• Our company is an internet startup started by two founders who act as managing directors.
• Next to the founders, there is a small development team consisting of one product designer, a product developer and a product tester. We also have two customer service agents who deal with support requests.
• Our development team is capable of delivering twenty-five new features per year. For now, we are happy with this target output, so we do not expect the development team to grow.
• The number of customer service agents we need depends on the number of customers – the assumption is that every client posts one service request per month and that it takes ca. 10min to deal with a service request. So if we win new customers, the number of service requests will rise and thus the customer service team must grow. When the team grows, we will also need to add team management capacity. Our assumption here is that we need one team leader per thirty customer service agents.
• The number of product designers grows with the number of customers – the assumption is that 1% of all service requests are actually ideas for new features. It takes a product designer 10min to qualify a feature idea. When the team grows, we will also need to add team management capacity. Our assumption here is that we need one team leader per fifteen product designers.
• Our revenue comes from a monthly subscription fee of €20 that each customer pays. We assume the average collection time is two months, i.e. it takes two months until the revenue is collected and the cash arrives in our bank account.
• Our main costs are the wages for the team (€ 3000 each per month) and the two founders (EUR 6000 each per month) and also for the infrastructure equipment we need to deliver the service. We also assume that we will spend EUR 20,000 per month on marketing.
• We assume we will reach 100 customers per euro spent and that 0.01 percent of those will buy our product. So we need to spend around EUR 100 per customer. To keep the discussion simple initially we assume that we do not lose customers once we have won them.
• Next to our initial shareholder’s stock of EUR 700,000, we assume that we have access to debt financing to keep the operation going. New debts will be added as needed according to our cash coverage policy, to ensure that we have enough cash to cover our payments. Initially, the cash coverage policy is set to three months. Debt is repaid monthly over a period of five years at an interest rate of  5% per annum.
• Our simulation will cover a time span of five years, all calculations will be performed on a monthly basis, the monetary unit in the model is k€ (€1,000). One month is assumed to have 20 workdays.

1. For the first three months, the cash flow drops fairly strongly. This is because the company incurs expenses (such as marketing expenses) in the first month of operation but does not actually meet its obligations (i.e. pay its bills) until the second month.
2. After two months, the cash flow starts improving – this is because we are gaining customers and revenue, without changing our monthly cost.
3. After about nine months, our stock of cash is depleted and our cash coverage policy (which is set to two months) kicks in: we start taking up debts in month 10, peaking in month 11, and do not stop taking on new debt until month 21 – you can see this best if you look at the debt cash flow in the financial statements (see screenshot below)
4. Our cash coverage policy then ensures that the cash flow is almost constant because it ensures the gap in operating cash flow is filled with new debts.
5. At last, at month 19 our operating cash flow becomes positive and at month 21 we have accumulated enough cash to stop taking on new debts – the cash flow starts to increase.
6. At month 44 our cash flow suddenly drops – this is because our company has to pay tax for the first time.

Note: Despite calibrating the model to a specific situation we need to ensure that we do not compromise the generality of the model. We will do this by ensuring that we model each aspect in the most generic way – this should not be too difficult because we are modeling a startup with a simple structure and a single product. Once we have covered all aspects of the prototype we can then calibrate the model to a different kind of business to test whether it is really generic. If yes, all is well. If not, this will be an opportunity to learn something new and improve the model.