This post will be less about Typescript and more about programming in general, specifically from the point of view of being a technical founder.
If you’ve ever dabbled in server administration, fiddled with a raspberry pi, been curious about new technology outside work, or you identify as someone with an explorative or entrepreneurial gene, this post might be an interesting read.
In the text to follow, I endeavour to explore all the facets of being a technical founder (eg. CTO) in startups, and what that means to my career and personal learning. Additionally, as I’m quite interested in business, I will also try to tie in any learnings about how to play the game of business, as a technical founder.
Lord knows I’ve made plenty of mistakes as I’ve built out several companies throughout the past 10 years, with varying levels of success. My current employment, Introdus Onboarding, in which I started as a developer and ended up as the CTO, is my first stab at creating an actual SaaS. What I’ve done previously is not too important for the context of this read, but the mistakes I’ve made are important.
Mistakes means learning
For any entrepreneurial spirit, mistakes are meaningful because they are usually a fantastic source of learning.
I’ve made so many of them and for some periods of time I regret not having a mentor to spar with, or someone who could have helped me avoid some pitfalls.
There are a lot of things to get right when launching a company and/or product in a digital world, and I feel like I made all the mistakes:
- Not outsourcing particularly critical pieces of business or software in which I have/had no experience
- Not asking for help (from literally anyone)
- Pricing too low
- Pricing too high
- Waiting too long to launch
- Hiring too early
- Not tracking/measuring enough
- Not being thorough enough with my Google Ads setup
- Spending too much time, being too thorough with my Google Ads setup
- Spending time optimizing for the wrong thing (why bother with conversion rate, when you have no visitors or traffic?)
- Not capturing emails from my lead magnets
- Pivoting too early
- Pivoting too late
I’m sure there are a ton more I’ve blisfully forgotten since I started dabbling in programming and entrepreneurship around 2012.
But, all of those mistakes have meant an opportunity to learn and that is golden.
Now, more than ever, I see issues with business plans, holes in scalability of software, missing validation for products. In other words, much my time making mistakes have translated into a heightened perspective, and that is friggin’ cool!
So what did I learn?
There are many terms that goes around in the wonderful world of tech, but here are some perspective changes I’ve had due to the mistakes in my past:
- I don’t know everything (anything?). I ask help as much as I can, from as many qualified people as I can.
- Pricing at the pricepoint of the value I want to deliver, regardless of competition.
- Working with MVP’s, in its definition by Eric Ries, to quickly iterate and learn, in order to help validate product or business ideas
- “What gets measured gets done”. Tracking is everything. Know your numbers by heart. Identify your business crucial KPI’s.
- Optimize for what matters: Business crucial KPI’s are different from company to company, find yours and always optimize for the one(s) that matter.
- Thinking in “Moving the needle”. According to Gabriel Weinberg & Justin Mares, in their book ‘Traction’ (fantastic read btw!), there are about 21 marketing channels to explore at varying phases of your company lifecycle. Use them appropriately! No one size fits all companies.
- Adopting a mindset of “Solve for X” or “Optimize for X”: I default to optimizing for time, hence I really enjoy testing new softwares using an MVP approach.
- Use data to pivot. Based on what I’m solving for and my theses for a given market or product, I can quickly adjust and make the necessary changes to my idea or approach.
- “Done” is better than perfect: To keep iterating on something that is already working, is a waste of time for the most part. Get it working, polish it a bit and launch it!
As you can see, I’ve learned many business lessons. In fact, none of the above are strictly programming lessons. Well maybe except the fact that I need to learn more from better devs.
But learning about the business first is actually the key here. Programming is all about solving business issues with code. In fact you can quote me on that!
Sure, som programming is art. Some is for fun. Some is for learning. But at the heart of it, being able to program means being able to come up with creative – and often automated – ways of solving business problems.
Journeying into Software as a Service
SaaS is a unique business model available reserved exclusively for those who know how to code – or pair up with those who know how.
I will admit, the ability to use ones brain to produce something once and sell it a million times over, with little or no extra cost is WILD. This continues to blow my mind to this day.
In fact, solving issues with code still blows my mind, despite having been at it for over 10 years. It’s like magic 🪄
When I started at Introdus Onboarding in 2020, that’s when the fun began. Being part of a small team of 4, I set out on a SaaS journey including so many ups and downs, and a ton of learning.
The pressure on a technical founder is immense!
Being the technical founder, in a tech-oriented company is incredibly stressful. I’m happy I got to do this at a stage in my life where I had some skills, but no kids or an established day-to-day. According to Y-combinator, the single largest determining factor in whether a startup is succesful or not, is the technical founder.
So, yeah, it bears repeating but: Being a technical founder is very friggin’ stressful!
But it’s also a lot of fun!
If you’re someone who’s capable and have the skills necessary to build, you pretty much get to do what you want and focus on building things that people love. That’s incredibly cool.
Nothing beats launching something new and getting a ton of positive feedback.
I found myself joining a company that already had some tech going: Javascript frontend, Javascript backend and a NoSQL database. Except for the frontend everything was pretty much home-baked (even auth it seemed!). While I wasn’t a big fan of some of the decisions, I also didn’t want to spend too much time rebuilding things and simply decided to stick with it.
So that’s actually what we still have today: A Javascript frontend, a Javascript backend and a NoSQL database. Well, I did upgrade it to Typescript as I’ve grown to love.
Working on a technical product is where things get really crazy, and I pray you have a good group of people that you can spar with and discuss, because on top of being technical you’ll also need to balance:
- Refactorings and making sure things are (somewhat) up to date.
- Writing tests (slowing development, but increasing robustness) – or not (that’s your decision!).
- Spending development time on the most valuable things.
- Interviewing or talking to customers, to understand the pain and form an idea on how to solve a problem.
- Infrastructure: Do you self-manage a server, hosted or on-premise, or do you pay for “app hosting”? Or perhaps you prefer serverless?
There are a ton of decisions to be made, a ton of features to build and only so much time to do it in.
In short; you will want to be as efficient with your time as possible.
At the end of the day, you’re going to be the one with deep technical knowledge, and that translates directly into responsibility. You will have the responsibility to argue for why tests are important (or not), why refactoring (or not) should be a prioritization. Why it matters how well-document the codebase is, how intuitive the UI is and how necessary an admin interface for your colleagues are.
You’re surely also going to see a lot of arguing against, tests being a classic case “that sounds like a waste of time, why can’t we just write code that don’t produce bugs”? Make sure you stand firm on whats important, because being the technical founder also translates, in part, into being the product owner.
How business decisions affect product and vice versa
Inevitably some decisions around the business are so integral to the product that the two go hand in hand. The same is true the other way around.
This may be things as simple what your business model is. Are you a true SaaS, letting users sign up and automatically bill them? Well that’s going to require built in systems for invoicing, plus handling accounts in multiple states (have they paid or not?) as well as a bunch of other things.
Perhaps you would like your product to be self-service with a good onboarding flow, which eliminates or at least postpone the need for sales department until there’s already money flowing in the company.
Additionally, what’s your pricing point? Are you sitting comfortably at a lower end, that most people are comfortable self-serving? Or are you perhaps an expensive enterprise product?
Either way, this too will have an impact on whether your sales funnel should be high or low touch, ultimately affecting whether your product is even feasible as a self-service product.
If you’re at all into business or entrepreneurship these are very exciting challenges, with interesting conversations and considerations about them. But they are challenges too, and it can be hard to come up with the right answer the first time around.
If you’re just starting out, these decisions become even more important because with the limited time and resources you have to build your MVP you can’t go back and constantly re-decide.
Important early product decisions
On that note, there are a few early decisions around the product that I think are absolutely core to how the business (and product) shapes up in the future.
There are four critically important questions early on:
- What do we/I include in our MVP?
- How can we validate the idea we have?
- How can we validate our product market fit?
- How can I validate my product-founder fit?
Unless you’re a lot smarter than I am, this is particularly a point in the business at which you would want to have others to spar with and talk to, because these questions effectively form the foundation of what you’re setting out to do.
So let’s go through them.
What do we/I include in our MVP?
Remember what I said about spending time efficiently? This will be your baptism of fire.
Figuring out what’s not important, is as critical – if not more – than figuring out what is.
The whole point of your MVP is to have something that you can iterate on that can help you learn quickly, in order to make a decision to either pivot, or continue further with more testing.
The goal should be to have one or multiple theses about your product and its target market, that you can go through and test one by one.
I want to clarify that an MVP shouldn’t be thought of as “what is the minimum version of the final product I can build?”. Instead, it should be a small, potentially standalone, product that helps you learn.
Eric Ries (author of The Lean Startup) describes an MVP as such:
The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort or in other words building the most minimum version of their product that will still allow them to learn
My point here being, that you need to shift your focus to learning, not to that of building (towards a final product). It simply isn’t relevant at this point.
As such, it’s paramount that you cut out everything that isn’t critical to the thesis you’re currently testing.
The goal at this stage is really “less is more”. Try to cut out as much as you can. It’s easy to add features, it’s difficult to create value with fewer ones. But fewer creates a better experience, and thats ultimately one of the ways to bring value.
How can we validate the idea we have?
The MVP is used to gather signals of whether the idea you have is feasible, or not.
The whole point of your early stage, should be to get as clear a picture as possible of whether what you have in mind makes sense to sink time into the project.
The more positive signals you get, the clearer your picture becomes, and the more validated your idea becomes.
Validated in this context, is never a guarantee and many things can still go wrong as you continue down the bumpy road of entrepreneurship.
I highly recommend you keep an MVP mindset for a while, and keep iterating between building MVPs and gathering signals.
How can we validate our product market fit?
In everything I’ve read, people I’ve talked to as well as my own experience, I’m afraid the state of a “validated” product market fit is not what you might expect.
Product market fit is not something you will ever “have”, because its a moving target. What’s a hot product in 2015, may have become stale in 2020, or 2025. Not because the product itself changed direction or did anything wrong, but because the market changes which makes it difficult to retain the same assumptions over time.
Because we can’t rely on assumptions, we must build MVPs to test and verify our assumptions.
These assumptions could also be called theses.
Starting to see a pattern?
How can I validate my product-founder fit?
Finally, the product-founder fit. As its slowly becoming a more commonly known term, its a helpful term to keep in mind as it describes the relationship between the product and you.
While that may not seem too important, especially now when you’re just excited about building, but as things become harder – and they will – its important that you’re building something you care about.
The bumpy road of entrepreneurship isn’t easy, especially as a technical founder. If you’re building in an industry in which you don’t love, or even relate to, your customers, and you ultimately don’t care too much about your product, it simply isn’t going to work.
Sure, it might, if you’re the most disciplined individual in the world. But it sure as shit won’t be fun 🙂
And that’s half the point.
Some things that can make things OK even if product-founder fit isn’t 10/10, is if you get to work with an interesting team or interesting technology. If you are anything like me and enjoy interesting technology, that can make up for a lot of downside.
With the power to create, make sure you’re creating something you enjoy and something you care about! If you don’t find it fun now, it’s not going to be fun when you constantly have to deal with customer requests or struggle to raise money or make ends meet.
Putting it together, an example from real life
A short story from my life of a past experience with the above.
In order to validate whether it would be wise to run a SaaS product in the cleaning industry with a focus on great UX/UI, I came up with a thesis:
“This industry would really appreciate something thats easier to use than current solution and has great UX, simplifying workflows”.
This assumption, or thesis if you prefer, was based on the feedback of accidental conversations of cleaners and my own impressions with the available software.
So I thought, hey, let’s build something that could help test if that is right or wrong.
So, I built a sample MVP that tested one core thing only: Is the industry screaming for a more user friendly software?
I did some research trying to brush up on my UX and get very wise about what a good feeling of UX is. I came up with an idea for a simple product to test:
- It must be simple
- It needs to collect email of the user(s) so we can engage in conversation
- It needs to provide real value, otherwise it’s just going to be a fun gimmick.
So in order to satisfy the above requirements, I built the best UX I could; a wizard to guide users through the most central workflow such an app would require: creating a booking with a client. At the tail end of the booking flow, a conversation email would be sent to the client and booking company (plus one for myself, letting me know that someone used the flow).
If you’re curious you can find the MVP right here
The whole point of running this test was to get indications whether my assumption was correct or not, instead of spending months of time trying to build an app that could (potentially (but probably not)) competing with existing solutions.
I ended up getting some positive signals from strangers, as well as the people I’d previously been talking to.
So last on my checklist was the product-founder fit, and ultimately I decided to scrap things here because it’s not a product, industry or audience I care about.
So it would become dreadful very very quickly.
Feel free to get in touch if you want to pick up 🙂
Summary
This post was a bit of an offload. The knowledge in here is from my past experience, as well as from books and articles I’ve read throughout my own journey.
In no way, sense or meaning is this meant as a complain or to say “ugh, my life is hard!”.
I absolutely love every bit of it; the technology, the stress, the emphasis on clever solutions, building things with someone else in mind, and so on and so forth. I think these are extremely interesting and complex challenges, but at no point are they dreaded.
Hopefully it wasn’t too boring of a read and I really hope you enjoyed it, and potentially learned a thing or two.
If there’s anything unclear or confusing, don’t hesitate to hit the comments below 👇