Startup Chronicles: From Conception to Market Dominance (Part 1)

This series of articles is going to cover the process of developing your SaaS product from idea to marketing. We are going to start with identifying the unique problem of our end user, then develop a minimum viable product, and finally deploy our MVP. Our final product is going to be solving a definite problem for our end user.

Problem Statement

Roboticists and embedded system engineers work on different projects to improve their proficiency. However, due to the limited human memory, it is difficult to manually track the inventories of material used in a particular project.

Manually sorting and jotting material for a particular project takes a moderate percent of their weekly work time (40 hours/week). Also, some pet projects get abandoned probably due to some unforeseen issue, and the materials for that project are mixed up with the rest of other materials.

Mr. James, the owner of XYZ company in the Robotics sector, wants to maximize the use of his employees’ time and also have a centralized solution to view the materials available for each team, and project.

System Design

From the problem statement above, we see there are a lot of moving pieces, we need a pragmatic approach to such a problem. To start with, we will need to outline the stated requirements. We will categorize the requirements as functional requirements, non-functional requirements, and extended requirements.

Functional Requirements

• Account for the items used in a project, and their status

• Admin/Manager should View the materials used by a team on a project and also manage the project status.

• The process of adding or searching for an item should be seamless

Non-Functional Requirements

• The system needs to be up all the time (High availability)

• The system should be durable and consistent.

• If there is an upsurge in the number of employees/projects the system needs to be scalable

Extended Requirements

• Admin/manager should be notified about items/materials that are about to be exhausted

Resources Estimation

Estimation and approximation help prepare for rainy days, there are different resources we need to estimate, the notable ones are, storage estimation, Bandwidth estimation, and server estimation.

Given these assumptions about the system:

Total components present at the moment = 10,000
Average Size of each Item data and metadata = 10kb
The average size of each item image = 1MB
Therefore, the average size of an item === 1MB
Daily active users (DAU) = 1000 (assume current staff strength of XYZ)
Total components that will be added daily = 1000
Read to Write Ratio of Items = 10: 1

We will make some estimations about the storage, bandwidth, and the number of server instances we will need.

Storage Estimation

$$StorageDaily = DAU * size of Item * ItemsAddedDaily$$

The relation above shows how to calculate the storage used for a day for storing an item.
For storing the Item’s text data and metadata,
the storage required = 1000 x 10 kb x 1000 = 10GB

For the Image of items = 1000 x 1 MB x 1000 = 1 TB

Therefore, the total storage required per day == 1TB
And for a year, 365TB of storage is required

Bandwidth Estimation

Bandwidth refers to the network speed required for an operation.

$$IncomingTraffic = TotalStoragePerDay * 8 / Number of Seconds In A Day$$

For incoming traffic = 1 x 10^12 / 86400 x 8 = 92Mbps = 0.9Gbps

Given the Read to write ratio of 10:1, that is for each write, there are 10 read, so for 1000 write per day, there is an estimated read of 10,000. But let's assume that each user checks at most 20 items per day

$$OutgoingTraffic = (DAU * ReadOfAUserPerDay* SizeOfItem * 8) / NumberOfSecondsInADay$$

Traffic for viewing only the items text data = 1000 x 20 x 10kb x 8 / 86400 == 20kbps == 0.2Mbps

Traffic for viewing only the items image data = 1000 x 20 x 1MB x 8 / 86400 == 2Mbps

The total bandwidth, assuming the uploaded content is not compressed = 2Mbps + 0.2Mbps = 2.2Mbps

N.B: The 8 shows network traffic is measured in bits, not bytes, and 8 bits = 1 byte

Server Estimation
Using The typical server used by Facebook, with specifications of 256GB RAM, 45MB Cache (L3), 15TB SSD storage, 36 cores, and 2 sockets, This server can take 8000 Requests per second. But due to cost constraints, we will be going for 4GB RAM, 10MB cache, 1TB Storage, 8 cores, and 1 Socket.

We will need to calculate the Request Per Second (RPS) of our system based on the specs of our intended server shown above,

For a request that will require our CPU usage, let’s assume the total time of execution of the request is 100ms,

The relation for calculating of RPS of CPU bound request is shown below,

$$RPScpu = (NumberofCores* NumberOfSockets )/Task Time in seconds$$

Therefore, RPS of CPU =8 x 1 x 1/ (100 x 10^-3s) = 8 / 0.1 = 80 RPS

For a request that will require memory usage, let’s assume an execution time of 50ms, and the memory for each worker in our memory is 100 MB.

The relation for calculating of RPS of memory bound request is shown below,

$$RPSmemory = RAM size/(Size of a Worker * Task Time in seconds)$$

The RPS of Memory = 4GB / (100MB x 50 x 10^-3 s) = 4000MB / 5MB = 800 RPS

Therefore, the average RPS of our server = RPS of CPU / 2 + RPS of Memory / 2 = 80/2 + 800/2 = 40 + 400 === 450RPS
The Number of servers we will be required for our use case = Daily Active User / RPS of Server = 1000/ 450 == 2

Business Model

All the calculations above are necessary, but we need to switch hats and see if this sojourn will be a profitable one. We will be using the Odyssey 3.14 approach to model our business

Value Proposition
The main value provided by this solution is to reduce our client hassle on managing inventories, and also provide a bird eye view of materials used by teams. Also, we can benchmark our value proposition with existing solutions in the market, and develop a unique offer to our end users.

Value Architecture
First of all, we are trying to help Mr. James manage inventories, but he is not the one in the warehouse noting all the inventories, the end users of our system are the engineers and warehouse manager.

Some questions such as:

• how does the end user upload a new item?

• how to search for an item?

• How does each team currently manage their inventory?

• How do we prevent duplicate items from being uploaded?

• how do we account for a single item that has different variations?

• Since there is an existing inventory system used by each team already, how will we combine the inventories used by various teams into our centralized system?

• In case of faulty items, does the system give a channel for the end user to report this fault to the product manufacturer?

  These are some of the questions that will guide us while building the system, although, we might not be able to figure out a perfect solution to each of the questions at first, a patchy solution to each of the questions listed above is a step in the right direction

Profit Equation

Although we are building an in-house solution for XYZ, let’s take a look at the bigger picture if we want to commercialize this product.

The cost implication for our estimation and infrastructure aside from the development cost can be gotten from cloud providers. Amazon, Azure, and AWS are some of my favorites.

The simplest way to get revenue for our product is by end user subscription, probably monthly, quarterly, or annual subscription. However, since the intrinsic value of our product is abstract, We can make this solution a platform, where we include an avenue for manufacturers to integrate and pitch their products to our users. And these manufacturers pay some fees to us. There are other ways of generating income, but our revenue streams can be improved and updated with time.

Now for the next part of our series, we will get our hands dirty by building the Minimum viable product (MVP) for our idea.