In January we kicked off the year and quarter with the whole team. We could really feel the young and crazy startup transforming and maturing to build a strong solution. As a network, Request must aim at long-term solidity. In this article, we describe how we have adjusted our balance to go from unlimited inspiration to structured and managed innovation.
Before we enter this story, we want to announce the departure of Elliott. Elliott was part of the founding team, we owe him a lot and take this opportunity to thank him publicly. We wish him all the best for his future career.
Also, over the last weeks, we welcomed three new members to our team:
- Lucas, who has joined the protocol tribe as a junior blockchain engineer.
- Adam, a legend in the Request community. Having contributed a lot since the beginning, this recruitment was thus a very natural move. Adam keeps being involved with the community and joins the apps tribe as a full-stack developer. We are very happy to have him give future partners an internal point of view.
- Laurent, who has joined the apps tribe as a full-stack developer.
We are very happy to attract such a diversity of excellent profiles. We are also slowly re-opening positions again. Stay tuned.
Now, based on Request’s vision for the next five years, let’s look at 3 key questions that define the success of an open network for requests of payments:
- How to make Request adopted short-term?
- How do we clarify our positioning?
- How to make Request last?
Let us tackle these questions one by one.
Regarding short-term adoption
Businesses can only accept a network for payment requests if it is secure, fast, easy to integrate, stable, and globally cheaper than their current solution.
For speed and security, quality is key and an open-source code brings transparency, trust and diversified sources of improvement.
For ease of integration, having our own internal clients (the apps tribe) is a good start. This year we will initiate different pilots to get a diversified set of integration inputs from external actors. We also plan to deliver more training materials along the v2.0 release: online documentation, tutorials and university courses.
Ease of integration also depends on our ability to communicate about in-progress work and upcoming changes. We tackle that in our upcoming website release and its roadmap section.
Stability depends on many factors, among which the team’s efficiency and organization. The small startup has grown, some teams are specialized, we see more interdependence and naturally need to structure. When kicking off the year, we set up the vision for the next five years. We are using the OKR methodology to transform collective challenges into specific Objectives and Key Results for the quarter.
Stability of the system also depends on its long-term resilience, which we tackle below.
Regarding cost-efficiency, the network effect is key. For this purpose, we build technological blocks for accounting, invoicing and payment processing actors. These building blocks will help financial actors to:
- Create requests and document transactions in general
- Interact with the payment status of these requests
- Use this new kind of database for all kinds of financial reporting
It allows an iterative migration; triple-entry accounting can be started along double-entry accounting.
Clarifying our positioning
At the frontier between payment processing, invoicing platform and triple-entry accounting, we have often changed our narrative in 2018. This year, starting with the rebranding, we have taken the time to clarify our role. Over the coming period, we make it more visible and accessible to people outside the community.
Payment processing: Request does not move money from an account to another one. But it is positioned where payment processors like Paypal are positioned today: just before the transaction occurs.
Invoicing platform: Request is a protocol made to store & exchange invoices and its related metadata. The landscape of accounting, billing and CRM is already full of good solutions. Request does not have to become just an invoicing tool. Instead, it will benefit invoicing software users to rely on a common framework.
Triple-entry accounting: Request lets businesses share invoices through an independent network instead of sending them. By doing so, every piece of accounting data becomes trusted on one ledger. This can either be a full replacement of corporates’ financial databases, or a side reference for audit and transparency.
- We are working on different use cases to clarify the benefit of Request for everyone in every context: e-commerce, B2B, insurance etc. These use cases will be showcased in our upcoming website.
- After technology, our positioning is the biggest challenge for 2019. Request is not a payment processor, nor a set of e-commerce plugins, nor an invoicing tool, but it prepares the field for the future of such actors. We build the ground layer towards a new financial paradigm.
Many projects in the FinTech space do not last or are not designed to last. Positioning Request as a common infrastructure for payment requests, invoices and payments documentation, the design is made to last. The resilience factors are also bound to:
- Internal organization.
- External builders.
- The protocol’s governance.
The internal organization dictates the stability of our development. The protocol and app development tribes follow two different lifecycles.
The protocol roadmap will be visible soon on our website. It reflects the infrastructure’s stability. On the other end of the spectrum, our education tribe works with partners to initiate proofs-of-concept. In-between the protocol and education tribe, the apps tribe acts as a filter for protocol’s roadmap consistency.
When we release v2.0 of the protocol on testnet this quarter, we will provide external builders with training materials so they can start experimenting on their own business cases and technology. The more external input we receive and process at the beginning of v2, the more resilient the protocol will be longterm.
Later, we will involve concerned actors in reflecting on what a good governance model is for a protocol like Request.