1859 Cloud is one ofmarmelab‘s customers. The digital product we’ve developed for them is both typical of our work (Lean Startup, agile iterations, API-centric architecture, full-stack JS) and very unique (long running, finance sector, very high quality requirements). Let’s see that in detail.
Helping Charities Using a FinTech
The vision of 1859 Cloud is simple: attract and select high quality professional investors, build a financial markets idea-based meritocracy, and capture the collective intelligence derived from the collaboration and competition within the community. This intelligence is used to drive the performance of a low cost investment fund, but with very attractive performance profile.
Investors in the fund will pay a normal fee, but given its low cost base compared to traditional funds, 1859 Cloud aims to redistribute a very large share of the difference to charities. For a usual fund managing several billions dollars, this can represent up to a million dollars a year given to charities. Who said FinTechs can’t have a soul?
But how do you create a high performing fund with lower fees? In usual funds, the fees (about 1 or 2% of the invested funds, and 10 to 20% of the performance realised) pay the fund manager, a highly skilled trader who knows where and when to invest. The bet of 1859 Cloud is to use the wisdom of crowds, i.e. to delegate the sourcing of the most attractive investment ideas to a group of volunteer contributors. The Wisdom of Crowds, a book written by James Surowiecki, describes how a group of well-organized individuals can outperform highly skilled experts.
Building up on this mechanics, 1859 Cloud is a private club of investors, selected for their performance, diversity of expertise, and investment style. Inside the club, members/contributors share investment ideas. Each member can invest virtual risk units (like casino chips) on each other’s ideas. These investments are a signal of trust, and allow the best ideas to surface. This swarming process is monitored and consistently evaluated, and this drives the fund to invest real money on some of the ideas – ideally the best performing ones – without ever needing a human fund manager.
Why would professional investors share their best investment ideas? Well, first because of the quality, multiplicity, and diversification of the other ideas they receive in return. They share something obvious to them, with the likely chance to get quite a few ideas they did not think about.
Also, those who share an idea get valuable feedback from their peers, without the risk of tarnishing their reputation if the idea doesn’t work. This is because members are anonymous in their interactions. Anonymity is a strong condition for the wisdom of crowds to emerge. If investors know the authors of the investment ideas, they might invest based on the authors’ reputation rather than on the idea merit. So 1859 Cloud completely hides the investor names, and all they can see in the club is the members’ grade – a representation of the member observed performance or judgment quality over a multi-year horizon.
As for any B2B business, the 1859 Cloud domain is large, and sometimes hard to understand for non-specialists. For instance, here is a typical idea shared by a 1859 Cloud club member:
" Long CAC/Short DAX (sell ratio) "
The rationale behind that idea will only make sense if you have strong financial background:
" Global selloff has brought French index almost back to pre-election level. Stronger EUR and potential global rally topping out makes the DAX an attractive hedge while the French government seems to have a good start and reforms ahead of it. Also, equities maybe to be exempt of French wealth tax in fiscal reform to come. German election in September another excuse for underperformance ahead. "
This is a real idea from the club, but it’s an old one. Current ideas have a potential strong value, and therefore cannot be shared outside of the club.
Inside the club, investors submit suggestions. The club administrators need to vet these suggestions according to some set of rules, they adjust the size notional to make them comparable in terms of risk, and they format the suggestions so they can become ideas, i.e. a published suggestion. Investors invest tokens on ideas, defining the limits when they will sell (a target price and a stop price). Each idea has a daily value taken from financial markets. An idea can also have events (like dividends, or roll for a Future), which add to the investment value. This value determines the performance (gain or loss) of an investment, and, by extension, the performance of an investor’s portfolio (the sum of all their investments).
There are many more concepts on the 1859 Cloud’s platform, in addition to complex calculations to get exact performance for a given investment on a given day. Besides, using financial products involves a big focus on properly handling dates, timezones, currency conversions, and roundings.
The Lean Startup Needs Adjustments for Finance
1859 Cloud came to Marmelab mid-2014 to build the club’s digital platform. Marmelab has provided a team of 3 people: 2 full-stack developers full-time, plus an agile projet pilot part time. The pilot is, at the same time, a scrummaster, a proxy product owner, a UI/UX advisor, and a software architect – think a Chief Operating Officer in a startup.
In many aspects, the building of 1859 Cloud is typical of The Lean Startup approach. Customer-centric design, features seen as experiments, early and frequent releases, metrics-based decisions, even a pivot to change the business model about a year ago.
But the 1859 Cloud case is also very different from your usual move fast and break thingsstartup. Mostly because the 1859 Cloud customers are wealthy people with very little spare time, and high expectations for super slick products with zero bug. In addition, this Fintech activity falls into the “providing advice for investment” category, which means it is regulated, and 1859 Cloud’s legal obligations translate into strong software requirements.
We had to accommodate our process to deliver a super stable product every two weeks. In developers terms, this means more thorough backlog grooming, a certain formalism in acceptance tests, longer qualification time, and a polished UI even for the first release. The Minimum Viable Product took 9 months to develop.
Fun Fact: The 1859 Cloud name comes from the year of the publication of Darwin’s “On the Origins of Species”, which unveils the theory of evolution via natural selection. Performing ideas are selected by the club, the ideas unfit for a world of profit die quickly!
In collaboration with a London-based web agency, we designed a classic API-centric architecture, and started developing 3 apps:
The frontend app is responsive: it has to work on desktop (in web browsers), as well as on iOS and Android devices (tablets and phones).
We chose PostgreSQL, Node.js, Cordova, and Angular.js for the main tech stack (remember that this project started in 2014). Along the years, we added a queuing system, asynchronous workers, cron jobs, a notification system, and many other bricks. 1859 Cloud uses several cloud services from Amazon Web Services (AWS) (including VPC, ECS, ELB, RDS, SES, SQS, S3, CodeBuild, CodePipeline, CodeDeploy, etc), which allows the infrastructure to scale easily without high upfront costs.
We don’t manage the production servers – 1859 Cloud appointed another contractor, Osones, for that. If you’re looking for a host company relying on AWS with great engineers, we can definitely recommend them.
Lessons Learned About Developing A Mobile App in The Financial Sector
And a large share of our efforts has been dedicated to building a full-fledged admin – in fact, more of an ERP. We pushed ng-admin, our open-source admin dashboard development framework, to the extreme to allow all sort of custom screens, optimized for speed of use.
Anyone who develops a mobile app knows this, but we learned it at great cost: deploying updates to the app is always a risk. First, all modifications must be done in a backwards-compatible manner, as the mobile apps will update way later than the API server (and therefore the new server must be able to serve the old apps for some time). Second, when it works on one device, it doesn’t work on all the devices of the same manufacturer. Mobile testing takes a lot of time. Last but not least, in-app analytics are a must, otherwise you’re blind to any problem the end users may have.
We invested a lot into a custom Continuous Integration service based on Travis and AWS. In addition to running automated tests, it automatically deploys the code according to the branch it’s been merged to (integration, staging, production). We can deploy with one click, and it doesimprove the quality of the apps significantly.
Oh, and about those tests – we’re so happy we started writing them on day one. The code has a strong coverage of unit, integration and e2e tests, and this has saved us countless times. I’d even say that e2e tests, which are very expensive to setup, write and maintain (especially with Angular.js), have a strong return on investment. With this test base, we can start large refactorings with confidence, and that’s the reason why the codebase is still fresh after 3 years.
It's The People, Stupid
Over the course of the project, the Marmelab team has changed at least 6 times. We try to rotate developers on a yearly basis, so that our developers see a variety of projects and technologies. Developers are notably hard to find, but easy to lose if they do the same thing for too long. You can imagine how painful it is for the Product Owners at 1859 Cloud, who must re-explain and share invaluable domain expertise twice a year, and support some periods of suboptimal productivity.
However, this also brings some strong benefits. For example, to avoid relying on a developer’s knowledge, we automated many processes – from configuration management to developer onboarding. The project has great technical documentation, which is unusual for us (we believe in code as documentation). And the codebase has no dark place – many developers have seen the code many times. The variety of experience of the developers who participated in the project has brought innovative ideas about architecture, performance, or system administration.
Projects at Marmelab usually last for a few months – we bootstrap products up to the MVP, then train developers working for our customer to take the code from there on. The 1859 Cloud project tests the solidity of our model on longer projects.
A continuing collaboration for 3 years only works if the parties trust each other. The project works because every individual involved in the project demonstrate goodwill.
The 1859 Cloud High Conviction Fund will launch in the second-half of 2018, and hopefully the first check will be sent to a charity in January next year. The 1859 Cloud company is raising more capital, and hiring more people, to accelerate their growth. They just closed successfully their Series A. Soon, 1859 Cloud will start analysing its members’ behaviour even more thoroughly, looking for new signals pointing at great ideas – using Machine Learning.
On the technical side, we’ve started the transition from Angular.js to React.js in the frontend. There is so much code that it will take long, but we’re confident that we can integrate Angular and React together to allow a continuous migration. We alternate technical iterations to consolidate the platform, and the development of new major features inspired by the feedback we get from the investors.
We’re super happy with this project, which is not only innovative, but also challenging, and motivating. It’s a great achievement by the 1859 Cloud and the marmelab teams, and we’re looking forward to making the word a better place thanks to the wisdom of Charles Darwin!