What I learned from working at my first startup

In 2017 I became one of the first hires at the legal tech startup Onlaw. March 31 of this year was my last day working there. In between I learned a lot about how to be a better programmer and how to be a better entrepreneur. I wanted to put a summary of these learnings in writing while they were still fresh in my mind. Like most startup advice these are not things that will be universally applicable for everyone, in fact I expect very little to none of the business learnings will apply to a side gig you bootstrap yourself and grow in your spare time. I found them to be true for my situation at that point in time.

A lot of the people who are interested in reading this kind of post are most likely also the type of people who’ve read similar posts with much of the same advice before. I had too. As I’m sure you know, lessons learned by experience simply have a much stronger impact than the ones we base on the advice of others.

On programming

Plan ahead and concretise your thoughts

I never really had a conscious, thought-out approach to starting a new project. If I look back and try to induce one based on previous actions, my strategy was to do a lot of online research to form an opinion based on the advice of others and then throw myself in at the deep end to get started. I kept all my plans in my head. This was generally successful in the end, but it could lead to a lot of frustration and stress when feeling stuck, especially with a deadline looming. I never really took the time to develop a better alternative.

Turns out it’s quite simple: Say it out loud or write it down. There’s tremendous value in sitting down with a piece of paper and writing notes or making a sketch of how you think you’re going to solve a task. The simple act of writing down your plans, concretising the malleable thoughts you have in your head, can lead to revelations. Most of us already know this; rubber duck debugging is popular with programmers for a reason. And yet, I personally never really took the time to actually do it before I started a task, it often wasn’t until I actually encountered a problem, that I would do it.

Don’t overdo it though, the actual solution will often change before you’re even done with the first implementation, and many of the things you write down will most likely not be read again before it has become outdated. Just don’t spend ages on it, do it for yourself and your own work not necessarily to share it with others.

This is a learning that I still struggle to integrate in my natural workflow, I have to tell me myself to write things down otherwise I tend to keep them in my head.

Learn to say no. Be realistic

When you have a clean slate in front of you it’s easy to get caught up in possibilities of using the latest and greatest technologies and architectures. This is when it’s a good time to take a step back and make sure you’re making the right choices. There’s nothing wrong with trying out a new stack, but be realistic when considering it. Are the technologies in the stack under active development or perhaps stable enough that they don’t need to be? If not, is the person or organisation behind it committed to developing it for as long as you need it? Sometimes you need to choose the “boring” option, even if something else is more alluring. Remember to view everything through the lens of “what is the right choice for the business”, not “what do I want to do”. Hopefully the two will overlap more often than not and you will get to learn something new and have some fun.

Start simple…

When you sit down to plan the task ahead of you, make sure to be realistic. Do you really need that scalable microservice architecture yet or will a monolith do for now? Don’t invest all your time in dev ops that will bog you down if you need to change direction later.

Try to break the problem you’re solving into the smallest possible steps that you can, steps that you can implement one at a time. Small, incremental changes are so much easier to understand and reason about than the larger rewrites we all feel like doing most of the time, and they make it far, far easier to course correct. The small changes are less thrilling, but when you look back at them over time you will have accomplished a lot.

…Except when it matters

Some choices in software architecture are more important than others. Your database schema is not something you’re going to want to change six months down the road because you didn’t take the necessary time to think it through when you started out. Choices that are a foundation for the rest of your code are worth investing time in planning out properly. You don’t have to come up with a solution that can last you 10 years, but you should try to at least hit the sweet spot of “good enough”, something that you can extend when it becomes necessary.

On running a business

Align your commitments

Getting a business up and running is difficult and it takes a lot of invested time up-front. When Onlaw started out there were a few of us working full time and a few others working part time, and we were left with a sort of misalignment. This was a mistake. It didn’t lead to enormous struggles, but having to loop people in every other day, or not being able to have someone prioritise a task because they weren’t working on the project that day, meant we didn’t execute as quickly as we could have done. In my mind’s eye I see us trying to steer an elephant when we really should have been the nimble mouse that can turn on a dime. In reality we were probably somewhere in between. The learning here is that if you’re going to start a business and it’s going to be your full time job, make sure you and the people you work with commit to that business.

The business is the product

Ultimately what you want to grow is your business and the product is a means to an end for that. In many cases the two are invariably linked, but that’s not always the case. There are plenty of stories out there about startups pivoting multiple times before finding success, and that’s really the learning here: Don’t get too attached to the product, always keep in mind that the ultimate goal is business growth. You should believe in your product, but there’s a fine line between that and being stubborn about it. Respect your customers’ domain knowledge and listen to their feedback. You’ll have to adapt and go which way the wind blows.

Understand the problem you’re solving

It’s fundamental for the business that you know what problem your product is solving and why. How can you create a business plan without knowing where your product fits in the market or what opportunities you expect to seize?

Solving a problem of your own will generally lead to a good understanding of the problem, but make sure to consider if the target group is, or should be, larger than people similar to yourself. If you’re an experienced programmer creating a tool to, say, make integration testing easier than ever before, scratching your own itch is probably a good start. If, on the other hand, you’re targeting a market that you haven’t worked with before, you need to really do your groundwork.

Sell!

It doesn’t matter how good your product is if no one is aware of it. You need to sell, sell, sell. It’s a lot of work, it’ll be tough, but everything else really depends on this point. There’s no need for code if you don’t sell.

A final word

It's difficult to break an experience formed over three years into small tidbits that are easily digestible. Most of these learnings are all related to one another, each a small part of the whole. Nonetheless I hope this post is helpful to you. Feel free to reach out if you want to chat about any of it or if you have other feedback.