I have written previously about how we, as technical professionals, misuse the term debt and end up sounding like idiots in a business context. This is meant as a companion, to help better communicate, to our non-professional colleagues, what we mean when we say "technical debt".
As a repeat founder I get the question from entrepreneurs and others: "how do you get your first users?"
For me, this is actually the easiest stage. I think of acquiring and growing a group of users differently based on the scale of the existing user base. There is a great book that talks about going 0 to 1 (https://en.wikipedia.org/wiki/Zero\_to\_One). What I mean here is how to go from 0 users to 1 user.
(a short story inspired by true events)
TLDR: Mere mortals implement best practices for S3 read and write performance, create a million billion s3 objects with their high performance system, try to clean up the really really expensive mess and find themselves in a dimension as vast as space and as timeless as infinity.
Does this sound familar?
Techie: We are drowning in technical debt!
Business person: Oh really! What is it costing us?
Techie: Oh, it’s not that. What I’m saying is the code doesn’t use best practices, there are alot of things hard coded and lots of spaghetti code. It makes the code really brittle.
Business person: But can we still deliver what we promised to Big Co Inc?
Techie: Yes, but we will have to do some workarounds. Working on the system is painful and what could have been a one day job will instead take a week. We really need to refactor!
Business person: Ah. That's good news. Our number one priority right now is Big Co Inc.
Conclusion: You don’t like your job because it is hard and/or annoying. I will tell your dev manager to ask you to work on the weekend.
If you have ever worked with AWS as a developer then you will know what I mean, AWS tools suck. They suck so bad there is an entire industry focused on solving for this pile of suck. For just Infrastructure as Code, for example, there are Terraform, Pulumi and Serverless Framework. AWS is famous for "listening to customers". So what gives? Why do their tools still feel clunky, complex and riddled with infuriating edge cases?
If you have used AWS you know how costs can sneak up on you. I have experience getting a heart stopping bill at a previous startup. With Cyclic I've decided I want to start adding controls and alerts from the start.
I recently found that AWS added Cloud Formation support for Budgets (AWS::Budgets::Budget). You can create a quick budget to to notify you of either actual COST limits or FORECASTED cost limits. Here is a sample Cloud Formation example.
At my last company we had a micro-services architecture. We also focused on recruiting developers who were smart and dedicated, but not yet experienced. When they started we would task them to add some new functionality. This would require on the order of perhaps 20 to 50 lines of business logic.
I recently raised a friends and family round for Cyclic and used an AngelList Roll Up Vehicle (RUV). More on the round later. Multiple founder friends have asked about my experience and why I used an RUV. Here is the Why, What and How: