I help SaaS Companies retain whale clients
In episode 7 of our Never Rewrite podcast, Isaac Askew and I discuss 'risk' - how setting up a project to minimize risk might be risky, and how an iterative replacement of your code decreases risk by increasing your options.
Listen at NeverRewrite.com, Spotify, and Apple Podcasts
A common tech fallacy is that legacy tech will go away if only you build a better version. Make something “better in every way” and then you can get rid of the old version.
When you own the software, you can force change. But you can’t do it by making something better in every way.
Once upon a time writing was only distributed on stone tablets and scrolls. Later we invented books, the printing press, and the internet. Each invention let us distribute writing wider with less cost. Even though it is more expensive and less effective, legacy “writing distribution tech” is still with us; we still produce writing on stone tablets, scrolls, and books.
When we first started distributing written ideas, the only way to get a copy was to find someone who had a copy, borrow it, and pay a scribe to copy it. Later, we invented printing presses which let us mass produce copies. Still later we created the internet which lets us produce infinite copies. Yet legacy “copy creation tech” is still with us; scribes still copy manuscripts by hand. We still have printing presses mass producing physical copies.
Whatever your system, whatever your tech, there will always be something “better” about legacy technology. Sometimes legacy tech is better just because the customer is already using it.
Your new system may be amazing, you may see it as better in every way; remember that your customers have their own opinions and reasons.
When you’re baking at home, for a few people, you can usually double the recipe and it will come out fine.
Quadrupling the recipe, however, rarely works. To get the same results you’ll need to adjust an ever growing list of variables. The extra pans will impact the airflow. The extra mass will change the heat distribution and baking times. As you scale, things like extra moisture will become problems.
Many SaaS Companies start off a lot like a baker working in a home kitchen. You can usually double everything and it will come out fine. Trying to quadruple the service introduces complex problems like concurrency, data loss, partial failures, and stale data.
Just as the transition from home to industrial kitchens has sunk many food startups, the transition from startup to scaleup has sunk many SaaS companies. If you can’t offer repeat customers consistency they won’t come back.
It’s the time of year to look back, reflect, and highlight some interesting pieces you might have missed.
I set a personal goal of publishing every week, or at least 50 articles for 2022.
All told, I published 32 articles - 64% of my goal.
I may not have hit my goal, but I'm very proud of the pieces I did write!
These were the most popular articles that I wrote in 2022:
These were the three most popular articles in 2022 that I wrote in past years:
I became a published author this year, with 2 pieces on leaddev.com
I'm going to spend more time writing in 2023. My goal is to publish 100 pieces, approximately 2 per week.
Happy Holidays and I'll be back in the new year!
The only client experience you can offer clients is the one you have today. Yesterday’s experience is a memory, and tomorrow is a promise.
Delivering iteratively, baby step improvements to your client’s experience, makes the experience better today, tomorrow’s promise more believable, and memories of things improving.
Promising a moonshot keeps the only experience your client’s have exactly the same; and if it was a good one, you wouldn’t need a moonshot.
When your customers struggle with a non-intuitive interface, would they rather:
Wait 6 months while you work on an amazing redesign and brand refresh, or get weekly tweaks that make using your product easier and more intuitive?
Branding and color schemes are about you, improving the UI is about your customers.
Don’t put off customer steps while working on a moonshot like a branding refresh.
You become a Scaleup when your SaaS’s service offering becomes compelling and you start attracting exponentially more clients.
All at once you have a lot more clients, clients with a lot more data.
Solutions that support 1,000 clients buckle as you pass 5,000. Suddenly, 25,000 clients is only months away.
Services that support hundreds of thousands of transactions a day fall hopelessly behind as you onboard clients with millions of transactions.
You finally know what customers want. You quickly find the edges of your system. Money is rolling in from customers and VCs. You can throw money at the problems to literally buy time to find a solution.
But you’re faced with a looming question - moonshots or baby steps.
It’s not about you or your SaaS, it’s about your client’s outcomes.
Moonshots are appealing because they take you directly to where you need to be. Your system needs to scale 10x today and 100x next year; why not go straight for 100x?
Baby steps feel like aiming low because the impact on you is small. But it’s not about you! Think about the impact on your clients.
From a technology perspective, sending emails 1% faster is ::yawn::
But for your clients, faster emails means more engagement, which means more sales.
Would your clients rather have more sales this week, compounding every week for the next year, or flat sales for a year while you build a moonshot?
Clients who churn, or go out of business, won’t get value from the moonshot. Even if you deliver greater value eventually, your clients are better off getting some value now.
Are you delivering value to your SaaS or your clients?
Do you know what’s next for your project?
Do you know why?
Do what and why add up to your goal?
Do you know what to do if they don't?
Imagine getting this whopper in an interview or a take home test:
The United States has been conducting a census once a decade for over 200 years.
Imagine you can iterate the data at a family level, with the family data being whatever format/object is easiest for you.
Find the family with the longest fibonacci sequence of children.
The most fundamental issue is that it’s not clear what the answer looks like. In fact, the 4 of us had 3 different interpretations of what the answer would look like.
Is the question looking for children’s ages going forward?
That would be an age sequence of 0, 1, 1, 2, 3, 5, etc
Or a newborn, a pair of 1 year old twins, a 2 year old, 3 year old, 5 year old, etc
Or is it looking for children born in the sequence? (This is the inverse of the first answer)
A 6 year old, 5 year old twins, a 3 year old and a newborn
Or is it asking about the age gap between children?
In that case you’d be hunting for Twins (gap of 0), a gap of 1 year, a second gap of 1 year, a gap of 2 years, etc.
There are so many ways to be the family fibonacci.
Fairly straightforward computer problems with meaningless mathematics sprinkled on top. Being asked by people who won’t know the implications of any of the 3 answers.
If you are presented with this question in an interview, the correct answer is to thank the interviewer for their time, wish them the best of luck in their search, and end the interview.
In my last article, You Won’t Pay Me to Rescue Your Legacy System, I talked about my original attempt at specializing, and why it didn’t work. I bumbled along until I lucked into a client that helped me understand when Legacy System Rescue becomes an Expensive Problem.
Rather than Legacy System Rescue, I was hired to do “keep the lights on” work. The company had a 3 developer team working on a next generation system, all I had to do was to keep things running as smoothly as possible until they delivered.
The legacy system was buckling under the weight of their current customers. Potential customers were waiting in line to give them money, and had to be turned. Active customers were churning because the platform was buckling.
That’s when I realized - Legacy System Rescue may grudgingly get a single developer, but Scaling gets three developers to scale and one to keep the lights on. Scaling is an expensive problem because it involves churning existing customers and turning away new ones.
Over 10 months I iteratively rescued the legacy system by fixing bugs and removing choke points. After investing over 50 developer months, the next generation system was completely scrapped.
The Lesson - Companies won’t pay to rescue a legacy system, but they'd gladly pay 4x to scaleup and meet demand.
