The problem of choice. Call to the experienced.
This might be of an appeal to more experienced software engineers who also want to learn a new stack. I'm one of those, and I am curious about how you deal with this or a similar situation. These are the technical entrepreneurs I'm calling to give me a hand, please...
So I have two ideas I have in mind for a couple of years (it has been that long!), and I have this choice: do I go with the language/platform I am most familiar with but sort of dislike/bored with, or do I go with a language I really like to learn - for these projects. And this has been bugging me and this is what I have been procrastinating the most about in the past few months or even years.
I want to build a website, and - oh gosh - if it were 1998 I'd just build it with what I have: CGI, plain HTML, what have you. But today I have OPTIONS. I have been working with Java since 2001 and I can build just about anything with it now, but I also know quite a lot about its drawbacks. At the same time I really also want to get into Go and I know how easy and quickly you can build the same in Go, with much lesser pain and boilerplate and what not.
To build one of my projects in Go I started working with plain Http router, Gin, Goa, Buffalo, back to plain Http router, back to Buffalo... I can't even track the number of times I went back and forth. And all this time the thing at the back of my head: why don't you do Java, you know it, it's very simple? But. Of course, I couldn't just go the old way. The Spring and Hibernate way. There's now Micronaut and Quarkus out there. There are Kotlin and Scala...
How do you, experienced guys, deal with this dilemma? I'm torn between doing what's easy vs doing what's interesting. Curious to learn about your take on it.
Thank you.
My suggestion is to determine what is your primary goal.
If you want to prioritize having fun building something that maybe can be a business someday then use the shiny new stuff.
If you're main goal is to build a business use the boring stuff you already know so that you can iterate on the business faster.
Came here to say exactly this. Totally agree.
Until recently, I was faced with a similar dilemma when starting to create Voxes. Then I chose the first path, today I can share some conclusions.
If you are a solo founder and your idea is not yet validated, do not hesitate to try to write it in the latest technologies, even if you do not fully know them. However, it is worth choosing those technologies that are already stable on the market and have a chance to replace the current ones in the future. In my case, it would be to change Vue + server API to NuxtJS + Serverless.
You never know if your idea will turn out to be a success. In this case, you will always be able to be happy with it, because at least you've learned something new.
In my opinion, the most important thing in this case is to trim the MVP as much as possible, which will help you validate the idea. If the application is really simple, there should be no problem with turning back on both roads.
The other way I would consider having someone to help, a community built around the project or a validated idea. Otherwise, treat the side project as an experiment and have fun from it, good luck :)
I would change the question slightly; if you have only 6 months to build an MVP, and you hold yourself to account to hit that deadline, what's the fastest route to launch?
With a new set of tools/languages, you will inevitably run into problems that can take days to figure out, and chances are, you will be able to breeze through them in a tech stack you're already familiar with.
Finding product/market fit is the goal, which will take up a lot of cognitive effort, as it's incredibly hard to get there, so try to make the other aspects of your day-to-day as straight-forward as possible.
I chose the route of learning something new rather than keep using the tried and tested.
This was because a major goal for me with side projects is to learn something new. It's great if they make money but I want to pick up technical skills out of it as well. Over the last few years that's led to learning:
At the end of the day, decide what's more important to you.
I think this article can be useful for you: https://www.lunadio.com/blog/how-to-start-a-saas-project-3:-the-stack
Sort of echoing what @Azard said, unless this is a validated MVP that's definitely going to turn into a production codebase at some point, assume it will be a sideproject that gets abandoned eventually and use it as a learning tool first and foremost. If it turns into something bigger, you'll either be comfortable enough to refactor your existing codebase, or you can just rewrite it in Java. That's how I've learned most of the languages I use today, actually.
One of them being Go, coincidentally. I started a few projects in Go, just to learn it, and I really enjoyed the process... so much so that I'd probably consider it my primary language now. Just a suggestion, stay away from stuff like Gin if you're trying to get familiar with the language. I'd recommend using something very simple for routing (gorilla/mux or chi) and using the stdlib for basically everything else. This is the most idiomatic way to use Go. It's generally frowned upon to introduce dependencies, purely because the stdlib is so robust.
If you are facing these types of problems in your device I will suggest you to visit here on routers guide and see the guide about it .
@csallen this is spam ^^
Technical cofounder of Uclusion here. Fit your tool to the problem, not the other way around. In our case we didn't want to maintain deployments so went serverless, which at the time was pretty much AWS Lambdas. On the front end we tried a few frameworks, but React seemed to have the best traction and bang for the buck on developer time. Not sure I really like any of the front end frameworks to be honest, so see what has good examples for the types of problems you're trying to solve.