# Fireproof business plan

### Executive Summary

Fireproof Storage is a realtime database solution that solves the challenge of writing interactive apps by offering a [cloudless protocol](https://purrfect-tracker-45c.notion.site/The-paradigm-shift-to-cloudless-computing-4cec85a9ea454d52b0fef0229807c9fc). Targeting developers, the key differentiator is that it's cheaper, scalable and verifiable compared to existing commercial realtime database services. The revenue model is based on charging enterprises for premium features. The market opportunity is estimated to be $20 billion with a CAGR of 15.7%. The goal is to capture a significant portion of the market share.

### Product

Product roadmap includes identity management, database APIs and a proof-of-concept app. Database operations are serialized by clients as [UCANs](https://ucan.xyz) and [IPFS CAR-transactions](https://github.com/mikeal/car-transaction), and routed by peers to Fireproof for verification and sequencing. Transactions can be applied by any peer due to cryptographic verifiability. The developer experience is based in React and other application components, so developers can get started without learning new APIs.

### Team

The founders have extensive experience in low-level protocols and understanding customer needs. One of the founders is a seasoned entrepreneur who co-founded Couchbase, which successfully IPO'd in the database industry. This expertise has been invaluable in their research and understanding of the realtime database landscape.

The current team structure includes software engineers with deep experience in the problem space, with plans to expand and add a frontend developer, an interaction designer, and marketing roles to support growth

### Marketing and Sales

Fireproof's go-to-market strategy focuses on attracting app builders by providing [simple UI widgets that make development fast and easy.](https://hackmd.io/@j-chris/SyoE-Plpj) Positioning the product as free is a key aspect of the strategy, aimed at attracting a large customer base. The target customer segments are React developers and mobile app developers who are looking for a shared interactive data solution across devices, and face the pain points of difficulty in syncing data across devices and the high cost and slow speed of existing solutions.

To generate revenue, Fireproof offers premium features and enterprise support, with roughly 50% of revenue expected to come from these sources. The company is tracking key metrics such as the number of apps, users, and transactions, total data volume, and number of qualified leads to measure success.

The initial go-to-market strategy is to gain traction and adoption with app builders and then scale up with targeted marketing campaigns aimed at technical buyers and decision makers in target enterprises.

### Financials

The company's financial projections are based on a period of 18 months and a simplified early stage operating model. The revenue for this time period is expected to be zero, and the main expenses will be talent costs, cloud services, marketing, and equipment.

The talent costs are estimated at $250,000 per year, per person, with a total of 4 people. The cloud expenses are expected to be less than $100,000 per year, while marketing expenses will be approximately $60,000 per year.

These projections are based on the assumption that the company will receive free storage from web3.storage and will see a viral growth in developer sign-ups through word-of-mouth, driven by conferences and media. As the company grows and achieves product-market fit, expenses may change as sales and feature engineering expand, but these changes have not been incorporated into these projections.

Based on these projections, we estimate that raising $1.5 million would be enough to prove the hypothesis that we can attract viral developer growth to a cloudless realtime database product.

### Metrics

In order to gauge the success of the realtime database solution, the company will be tracking several key metrics. These metrics include the number of apps using the solution, the number of users, the number of transactions processed, the total amount of data being stored, and the number of qualified leads generated. By closely monitoring these metrics, the company can assess the adoption and effectiveness of the solution, and make data-driven decisions to drive growth and improvement.

### Use Cases

Verifiable data enables cloudless business models, which are a good fit for a lot of the new ways data is accelerating. Data owned by users, stored in a location independent way, is simply less work to think about. The status quo is having data that is in a location, and not in another place. Cloudless data and compute mean you rarely have to move data to work with it. With a distributed protocol you have no lock-in and total location independence. Centralized concerns are currently hampering normal use of data.

- The move from user-created video, to user-prompted AI-generated video
- The laregly unmet desire to store AI inputs and outputs along with cryptographic signatures attesting model versions, etc
- Social media apps made by and for communities
- Chat and communication
- Metaverse
- IoT sensor, edge network, distributed BI
- Shared analytics workloads

## Architecture

### Data Transactions

The realtime layer in Fireproof enables the sharing of content-addressed immutable CAR-transactions between peers. These transactions contain updates to data structures, stored as IPFS blocks and referred to using content identifiers (CIDs). The core data structure in Fireproof is a Prolly Tree, which is a type of B-Tree that ensures efficient replication as the data changes. The order of updates to the data structure is tracked using a Merkle Clock, which is similar to a vector clock. This mutable pointer to the current version of the Prolly Tree is signed and broadcast by an agent with a UCAN signing principle, which can be tied to an email address. This allows for delegation of authority, enabling collaborative updates to the data structure. The whole package of updates, including the UCAN header, can be stored and forwarded, enabline Fireproof Storage to create a marketplace for services.

The query layer uses a GraphQL like interface to make interoperability easy with other front-end tools. The data path has a seperation between the block level (CID) layer, and the CAR-transaction layer. Transaction broadcast and persistence is decoupled from validation and application.

1. The user makes a change in the UI.
2. The change is captured as a GraphQL mutation by its associated resolver.
3. The resolver writes the update to the prolly tree, which returns a new root CID.
4. The resolver generates a new UCAN entry and sends it to the mutable pointer Merkle clock.
5. The mutable pointer validates the update, via a pluggable deterministic Javascript function, and adds the new prolly tree root CID as the new current value of the Merkle clock mutable pointer, if validation passes.
6. The blocks for the prolly tree update and for the mutable pointer update are wrapped in a CAR-transaction with appropriate UCANs.
7. The transaction is broadcast to other users over the network, and saved to Filecoin via web3.storage.
8. When a user receives the broadcast, they validate the UCAN cryptographic proof, in if the deterministic JavaScript validator passes, apply the pointer update locally, triggering an event.
9. The event triggers a GraphQL refresh, which is resolved by loading the latest version of the data from the prolly tree.
10. The resolver returns the updated data to the UI, where it is rendered and displayed to the user.

The path of a data update in Fireproof involves multiple steps and layers, from the user's UI, to the GraphQL API and resolvers, through the prolly tree data structures, and finally to the UCAN-based CAR-transactions for persistence and synchronization across users. At every step, the data is validated and verified using cryptographic proofs, ensuring the integrity and consistency of the updates across the system.

### Identity & Authorization

Updates are authorized by including signed UCAN invocations with proofs that link back to capabilities and delegations. For instance, an author might delegate the ability to modify the mutable pointers associated with an article to other collaborators, and the mutable pointer associated with the comments to anyone with a valid UCAN signing principle.

In the case of the comments mutable pointer, users will be limited to only creating comments or deleting comments they have created, and the comment will be required to adhere to an expected schema. To implement this, each mutable pointer has an associated piece of JavaScript which can return true or false if the incoming update is allowed or blocked.

### Indexes & Events

Indexes are written by functions which subscribe to the merkle clock mutable pointer, and run over the data in the incoming diffs. They maintain their own prolly trees and mutable pointers. In this way when any peer computes an index update, they can broadcast the association between root cid and index cid.

Let's call the construction of prolly tree changes in car transactions being orderd by the merkle clock mutable pointer (merkle log) a merkle history. You'd traverse the history absorbing new events into the index. If the history order changed, you roll the index to the last stable point and re-apply. (Or maybe diff the old to new in a more efficient way.)

## Premium Features

Customers can access additional premium features by providing a credit card that unlocks metrics such as the number of users in their app, total data volume, and transaction rates. Certain premium features are available at an additional cost that scales with the database usage. This allows customers to only pay for what they use, ensuring that they get the best value for their money.

Enterprise users have the option to sign up for access to the Customer Council chat server. This premium support package costs $1000/seat/month, which includes access to the full feature set. With 50 seats, for example, an enterprise customer spending $50k/month on usage-based premium features and $50k/month on premium support would represent approximately $1M in annual revenue.