Someone, somewhere may care. But the important people, the ones who matter. They won’t care what tech stack you’ve used to build your SaaS product.
They may not even know what you’re talking about.
Only a small number of tech people on X/Twitter will care.
And even if they do. Will that stop them from using your software if it’s awesome?
Regardless of what programming language, framework or tech you’ve used?
I doubt it.
Working Software > The Latest & “Coolest” Tech
I’d been working on a project of mine all week.
And yes, I’d been using a newer technology. To migrate the project from an old stack to a newer one.
I decided to see if I could rile people up on X/Twitter. This is the tweet I put out
Blazor > React
— Phillip Hughes (@phil_techuk) August 12, 2024
Prove me wrong
I wasn’t disappointed (more about the response I got in a minute).
My goal with the tweet was to show that getting something out the door is far more important than anything else.
If a user or a customer can’t sign up for your software, pay you money. No matter what tech you’ve used. How fast the software renders. Or that you used a new framework to design the look and feel of the software.
Then, it’s all for nothing.
Have An End Goal In Mind
As I’ve said, I was working on an existing project of mine, Elementary Analytics.
I built V1 using a programming language and frameworks I knew well. Also, I used a hosting provider and model I knew well.
But I had very few paying customers. And it was costing more to run than it was bringing in
So I decided to pivot. I’ve written a blog detailing how I pivoted with my SaaS here.
The idea was to reduce the features inside the SaaS product to focus on doing one or two things well. And to get the cost of running my software startup down to zero.
Turn To What You Know Not What’s Cool
Time was of the essence for me.
I set a deadline to switch the old version of Elementary Analytics off. And get the new one up and running.
So, I had to stick with a programming language I knew well. This was C#.
And with a framework and technology I have used before, Blazor.
As well as use Microsoft Azure to host the new version, but keep the costs down to zero.
This meant using a structure for my project I hadn’t used before. And that the performance of this structure and the underlying tech isn’t “the best”.
But, it meant that 80% of the coding was my tapping into my experience and existing skill set.
And the 20% left, the mental effort was making sure I got something out the door, fast.
Guess what?
Within a week I had a working solution. V2 of my project was live. People could register and start using the product. And it was costing me nothing to run.
Result.
Targeting Tech Folk
Before I talk about why no one cares about your tech stack.
I want to argue the case for it.
I’ve seen quotes saying: “If you can’t argue against your position. You don’t understand the topic well enough”.
Now, if your ideal customer is the tech industry.
Coders, developers, solution architects. That sort of folk.
Then tell people about the tech stack you’ve used. Well, it could be a great marketing tactic.
First, it will get all the people who know, like and use the same tech stack to have a look at your product. They may even start to “compare notes”.
Second, if your tech stack has an advantage, let’s say speed. The tech folk who care about this. They will jump on it. Again, because that’s what they care about.
The list goes on.
But if you aren’t building something for the tech industry.
Then all this is pointless.
B2B Customers Won’t Care
If you’re building software in the business-to-business arena. Customers may understand what a tech stack is. Even know about the tech you are using.
But they won’t care.
If you’re solving a problem. Saving them time and money. Or helping them make more money.
They won’t give two tugs on a monkey’s bollock about your tech stack.
Tech Stack Performance Isn’t Relevant
Going back to my post on X/Twitter.
Where I wanted to annoy “tech Twitter”
Well, it worked.
I fired shots at one of the most popular frameworks out there. That people seem to love and get behind, 100% for some reason.
And yes, I’ve used it on a project.
Only because of the constraints I put in place for the project. It meant that using it kept me under these constraints.
Anyway here are some of the responses I got.
Blazor WASM pages are huge in MB and have terrible rendering performance. Blazor Server racks up $$$ in cloud bills has annoying timeouts/latency. Blazor SSR w/0 interactivity is fine I guess. But then you are back to jQuery code spaghetti days.
— Ryan Shaul (@ryshaul) August 12, 2024
Ease of coding is relative. I love react's mental model personally, blazor is obviously heavily inspired by react. However one thing that is objectively true is that any website built in Blazor will have a worse user experience than if it was built in react (or any JS framework)
— Ryan Shaul (@ryshaul) August 12, 2024
It was all tech stuff.
Benchmark speeds. Rendering issues. The size in megabytes. The cost of hosting it.
And I love the statement. “However one thing that is objectively true is that any website built in Blazor will have a worse user experience than if it was built in react (or any JS framework)”
I’m glad he said objectively. I still don’t full agree with him.
User experience is down to how YOU build something. No matter what framework is under the hood.
They Don’t Care About The Same Thing You Do.
Let’s look at the benchmark speed tests.
The results recorded timings in milliseconds.
FUCKING MILLISECONDS.
Do you think a customer will care if something take 50 milliseconds instead of 20 milliseconds to load?
Even if it takes 5 seconds.
Software that makes it 100X easier to run their business. They won’t care if it takes 5 minutes to load. As long as they get the results.
And I get the gentleman’s point about your perception of a framework.
What I find easy to use and what he does is all relative.
And that was one of the points of my post. I can get something out the door using Blazor, faster than if I used React.
If you’re the opposite, great.
The goal is to get it out the door. That’s it.
B2C Customers Won’t Understand
As I’ve mentioned. I’ve used React, the framework I was calling out.
To try and argue the case for it. (Going back to the quote I mentioned to understand my position).
I’ve built a forum using the React framework. It took me far too long to get something out the door. But that’s me.
My other project, BAITCAMP. After a bit of feedback from fishermen that had downloaded my app. They wanted a forum too, focused on fishing.
I decided to go and build it.
Because I wanted to use the same login provider I used for the mobile app I’d built. Using the same hosting and other assets I had too. React was the best choice.
But this came with some downsides, I had little experience building using React.
It took me over a month to get V1 of the forum live into production.
And it was difficult for me.
But it was the right tool for the job. Because of the decisions I made and the constraints.
If I told all this to a fisherman, do you think they would even know what I’m talking about?
Customers Won’t Understand What A Tech Stack Is
Let’s go back to the speed and performance discussion again.
My ideal customers are men, between 30 and 60 years old, who go fishing as a hobby.
That sit beside a lake or river for 8 hours a day. Patiently waiting for a bite, to catch a fish. Do you think they will even notice how fast my forum loads?
Or even care.
Even the user experience. My first attempt at the forum was awful. So regardless of the perception that React makes for a better user experience. It didn’t because of what I was doing, not the framework.
Again, if I tell all this to a fishermen. The people who I want to become customers of my fishing brand.
They will think I’ve lost my mind.
They have no idea, zero clue about what I’m talking about.
Conclusion: Your Tech Stack Isn’t Important
There’s no right or wrong tech stack when building a software startup.
And what you like about a framework, speed, performance, and user experience.
It’s either irrelevant or down to your perception of that framework. How skilled you’ve become using that tech stack.
More than likely. Your ideal customer will have two reactions when you tell them about your tech stack.
1) They won’t care if it can help them
2) They won’t know what you’re talking about
So the most important thing is to pick a tech stack that allows you to “run as fast as you can”.
You need to get your software over the “finish line”.
Why?
Because while you’re reading about performance. Looking at benchmark metrics, like speed, page size, and render stats. And assume that things like user experience is down to what framework you’ve used.
Someone, who is less skilled than you. Using an older tech stack. And frameworks that aren’t fashionable.
Well, they have shipped their work and are reaping the benefits.
While you are probably arguing with me on X/Twitter.
And that isn’t good for either of us.





