When deciding on the technical foundation for a project or product, the one advice you hear most is "the goto stack for building [...] is the one you know the best." So by using exclusion, the following was my thought process for choosing the tech base for Birdspotter.
No-code is no option this time. What I have in mind needs more oomph. Sure, Bubble could still be interesting. Yet I'm afraid the learning curve for Bubble may basically be the same as getting my old coding skills (I used to be a software engineer) back up to speed. So no no-code.
I never used Ruby or PHP, so they are off the table, too. As is Python, as I only used it for very simple scripting jobs yet. Objectively, this is a shame, as all three have a huge ecosystem and therefore a lot of ready-made code to build on.
There's a lot of great SaaS boilerplate available for the JavaScript ecosystem. But I never wrote anything worth mentioning in JS. I don't have any alternative when it comes to frontend code, so there is a learning curve anyway. Yet I feel uncomfortable when thinking about using it in the backend.
This leaves me with an old combination for the backend: Java and Spring. Both I know from the past, although both are boring and cumbersome. For the frontend, I plan to use React and Tailwind. (And maybe learn some TypeScript on the way.)
The above is what I wrote on Twitter, what I also discussed with some day-job colleagues during lunch, and what I got valuable feedback for. "Use Kotlin instead of Java" was one. "Spring Boot is way too heavy, use Micronaut instead. Also, Spring Boot makes it way too easy to build a sloppy architecture" a second one. "I really liked TypeScript for the backend. And I wish I had known NestJS earlier" yet another. What do you notice when reading these statements?
First, all are right. They are all experienced software architects and developers and from their point of view, these are valid arguments. Secondly, none of them mentioned anything about the product to build and the value it provides to customers. Their sole focus was on the technology and the process of building for the sake of building.
The point is that none of our (future) customers care about the programming language we use or the perfect software architecture. They care about a solution that helps them get their jobs done. And yes, most likely we will make wrong decisions when starting new projects. But the important thing is to start.
Deal with technical debt, scalability issues, and the like when they are an actual problem at hand, not some potential threat in the future. Everything else is just the danger running into the German "in Schönheit sterben", which literally translates to "dying in beauty." As bootstrappers, we have to handle our resources with care. Time is one of those resources, so use it wisely.
And closing, I made a mistake I noticed mere hours after I sent the Twitter thread mentioned above. It's so obvious it actually hurts: what is it I'm going to build? I do have a mission and a product goal. But how does the product look like? I chose technology before having a clear picture of the solution to build.
Well, there he is again, that former software developer still in me just wanting to code. Still so much to learn.
This post is based on Basic Problem issue #40.
If you liked this, feel free to follow me on Twitter and subscribe to my newsletter.