918 days ago in building a tech company
Approx. reading time: 10 min
I have been encouraged to write about how we build Hudya’s technology platform, so I thought I’d get this blog started by doing that!
Hudya set off last year to turn upside down on how you buy those boring necessities for your home and family: electricity, mobile, insurance, banking, home alarm, and smart home. If you have the nagging feeling that you are paying too much or paying for something you don’t really need, Hudya is for you! Our services are designed to be simple with fair prices and with no hidden fees or things you need to pay attention to. We want to take the view of the customer and simplify life by removing hassle and worries related to these basic services. In order to do that, we use technology, lots of technology! As we evolve, we want to use our technology to help you in your daily life. With Hudya, you should feel taken care of!
When I joined the other founders on Jan 2, 2017, I was the first engineer and the only technology asset we had was a WordPress web site. The ambitions were to launch products in six different industries (electricity, home security, mobile, banking, insurance, and smart home) in three countries (Norway, Sweden, Denmark) as quickly as possible and in parallel. How do you manage such complexity and get things in the market quickly without sacrificing long-term ability to execute?
I quickly realised that our biggest problem would probably be to make sure that individuals don’t have to understand everything in order to be productive. The classic startup approach where you have a small, tight-knit team in the same room where everybody is involved in everything would probably give us best speed short-term, but we would quickly suffer from too many things going on at the same time and lack of ability to scale the team.
Here are the principles I followed:
Each of the industries and each of the countries we are going into have their own complexities. There are lots of little details somebody needs to spend hours understanding to get things right. But there were also some things in common like secure authentication and authorization and subscription-based services with usage of some kind of unit (kWh or Mb). We also knew that with our ambitions to be open and trustworthy and offer “insanely good customer experiences” (thanks, Steve Jobs!), the customer dialog and our ability to understand what customers desire would be enormously important. And we had to design in privacy and security from day 1.
I decided to use a microservices architecture where the subscriber is at the core of a set of services that are event-based and communicate internally and externally using REST APIs authenticated with JWT (JSON Web Token). Above is my first sketch of the architecture. The core is entirely event-driven, and all services have only one entrypoint: the documented JWT-authenticated REST API. At the edges, we have what we call adapters, components that translate from the outside legacy world into our core architecture.
Using this microservice architecture approach, similar to what Netflix and Über are using, we can have individuals or teams work on each microservice who can make sure they expose a simplified Hudya view of the outside world to other microservices.
I first learned about this strategy when reading about early Microsoft development. When you are starting up, you don’t have resources to build everything you need to build, so you need to find partners that can offer that functionality (design them into your architecture). You may find that you don’t have to build it at all, your partner does it better than you need, or you later have to replace the partner functionality with something you build yourself (design the partner out of your architecture). Cloud-based API-first offerings on the Internet have made this strategy super-cheap to execute on. We decided to use Stormpath for authentication and authorization, Intercom for chat and customer engagement, Stripe for payments, and Bisnode for phone directory services (EnergySales is our electricity partner). Our experiences here could be blog posts on their own, only Stripe has been a smooth experience, but let’s leave that here 🙂
As an example, we fairly quickly migrated to Amazon Web Services instead of Digital Ocean, and we are currently about to introduce Go Lang as a second language for microservices. The (fairly) complete current stack can be found at Stackshare.
In order to get things done quickly that help our business move forward and learn, I use a technique I call “scaffolding“. Basically, this is an approach where you write code that is prototype code or scripts that can support a semi-automatic process. For example, we knew we needed a fully automated credit card processing system. But instead of writing a specification of the entire system and then implement it, we identified activities or tasks that would quickly become a pain to do manually (in excel, email, word, etc). Then we wrote code to handle those. This allowed us to start offering services earlier, and in the process we learned a lot, so that when we later implemented production-code, we would have higher confidence in how to do it. My favorite saying when looking for scaffolding opportunities is: Don’t solve a problem you don’t have! We thus tend not to code anything until we feel a pain…
I knew that the tight-knit, physically co-located team would be the less risky option, but I also knew that if I brought on board senior engineers from the beginning, we would spend a lot of time discussing the right architecture and technology choices (rightfully so). While there is a time for that (we are in the middle of that now), we didn’t have the time. We were supposed to have already launched electricity services, and I wanted to start building an organisation that would be able to move forward new products and new countries in parallel.
So, based on the architecture and technology skeleton, I searched for highly competent people with experience and dedicated to the choices I already had made. Considering our urgency, that meant consultants, not hired people. Still, I wanted people who would want to stay for the long-run as I wanted to start building the company culture and practices. We already had a good relationship and good experiences with an Argentinian design/UX company called Moka that had already built our first version website in WordPress. Our cloud architect joined us from Napsty in Austin, Texas, and we found a great Python developer team in Ukraine from AtomCream.
With this team, we built and launched electricity services in Norway in eight (8) weeks, while at the same time building up our devops pipeline and processes, and a first version of our microservices architecture.
Did we cut corners? Absolutely, that is what scaffolding is. And did we end up with the design and specifications I envisioned? Roughly, yes, but I turned out to be the main bottleneck (not surprisingly), both trying to specify the details of the architecture I had planned as well as how to implement electricity services. I call this phase “sketch-out”, as you set a direction, but the velocity required means that you don’t get it exactly right.
Unless you are prepared for this, you will get an unwieldy mess of an architecture that will make you suffer for years. Phase 2 is about hiring, re-design and re-factoring. We have started to learn more about our services, what is important, what works, and we have devops pipeline that allows us to bring code (fairly) quickly into production. The first key person I needed was a Chief Architect, a person who would intuitively grasp the requirements, architectures, and design patterns I had in mind, and who could validate them, design them, and prototype what is required for the entire team to implement. I was incredibly lucky and met Tommy, a very senior architect, CTO, and coder. And shortly after that, Pablo, head of Moka agreed to move to Oslo and join us as Head of Customer Experience!
We are now in the process of making each of the physical locations we have into standalone production units (scrum teams with product owners) with ownership to their own microservices and components in our platform. A key part of that effort is to hire a senior team here in Oslo, Norway. Beside owning overall architectural vision, the Oslo team will own the customer dialog and all customer-facing components that we need to make sure our sales and support representatives (aka “educators”) can offer the insanely good customer experience we aim for.
A big part of writing a post like this is the hope that it can help somebody else, so I also want to share where we have struggled.
I mentioned that I quickly became a bottleneck. I was the only connection between the vision, the products we were going to bring to market (including partners), and the engineering team. I thus had to cut corners where I could, and when I asked the team to deliver something, it was often guesswork to understand what I meant. To fix this problem, we have worked on getting a technical product manager/product owner for each area (do you know somebody great?!), as well as to set up a roadmap/backlog grooming process that allows input from many different sources to be collected and pulled together without one single person being a bottleneck (maybe a later post?!)
We were also hit by Stormpath joining Okta without really being acquired. And since Okta decided that all customers (at least for the time being) should fit into the requirements of large enterprise customers and gave us prices out of this world, we had to totally rebuild our authentication and authorization system.
Another big issue has been developer productivity. We built a devops pipeline with the ambitions to be able to deploy code several times a day. I wanted real devops with continuous integration and continuous deployment (CI/CD). This means that code needs to be structured differently and new features designed for CI/CD, and you need a lot of plumbing and structure to support this. It’s tricky when you have a new team with people distributed across locations and timezones, they need to get to know each other, and no one has experience with exactly what we are building (there are so many different ways of doing it). In the process we built out various technologies, processes, and systems that were designed to give us a support structure for building, testing, and deploying code with high quality. We underestimated how difficult it was to code new features in our microservices architecture. We are as we speak building a simplified development environment to ensure that developers can have high iteration speed when coding new features.
I would love questions and feedback!