CaaS Case Study: Arnie

Implementing the Arnie Investment Platform

Marc Adler
CTO as a Service
June 2020

At the very end of July 2019, I received a very pleasant email from Izabel and Eliza Arnold, two sisters in California who had a dream. The email went like this:


Hi Marc,

My startup partner heard about your services through Betaworks, and it sounds like it could be the perfect solution to get us to the next step in our journey. We’re both non-technical founders and are struggling to find someone to take the lead on product development. I’d love to learn more about what you offer and how we could work with your team. We’re west coast based (SF and LA) so it will have to be done through video conference. Let me know when we can set something up. Thanks!


Little did I know that this opening conversation would lead me to an 8-month voyage in what was to be one of the most enjoyable engagements that I have had in my short tenure in my CTO as a Service (CaaS) consultancy.

Izabel Arnold

First Steps

The first step in the process of engaging CaaS is always a free one-hour chat, either by phone or video. Before this initial chat, I volunteer to sign an NDA, and I even have an NDA that I can send to a potential client. Although an NDA is never required, the bi-lateral signing of an NDA makes a potential client more relaxed when discussing their startup ideas.

A few days after the initial communication, and after mutually executing the NDA, I hopped on a Google Hangouts call with the Arnolds. As we spoke, it became apparent that this was a perfect match for my CaaS. Izabel was a financial analyst and Eliza was a creative director/writer for creative agencies. They both had a vision of creating an investment platform called Arnie for people to create customized investment portfolios that align with their specific sustainability values, by investing in companies making a positive impact and solving the global problems they care about, while also divesting from companies causing harm. The platform would support ESG-related values (Environmental, Social, and Governance).

https://www.msci.com/esg-sustainable-impact-metrics

However, neither co-founder knew what it would take to bring their vision to life.

My CaaS consultancy is domain-agnostic. I have clients from many different domains: EdTech, InsureTech, Wellness, HealthTech, and many more. But, since much of my corporate life was spent in financial companies, I have a special affinity for the FinTech area. So I knew precisely what it would take to help bring the Arnie platform to life.

Pretty soon after that video call, I got a follow-up email from the Arnolds:


Hi Marc,

We really appreciate the time you took to chat with us last week. We very much enjoyed our conversation and we’d be excited to engage with you as a temporary CTO to help get our startup off the ground. Your coding expertise and experience leading development teams would be invaluable for our business. We felt our personalities were very much aligned and would make for a great partnership. 


We decided on the terms of the contract, the lawyers did a brief review, signatures were exchanged and we were off to the races. I was engaged for 40 hours per month, which we felt was the proper amount of time to spend to do all of the tasks that were necessary to manage the tech aspect of the platform and to come up with the MVP for Arnie.

Eliza Arnold

Pricing

There are some interim CTOs that charge $400-500 per hour for their services. My rates are a lot more affordable than that. I enjoy helping startups that have a mission to help others. For these startups, my rate is affordable enough to fit into their existing funding. I do not charge any minimum number of monthly hours, and I do not lock a client into long-term contracts. You can use me for 1 hour per week or 10 hours per week. For most startups, I recommend 5 to 10 hours per week, depending on the stage the startup is at.

My rate fit within the budget that the Arnolds had allocated for temporary senior leadership services. For a fraction of what it would cost to hire a full-time CTO, they were able to afford to have someone drive the technological aspects of building their platform.

Getting the Tools

I needed to make sure that we had all of the tools that were necessary to support the development team as well as the infrastructure that was needed to run the Arnie platform.

For collaboration, we used Slack, which has turned into the defacto platform for collaboration between the founder side and the development side.

We chose Jira for the project management system. It supports Scrum-based development and has a wide variety of plugins that enhance the environment (we added a plugin for time tracking). There are other project management platforms that some people prefer over Jira (i.e.: Clubhouse), but the odds are that the remote development shop that we would end up hiring would be using Jira.

In order to have a one-stop place where all documentation would reside, we chose Confluence, which is another product from Atlassian. Confluence integrates with Jira, and just like Jira, it only costs $10 per month for teams of less than 10 people.

For source code management, we chose Github. All founders should own their source code management system (SCM), and the development team should be required to check all code into the founder’s SCM, not the development company’s SCM.

Finally, we settled on using AWS to host the infrastructure. If you are a startup, you can usually get some generous credits if you enroll in the AWS Activate program, which is a program run by AWS that provides assistance to startups. I had the Arnolds enroll in Activate, and as a result, AWS was basically free for us to use.

Writing the Biz Stuff

The technical architecture should always support business requirements. Even before I started considering the architecture, I had the Arnolds go through the exercise of writing a Business Requirements Document (BRD). The BRD is the “bible”. If the development team has any questions about the functionality of the application, the BRD is the first document that they should consult.

The BRD contains each and every use case. It details the flows that lead to happy paths, as well as unhappy paths. It contains information about complex business logic. It can be used to draw up the various user flows.

It can be a bit boring and tedious to write a BRD but believe me, it is worth it. The BRD captures and clarifies all of the founder’s thinking, and in writing it, a founder can often think of new features that would enhance the platform.

It was hell, but we completely agree it was an invaluable experience writing it!”

Eliza Arnold

Once the Arnie BRD was written, we then went through each and every item and determined what would fit into a logical MVP. Not every feature has to go into the initial product. For the Arnolds, enough functionality should go into the MVP to enable them to go out to investors in order to raise funds for the initial production-ready version of the product.

Choosing the Development Team

The technology stack that I chose is a fairly standard stack. ASP.NET/C# on the server-side, React on the client-side, MySQL as the database, and AWS as the cloud provider. I knew that, with this stack, I would be able to consider almost every remote development team.

I would love to be able to hire USA-based developers for all of my clients. The fact is that my startup founders have a limited budget, and that forces our hand when it comes time to hiring a development team.

I have some personal requirements for any development team that I consider.

  • They have to have a large enough staff to be able to backfill any member on the team. There are times when a developer just doesn’t work out. There are times when a developer gets sick. We just need to make sure that the development company has talent in reserve and can backfill at a moment’s notice. 
  • They have to provide a wide variety of services. If we need a UX specialist or a QA specialist, we would ideally like to hire them from the same development company. We are assured that these additional team members will all work from the same time zone, and there will be a smooth pipeline from UX to front-end developers.
  • We cannot consider a development company that does on-demand hiring when they win a project.
  • Most importantly, we need to make sure that the development effort will fit our budget.

After considering several development companies, we ended up choosing a company out of Belarus that satisfied all of our requirements. The company proposed a team, and I interviewed all of the developers in order to make sure that their skills were sufficient enough to build the product. We were also assisted during the entire process by our awesome NYC-based salesperson (thanks to Jesse!). 

Grilling the Third-Party Vendors

Even though Arnie determines how a user’s capital should be invested based on their inputs, and invests their portfolio for them, the Arnie platform does not actually hold the investors’ money. Nor does Arnie actually directly execute the trades on the market exchanges. This is all done by a third-party Custodian.

The Arnolds and I started doing our due diligence on the various providers of custodial services that support the startup community. This involved doing both a business-related deep dive on the custodian’s platform, as well as a very detailed technical deep-dive. We needed to make sure that the custodian supported all of the features that the Arnie platform required. This meant that I had to examine the custodian’s API and map the Arnie business requirements into various API calls. We had to ensure that the custodian wouldn’t break down on heavy trading days (note: in March and April 2020, there was record trading volume, as well as thousand-point swings in the Dow).

The founders needed someone on their side, representing their interests, that could ask the difficult questions to the vendor and detect any bullshit that came back as answers.

We finally settled on a custodian that supported most of our needs. However, one big issue was that the custodian would start charging Arnie a hefty monthly fee once the contract was signed. How do we get around a situation like this? More on this later.

The Architecture

Despite the word “Technical” being in the title, there are many CTOs that are just not technical. Fortunately, despite my years being a CTO and Chief Architect for some major (and minor) companies, I have always maintained my technical ability.

I created the initial service-based architecture for the Arnie platform, including writing the complete API spec and the data model. Once that was done, I started personally putting together all of the infrastructure on AWS. I chose EC2 servers that ran Ubuntu 18.04, and Nginx as the webserver. We used MySql under RDS for the database. I had to install .NET Core 3.1 because, at the time, the AMI that I chose only came with .NET Core 2.1. 

We migrated the domain from Google over to Route 53. I set up Route 53, CloudFront, S3, the Certificate Manager, etc. I set up the CI/CD environment using AWS CodePipeline, which hooked nicely into our Github repo.

I also generated the initial ASP.NET Core skeleton for the project.

By the time the remote development team was ready to start, everything was completely set up for them.

Planning the Development Effort

The Arnolds did not have prior experience running development projects, especially using Scrum. I gave them a brief lesson on how to use Jira, and then we started mapping the BRD into our backlog items. Once the complete backlog was formulated, we started prioritizing the backlog items and we came up with our first sprint. I usually like to make the first sprint a 4-week effort, mainly because we need to build the foundation of the app. There are certain tasks that need to be done upfront, and only need to be done a single time. There are some things that the developers needed to learn, such as how to work with AWS CodePipeline.

The remote development company generously provided a free part-time PM to the Arnie team. We made sure to go over the sprint backlog with the PM in order to make sure that it was properly fitted to his team. We also installed a plugin in Jira to enable each developer to track their time accurately.

Each developer was added to our Slack, to Jira and Confluence, and to Github.

With everything ready for the developers, we broke the champagne bottle on the side of the battleship, and the project was launched.

Weekly Development Tasks

We had team meetings three times a week. One was usually a full team meeting, one was a backend meeting, and one was a frontend meeting. I was available 24×7 to answer any questions from the development team, and Slack was used heavily. I would wake up in the morning to a bunch of questions, which I would attempt to answer over my first cup of coffee.

I also met with the Arnolds every week for a debrief, a status report, and to make sure that they were satisfied with the team’s progress.

Every once in a while, I would do a code review and offer suggestions. Our backend developer turned out to be a real star, and she picked up new technical concepts very easily. 

I had periodic meetings with our chosen custodian provider in order to dig deeper into certain workflows and to keep our relationship warm while the development team continued working.

The Custodian Simulator

I mentioned above that the custodian would begin charging Arnie a monthly fee once the contract was signed. In order to avoid these costs, I wrote a simple C#-based simulator of the custodian’s platform that the backend developers could write REST calls to. Once the contracts are signed with the custodian, we know that we will have to spend a bit of time testing our code against the actual custodian’s APIs. But by writing the simulator, I was able to save the Arnolds tens of thousands of dollars in fees.

Boy, am I glad that I kept my coding skills up. As a Chief Architect/CTO for some major companies, it was always a bit of a struggle to stay technical while managing organizations and doing the things that a CTO does. I am happy to do coding when needed for any of my clients.

The Result

After a 3-½ month development effort that finished within budget, the Arnold sisters have their completed MVP. 

Arnie is an investment platform that lets you choose various sustainability and impact values that you can align your portfolio with. The components in your portfolio are modified and re-weighted based on the values you choose (e.g. lowering fossil fuel emissions, improving board diversity, etc). You can also exclude any stocks you simply don’t want to invest in. There are informative news articles on the site that keep you posted on any ESG-related news.

The production version of Arnie will contain a portfolio optimizer. This will create an optimal portfolio that balances ESG factors with financial factors to give you a more sustainable portfolio that still aims for market-rate returns.

The Arnold sisters are now talking to investors in the hopes of raising the funds that are necessary to complete the product, sign up with the custodian, and begin marketing the product to people who would like to invest in companies that operate in a socially-responsible manner. If you know someone who might be interested in making an investment into the Arnolds’ vision, please contact me at marc@ctoasaservice.org, and I will be happy to make an introduction.

As part of the service that I give to the Arnolds, as well as any other CaaS clients, I am happy to meet with investors in order to dive into the technical aspects of the app. The investors should be comforted knowing that there is an experienced senior veteran behind the technology. In fact, many investors demand to see that kind of experience behind any organization that they invest in.

Why Use CaaS? I Could Have Done This Myself

Maybe. But I get contacted on a weekly basis by startup founders who just gave their ideas over to a remote development team, and in the end, they got back something that was less than functional. Some founders don’t even have access to the source code that they paid for. Some do not even know how to access the cloud-based infrastructure that they have paid for.

I hope that this article helps to convince you that you always need a senior technical person by your side while your application is being developed. You don’t need someone there on a full-time basis. But having someone on your side that represents your interests is well worth the investment. Because it is more expensive to start over again.


CTO as a Service has over 30 years of writing systems, leading development teams, and doing architecture reviews. I work with all sizes of companies, but I love helping startups realize their visions. Services include hiring and leading development teams, architecture, code and architecture reviews, roadmaps, coding, speaking with investors, etc.

Marc Adler
CTO as a Service