My first 6 months as CTO/Cofounder
Hi everyone,
I was lucky enough to launch Defacto in spring 2021, with Jordane Giuly and Morgan O’Hana. Our mission is to finance Small & Medium Businesses (SMBs) in Europe. Our product is an embedded lending API.
I’d like to share my first 6 months as the only engineer and to explain how I bootstrapped our platform. The goal of this article is to share my thinking process, not to build a playbook.
First, a little bit of my background. I lived in the US between 2012 and 2020, got a Master’s at UC Berkeley before joining several tech startups through which I learned how to code and grew as a Software engineer. I was consecutively a business analyst, data scientist, data engineer, backend engineer, and finally full-stack engineer. I worked at ClearMetal, acquired by project44 , joined as 2nd employee and grew the team all the way to 70. I got the experience of starting from scratch. This is important as it got me used to wondering and later ignoring (to the best of my ability) the daunting question: “Am I doing something stupid that can jeopardize the company ?”
Enough about me, let’s see what happened.
🎉 Start Coding (6 weeks)
My first objective was to have a webpage only displaying the SELECT now() from a database. And to have everything hosted on the Cloud.
It contains all the foundations of any tech platform. We were still in our user and market research phase so it was a good time to build something business agnostic.
Pick your stack
This is the first thing you have to do. It is not an easy task. In particular it influences your company’s hiring pool and which candidates feel like they have the right skill sets. Hiring is the #1 priority when you launch a startup. Engineers can be opinionated or have different background depending on their stack. But after couple of discussion with other co-founder/CTOs, I picked the stack I was the most comfortable with. The one I understood the most. So here it was:
- Python for the backend along with Flask
- Typescript for the front-end along with React and Material-Ui
- Terraform for the infra along with AWS, Docker
- Postgresql for the datastore
Hello word! app
Having a good developer environment for our engineers was important to me from the start. I believe that a cofounder is fundamentally a momentum keeper. Speed and reliability are everything. So I wanted a disposable infra that you can spawn whenever a dev needed it and a good CI/CD from day one.
Most of the infrastructure was new to me. Here are some resources I used.
- Front-end: how to build an app from scratch
- Front-end hosting: let’s netlify handle everything for me
- Front-end testing: how to get cypress test to run with my CI/CD
- Terraform: basic Flask app on AWS
- Terraform-cloud: how to launch multiple parallel env
- Flask app with automatic swagger generation
- Testing: enable integration tests through docker-compose (adapted to python)
- CI/CD: deploying through circleci
comments: I did not know Terraform nor typescript but I spent time learning it
🗽Design your Data Model (3 weeks)
I can not stress this point enough as I believe it is often neglected.
You want to move fast, be quick, show something to your first beta-tester. You may think “it does not matter how I model an invoice, a quote or a loan-request”. But your data model is the state that you’ll live the longest with. We all know how frustrating it can be when you can’t develop new features due to it.
I never worked in finance before but my cofounders were industry experts, as cofounder and early employees of Spendesk. We spent hours, all together, discussing about the industry, their learning, and brainstorming different product ideas and their high-level implementation. Also, we confronted our data model with many CTOs, lead engineers from the fintech industry.
If you want to have an idea of what we did, here’s our API doc. I still believe this is our biggest asset so far. And this is still an ongoing exercise that we do every month.
🤷♂️My first user workflow: upload invoice and request a loan (3 weeks)
By the time the basic infra was in place, I understood the industry concept and how to model them. We finished our market research, we got funding. It was time to build something meaningful.
Our first product was invoice-financing: you’re a freelance, you sent your invoice but your client is going to pay you in 60days and you need the cash now.
The first user story we identified was: as a user, I can upload an invoice. Let’s move fast!
Once again here are the main resource:
- Front: submit files
- Front: display table
- Python: upload file
- invoice parsing
💰Our first payment (2month)
After a user has uploaded the invoice, requested the loan, you need to send the money!
Dealing with money is pretty scary as a developer. There are a lot of cases where the motto “Move fast and break things” does not make sense: lending money is one of them. This aspect lead me to introduce a couple of significant changes.
introducing multiple services: I decided to isolate all the financial functionalities into its own service. This is when I introduced multiple services in the backend. This new service would be in charge of orchestrating any payment I needed and listing all the transactions that occurred on any bank account. I chose a python framework, Nameko, that I used in my previous company. Here is an example.
introducing state-machine pattern: It is important for us to get a financial trace of every action taken and to prevent unexpected manipulations, such as initiating the same payment more than once. I decided to introduce the state-machine pattern. It gave us: an explicit state, well defined transitions and logs.
introducing event-based architecture: To maintain our overall state coherent across services, I attached an event publisher to our state-machine so that any service could subscribe to changes.
introducing dogfood: To test our payment with our money first, we created a couple of accounts in multiple banks. We then launched a dogfood environment (where a company uses its own platform) where we could request loans between those bank accounts. This forced us to have our platform fully configurable.
introducing cron routine: The need for scheduled jobs is well known but it’s always a pain to implement it (should I default to Jenkins?). I wanted to have these cron jobs been configured through terraform. Here is the template I used.
comments: we are happy to use Swan as our payment
🥳 Our first live customer (1 month)
Now it was time to have our first user — even if we showed regularly our progress to our beta testers.
A couple of pieces were still missing
authentication: This is only at this stage that we dealt with authentication. I went for JWT token with flask-jwt-extended package. It is important to note here that we introduce this auth in all our backend services. Any requests across all services would persist the original identity.
empower your team: To help our big “Customer Success” team with enrolling so many clients, we spent time building an admin panel. It was important to have our success team self-supported for any request. We opted for retool, which allows us to easily create dashboards based on APIs. This was the foundation for our internal process.
build your basic monitoring: In order to get some visibility on our system, we integrated: Sentry (for all the exceptions), AWS Cloudwatch Logs (for logging), Intercom (to capture webapp important events and provide customer support)
And that was it!
Conclusion
In a nutshell, I went with what I knew. I spent time on everything that was foundational (data model, ci/cd, testing, state-machine…). Everything else, I was running as fast as possible. I always had a clear objective in mind. Anything that could be postponed to later, I postponed.
It is important to note that
- Antoine Cheron, our first dev, joined me in the middle of the “first payment” milestone so I was not by myself for 6 months.
- 50% of my time was dedicated to hiring
☞ If you want to be part of Defacto, check out our open positions 😉
