4 Lessons From Building a SaaS
Dev Leader Weekly 66
TL; DR:
Do things that don’t scale
Feel the pain to help prioritize
Check out these CodeCommute videos!
DotUltimate Giveaway!
You can win a FULL YEAR license for dotUltimate! I gave away licenses earlier this year and have a handful more to give away before the year ends! Now’s your chance to start earning entries here: https://trop.ee/6sc8IO14s0
What’s In This Issue
Exclusive Article: 4 Lessons From Building a SaaS
Making Time Out Of Nothing
I like to keep busy, and sometimes, I realize I am keeping too busy. Often, this is a little bit too late because some things start to fall off—even simple things like taking my vitamins or washing the car. But I like feeling productive; it almost becomes a vicious cycle of trying to remain productive.
Earlier this year I decided to start focusing on building my SaaS, BrandGhost, more seriously. I had been building out some of the ASP.NET Core backend for several months already, slowly adding the features that I needed to keep my social media posting going.
You see, at the start of 2023, I had taken up creating content on social media since I had given up on it a decade prior. But I knew I had to stay consistent and keep posting regularly. But I’m always operating at near my full capacity so going into it I had to have a strategy to make sure I could sustain doing more.
I tried to be consistent with getting out a weekly blog post, but I also told myself I’d make three YouTube videos per week. I couldn’t even keep up with the blogs and the videos were a TON of work. But after a little bit of time, I could build the consistency — but once it started I began layering on more tasks, like sharing the links to my blogs and videos more regularly.
I knew I needed a system to help automate this, so the methodology behind BrandGhost was created and I continued to build out my content in a way that would fit. Unfortunately, no, I was never able to create time out of nothing. But every time I made a bit of progress in consistency through automation, I would layer on one new thing. I repeated this until I was writing up to 6 blog posts per week, multiple social media posts every day across 10+ platforms, 3 YouTube videos, 2 livestreams, and a newsletter ever week.
But I needed time for BrandGhost, and we all have the same number of hours in the day. Something had to give, and I deprioritized writing new blog posts because they were the most effort with the lowest return on my content strategy.
LESSON: We all have the same number of hours in a day. You need to be honest with yourself with what you value, and drop what’s not aligned with your priorities.
User Feedback & User Issues
User feedback is incredibly important. It’s one of the main reasons my last SaaS, Mealcoach, didn’t succeed! We’ve been hard at work making sure we can understand user feedback, listen to their pain points both in our product and in their lives, and navigate what goals that they have for what we’re hoping to solve.
LESSON: User feedback might hurt your feelings, but it’s INFINITELY better to have feedback from users than to have zero users.
We all know the feeling of getting feedback and feeling that little sting that comes along with it. It’s common with things like code reviews or performance review feedback when you hear something that you need to work on. But truly, getting feedback is a huge benefit:
We can learn more about our customers
We can understand if we’re on the right track
We know what we need to prioritize for user goals
… We can fix bugs (not that we have any… ever…)
You must see past that initial little sting feeling — it’s way better that you have something that you can action! You can hear me stream-of-consciousness about this topic in this video:
Which brings me to the next important lesson:
LESSON: Don’t follow all user feedback blindly. Understand the challenges and goals, don’t just implement the first solution you hear.
When you start getting feedback, it can be easy to fall into the trap of just doing anything and everything that users ask. Sometimes these could be AWESOME features and important bug fixes — so I’m *not* suggesting that their feedback isn’t useful.
The challenge comes from not understanding what the feedback is actually telling you. When you have users that provide you solutions, it feels like they’re giving you the answer — but you need to instead understand what goal they have and what challenges they have with meeting that goal. If you blindly implement every solution a customer tells you, you might end up with something helpful in the short term but you’ll likely be building a desperate product offering that doesn’t have a cohesive goal. If you want to hear me blab about this, this video is for you.
All The Reasons We Didn’t Test Software
I’m a big advocate of testing software. I’ve written articles on it, I’ve made videos on it, and I write about it on social media because I think it’s a very important part of being able to create a solid product and service.
But I’ve also written about when testing DOESN’T make sense and followed up with an entire talk on it as well. I’ve found when you’re trying to move fast and just evaluate an idea, it can start to interfere with progress. However, when things start to solidify and become more core to the thing you’re building, it often becomes quite clear you need tests.
LESSON: Be pragmatic. Testing is good, but consider the cost and the value it’s adding. You’re allowed to say no.
LESSON: I recommend feeling a bit of the pain to help understand where to prioritize time and efforts. Losing confidence in your code? Probably time for tests.
LESSON: Try to catch the point in time of the previous statement earlier so that you minimize the pain and impact!
With BrandGhost, there was an obvious point on the backend code that I have been writing in ASP.NET Core where it felt like tests were absolutely necessary. There are a lot of repository patterns with SQL and Dapper in the code — but I started to notice more and more small bugs. “Small” in the sense that they were often single characters missing or added by accident, like a comma, but not small in terms of impact.
Once I started feeling some of the embarrassment and losing confidence in my ability to make changes — it was obvious. I needed tests. I invested time and effort into the automated testing infrastructure. I wrote tests using Testcontainers and xUnit to get the coverage I needed. I did this just in time on the areas of code that were starting to become solidified in our product offering so that we could move forward with the velocity we were used to.
You can hear more about my thoughts on testing for our SaaS in this video:
Do Things That Don’t Scale
And I won’t take credit for this one at all, but we’ve been trying to embody “things that don’t scale“. I realize this sentence probably sounds kind of funny to people, especially those that have not worked in startups and those that have not tried launching their own product/service.
It’s counter-intuitive. We’re literally trying to build something that we can scale up, so why would we do things that don’t? This is the same audience of people, software engineers, who want to use k8s for everything and have a microservice for every line of code that we write. Scale, scale, scale!
LESSON: Do things that don’t scale.
The reason this is counterintuitive is because you’re not at scale. Doing all of the things to try and support you at scale is likely to make you fail early.
There’s no reason for massive horizontal scaling if you have no users
We don’t need a sales team if we can nurture solid relationships early on
You may not need a perfect automated workflow if a human can do it for now
You don’t need to hyper-optimize performance if you haven’t even figured out if the feature is helpful
We don’t need 3000% test coverage on every part of our system if we’re about to backspace half of it by tomorrow
This also brings me back to my earlier point about “feeling the pain” first so you can figure out where to spend your time and prioritize. I talk about this more in this video, with respect to BrandGhost:
Closing Thoughts
BrandGhost has been a ton of fun to build. It’s something I’m very passionate about and something that I find extremely helpful in my everyday life. It’s been a great experience to build this with my close friends and there are countless interesting experiences and lessons that we’ve learned already.
Things are still early for us, and we’re continuing to refine how we want to present our offering to the world in an effective way. But learning, working hard, and working with friends on something I care about is a very fulfilling process.
It never truly feels like work if you’re enjoying it — Even if you periodically have to see some JavaScript near your C# code.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
Weekly Recap
How To Refactor Your Brain – Interview With Dagna Bieda
Software engineers are no strangers to tech debt and the power of refactoring.
But what if you could refactor your brain?
I had the pleasure of sitting down with Dagna Bieda to go over just that! We discussed some awesome passages from her new book, Brain Refactor!
From burnout to imposter syndrome to all things software engineering, hear about how you can clean up some of the legacy code that controls how you think.
Thanks for this awesome chat, Dagna!
Radical Accountability vs Blame Culture – Principal Software Engineering Manager AMA
Having a work environment with a safe place to fail is critical for growth and innovation.
Once we start blaming or instilling fear in people for their mistakes, you’ll quickly see progress grind to a halt.
What do these two different cultures look like? How can we create such a blameless environment?
Let’s discuss.
As with all livestreams, I’m looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
Today we focus on:
My newsletter focused on radical accountability vs blame culture
Jumping into articles/posts from LinkedIn & Reddit
Answering YOUR questions
LIVE CODING – WordPress Migration to Blazor
It’s time! WordPress on AWS LightSail has been non-stop problems for nearly 2 years now.
Time for a change.
I’ll be looking into using LinkDotNet.Blog by Steven Giesel as my blog engine of choice. But migrations are never easy, so this will be the first of many sessions trying to figure out how I can get my blog setup before going live.
Remember — I need to keep as many links active as possible so I don’t ruin my SEO!
C# Recursion With File Folder Hierarchies: Beginner’s Guide
Do you struggle with understanding recursion in programming?
For many people, recursion is a bit of a mind-melter. For others, it just seems to click right away.
In university, I felt like recursion was explained in a theoretical way that didn’t feel effective — but fortunately, I had already been writing enough code to see how it works.
What clicked for me? Using hands-on practical examples and seeing it in action. Let’s try it out!
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram