Lead developer at a startup: Year 1 (Part 1)
Tags: startup, leadership
Published: 2020-03-16 07:32:06

A year ago this week, I started my job as the first tech hire of a fresh startup. They were already operating as a small services business serving clients manually, and I was tasked with coming in and starting the product offering and transitioning over to a SaaS model. It's been a full on year, with plenty of ups and downs, but more than anything an exciting journey with hopefully plenty more to come. I've decided to share that journey in chunks, and here we have the first one:

## Setting the scene

I'll just set the scene a little bit first before digging into the details. The goal of the startup is to make anti-money laundering checks super simple. New Zealand recently introduced a bunch of legislation that means accountants, lawyers, and estate agents all have to get these checks done on their clients. This ranges from a simple ID check of an individual, all the way up to a complex investigation into who needs checking when the client is a complex corporate structure an accountant has set up for tax avoidance.

The startup was 6 people at this point. They'd been running these checks largely manually, using a bunch of 3rd party tools to manage the processes and data. Essentially they were an outsourcing company. This wasn't going to scale, and the founders had much higher aspirations for their company. So they went out and got a tiny seed round and some free office space from an accelerator. They used the money to hire me, with budget for a second dev.

## Phase 1: Oh fuck, what do I build, what am I doing, who am I

I think this sums up the first month or so of my job. It was the first time I had been the first person on the tools, laying the groundwork for what was to come. Imposter syndrome kicks in pretty hard for most people in that scenario I think. So I decided to focus on things I _knew_ how to do:

- Decide on tech stack

- Put tooling in place (github, CI/CD)

- Hire a front end developer (definitely not my skill set, and something I didn't want to expend a lot of energy learning)

The tech stack was a relatively easy decision, at least on the back end. I was very familiar with C#, and it is super popular in Auckland. The flexibility and ease of .Net core makes it an attractive option these days. I had a rough idea of what the data was going to be like, a relational database made sense and is always a nice default, at least to start with. I was most familiar with MS SQL but PostgreSQL is free, so Postgres it was! Terraform was an obvious choice for coding infrastructure, though one I hadn't worked with before. Front end stack would be handled by whoever I hired to handle that. Easy stuff.

Tooling was full of learning opportunities. It had been a while since I'd set up even a small project greenfield. I picked CircleCI for CI as it seemed popular and I liked the container centric approach. I’d end up replacing this with buildkite in the end, but it did the job for the first 6 months. Easy stuff.

Then came hiring. I'd done a lot of this before, from interns through to seniors. Turns out hiring a developer to have the skills _I don't_ was HARD. I wasn't able to ask the right questions, and had to go on gut feeling and base programming principles for most of it. I lucked out to some extent though. I found someone who seemed to know their stuff and was available immediately. I had a team! Shit was getting real _FAST_.

Now came the giant elephant in the room. What were we actually trying to achieve? I’d kind of fleshed this out with the founders in the interview process, but how were we going to get there?

In startups we have to wear many hats, so I plopped on the product hat. I had worn this hat a little bit before, I think all senior developers _should_, but this was different. I'd never started the product entirely from scratch before. I sat down with the people in the company who were running these manual checks and tried to figure out what they were doing and how we could help. Many of these manual processes could easily be automated, so I started investigating writing little tools to help. We also started trying to piece together a platform based on the 3rd party data sources we already had.

We made some reasonable progress. Our development flow was nicely set up, and we ready to start rolling software. By this point I was about a month in. I headed off on a previously planned vacation for a week or two with a friend who was visiting NZ. Things were great, it was sunny, I was on a boat, and was starting to get over the imposter syndrome.

Then came a message over slack. To keep one of our largest clients happy, we needed to produce a platform for them within the next month. The stress was about to intensify big time. And that's the story for part 2!

Learnings from this period:

- You're always going to make at least some bad decisions. Don't be afraid of this. If it's a decision that's easy to undo later, just go with it. If it's difficult to undo later, then spend time laying out your reasoning and be confident in your decision. It still might go wrong, but it's better to move than to stand still.
- Don't procrastinate on the hard tasks, focus on them. Get the unknowns out of the way first and everything becomes a bit more predictable and easy to handle.