Do you regret choosing your tech stack?
Do you regret choosing a tech stack that's moving you slower in the direction you want your product to be in?
Trending on Indie Hackers
I'm building the MCU of SaaS 💎
🔥 Roast My Landing Page
Not a single regret because I was very mindful when choosing my tech stack (Ruby on Rails).
New research: People who practice mindfulness tend to choose a better stack.
And now, Rails has Hotwire to future-proof it even longer!
How can no one regret the choice they made?
I started with Python for some of my backend functions but moved to Javascript to reuse code from the frontend.
Also the backend was in Golang and moved to Node as having the same langauge on front and back is huge especially when using a framework like React.
I also regret creating microservices and wish I used a monorepo but they weren't popular when we started.
Microservices have made me regret a lot of things.
I think a benefit with using aspnetcore is that I can choose to move between microservices and monolithic fairly easily. If I am tight on schedule, I can just get lazy and implement whichever is faster/easier and figure out later.
But yes, just to get the concept and setup with all sort of best-practices takes time.
The decision to implement microservices - a massive increase in complexity - is not a "rice or potatoes" decision. If you can build what you need without using microservices... congratulations, you're done! Go home to your family.
Microservices should only be considered if the product that you're building would be impossible any other way.
Imho if you write something that you plan to scale, microservices is the only way to go. Otherwise you will pay the price later...
Of course you have to be mindful not to go too granular.
For example, in Joyform i have all apis in one service, including account management and workspaces and forms crud. However, form submissions go to another service because it has a different scale and its uptime is the most critical part.
Rails developer here. Wondering when Shopify and Github will pay the price?
Wdym? They both use microservices architecture.
Monorepo is something else. It's just how you manage your code and ci/cd. It doesn't affect your deployables. You can use either microservices or a monolith with it.
Github was started as a Rails monolith and was still essentially a Rails monolith when Microsoft bought them. I'd say they GOT paid a nice price for not going the microservices route.
It should be microservices now, though.
I feel as though we might be talking about different things using similar words.
What I'm talking about is the relatively recent introduction of AWS Lambda and similar concepts, the use of which sound cool on paper but massively increase both development and deployment complexity.
Is it common to set up multiple subsystems in a large Rails deployment? Certainly. Some will be monorepo, other orgs will attempt to manage multiple codebases. Rails projects come in many shapes, and some are literally just APIs with front-end bundlers.
There's even been brave folks who have deployed Rails apps to Lambda!
However, it's not much more than a cool proof of concept and certainly nothing like a mainstream approach in our community.
Not sure if you tried aspnetcore. implement microservices is pretty easy there. moving a service to microservice (vise versa) is fairly seamless on it as well. Yes, there are some added complexity but I think it's fairly easy. Maybe i am doing it wrong :P
Out of curiosity, what tooling do you use and how do you handle deployments as well as authentication between the services? I’ve only ever seen Kubernetes handle this well
I can either publish directly from visual studio or via azure devops. Azure can handle multiple deployments. I actually don't need to use docker/kubernates if I just use app services. Authentication is... I use asp.net identity. On identity providers, you can use your own, 3rd party like Auth0 or AADB2C, or host your own identity server.
I was meaning more how you handle your networking and routing between services. Do you have a trusted relationship between services or do they always have to authenticate with each other? And is hosting on Azure not crazy expensive?
cost is slightly lower than aws or at bar. but a lot of time I am using the free tier. free tier gets you pretty far.
I try to follow the best practices for security/identity. It's easy on blazor server-side/aspnetcore. On WASM, just your typical token based with identity provider. I use aadb2c and others. When I get lazy, I have some basic security lib that I use. since no one knows what it does, it's fairly decent :)
I think that we're too often motivated by the new hotness and Indie Hackers especially need to be careful as we have total control over what technologies and architectures we use.
Microservices serve a role but you need to understand that role and its implications.
For the record, I am not immune to this, nobody is. Everyone gets burned by it and that's how we learn to be more cautious.
Microservices are good for when you need to scale your team past 25 devs or so.
I also started out using Django for frontend (and backend), which I regretted. I find a JavaScript framework/library a whole lot better for SPAs. Good to know your thoughts on Go/microservices as I was considering going that route since that's what I'm familiar with at work.
Glad I could help.
I'm sure Go has it's place just not in early stage IH companies.
The most interesting response in here, thanks for sharing.
I personally love the javascript (typescript) everywhere stack. The only huge problem with the stack is the lack of really high level building tools (Rails/Django/Laravel type tools).
Lately I've been eyeing a couple:
NestJS is really more backend API heavy, but it certainly has template rendering.
I personally use tsoa as part of a custom reusable appliance I built (it's called ReadySetSaaS, and it's not ready yet but I'll probably launch it on here sometime in the future). I've got a ticket in my issue tracker to switch to NestJS.
Also I find that while I like the separation of microservices (I use this term lightly -- I mean separate repos for landing, front-end and API -- nothing crazier than that), I've been using SvelteKit and jamming as much as I can into one monolithic "app". That said, I do still run that custom thing (ReadySetSaaS) behind, so it's always at least two things.
The problem is partially the language. JavaScript will never have quite what Rails does (and neither can Python). Ruby is just expressive enough to be capable of DSLs like those throughout Rails and its testing frameworks. There's a reason that 15 years later Django still uses regex in its router—it literally can't have a Rails-like router DSL because Python isn't expressive enough.
Having macros, Elixir is even more flexible, and these kinds of time-saving DSLs are on full display in the Phoenix Framework. I've used a lot in the last couple of years and it's probably the best rapid web dev experience I've had.
That's probably the optimum path, given the limitation of sticking with JS.
Have a look at RedwoodJS as a high level framework. It claims to be the app framework for startups.
Thanks for the tip! I know about Redwood -- it's a framework but what I'm building is actually not a framework, it's an appliance.
The idea is that you run ReadySetSaaS and you don't worry about anything else, and just start building your app, it does the things you would have had to build yourself, and you make web requests to the existing API to make them happen.
More selfhostable backend-in-a-box than library you import.
So for example, if you need to accept user generated content and store it in object storage, ReadySetSaaS takes some ENV config that sets that up for you, and has the endpoints you can call straight from your frontend to do stuff like presigned URLs and taking the actual upload itself to generate a
UGCUploadobject which you can later retrieve/manipulate via the ReadySetSaaS API.I understand. That sounds interesting but there are so many possible features a SaaS backend could need, I assume building something like that is a ton of work.
I just wanted to point you to Redwood as an answer to
"I've got a ticket in my issue tracker to switch to NestJS"
Better point that one pretty high 😆
Straight from the Gitlab issue history lol, I had the same thought you did 7 months ago.
I'm wondering if I'll ever actually do this, it's such a massive change and it's not like tsoa is hurting ...
If you’re looking for something more rails like I hear good things about blitzjs
Yeah unfortunately I'm not really a huge fan of React... But I should look into this (and getting back on the React/Next train all together)
This comment was deleted a month ago.
Sounds like every JS attempt to recreate Rails for the past 15 years 🤣
Bullish on Supabase, Fastify and these new deno workers are interesting as well.
I mainly use React so I just need clean APIs.
I made the mistake of using Python and then later JS on the back-end, too. It's so easy as a beginner to just look at total market share and then think it's a good indicator of what language to use. In reality, it's an indicator of what language people are forced to use and what was chosen for them when their projects started ages ago.
What's good for an indie is very different than what's good for a billion or trillion $ company.
what stack of js did you use?
Most likely a very unpopular opinion but indie hackers should use JS where ever they can. Even if they're currently better at another language.
I'd say it's a popular but extremely destructive opinion. Productivity matters more than conformity in small orgs, especially in orgs of one.
I regret using GatsbyJS. Too slow and don't need most of the bells and whistles. Despite all the bloat it doesn't seem to scale that well either.
Had the same issue with Gatsby, even broke one of my sites after moving off it due to service workers.
I constantly evaluate my tech stacks and I come to the conclusion that C#/ASP.NET Core/Blazor is the most suitable for me. Previously used reactjs/angular/django...
I also do native swift/swiftui in favor of uikit/storyboard. I do native java on android (probably should move to kotlin). I probably will try .net MAUI/blazor in the future or just stay with native.
EDIT: one lesson learned over the years is to chose a good tech stack that will have good support going forward instead of just picking the latest and greatest and have half baked code and year or 2 later, another stack came along and others moved on, while you are stuck...
This is the first time I’ve heard of someone using Blazor. We love our stack of .Net Core and Vue.
Blazor looks cool, but it seemed to bleeding edge for production. How’s it working for you?
I've been using Blazor for several years now. It enables SPA to be developed with c#/ASP.NET. Server side was fairly stable from day 1, WASM is pretty solid since .net 5 (but really, by .net 6, it's pretty solid).
I enjoy the coding experience. The one thing that it lacks vs js frameworks is any ui changes needs to recompile to wasm as oppose to just save and refresh on react/vue. It has built-in auto-compile as you save the file, but it's still not instantaneous. This only bothers me when I am doing minor ui changes and would like to see results instantly.
I moved all my projects/clients to blazor/asp.net core.
So far keeping it simple with my MVP (net-tools.io).
No frameworks, just HTML/CSS/JS/PHP; built image with dockerfile and hosted on GCP cloud run currently. Deployment revisions are a breeze.
I’m a weekend warrior dad, so trying to keep it all simple/feasible. I’d say with this stack it’s been the opposite and development has been rapid 🤓
Not a single regret because I was very mindful when choosing my tech stack (Django).
I see what you did there ;)
No offence! I love Ruby on Rails too :)
I only regret my choices when I overengineered. Keeping it simple stupid but still qualitative is my mantra nowadays. It rarely hurts to switch to greater architectures later on.
For Writings I decided to go with what I knew - Flutter. So I built it in Flutter Web until it made sense. When I saw that it'd be more challenging for me to integrate Rich Text formatting rather than pivot to React, I went with the pivot. So I would not say I regret for choosing my stack, as I learned a lot anyway, technology is just a tool and the mindset is pretty much similar. But, if I go a year back maybe I'd jump straight away into learning React rather than experimenting with a stack and see it fail. In both cases, valuable learning.
Also fell for Flutter web, then more and more Javascript took over :-)
You're not alone. Stay strong.
All my features are real time and I'm so happy with Elixir/Phoenix ! Best choice I ever made
The one thing I've learned with the tech stack is to stick with what you already know.
However, one caveat to this rule is that learning something new can be very motivating. Introducing a new library or framework can be super fun. The trick is to not bite off more than you can chew.
I had other attempts where I went with django (either graphql or rest) + react for the frontend, and I didn't get very far. I was spending a lot of time writing forms, frontend validation, etc. Even though all the functionality was behind some basic CRUD, I was spending a lot of time manually implementing all those create/update/delete forms + tables and single views. Scraped a lot of ideas because form building was a pain. I tried looking around for other solutions, but there was nothing really suited for my needs.
For the latest attempt, I scaled down my tech stach (went back to django's templates) and also the scope (no more high tech stuff, just a very niche blog engine targeted for developers). I made more progress faster and I actually enjoy building it. I plan to officially launch soon after I transfer my current static blog to it to "eat my own dog food" for a while and see what are the obvious things that are missing.
https://devxblog.com/home/
working with emerging technologies such as IoT, AI , Blockchain
I once used firebase for the app consisting social media features. Worst mistake ever.
How come?
A social media app usually has tons of relational data:
Users have posts, posts have likes + comments, likes + comments have users
Firestore is a document based db. Working with relational data is more than painful.
Yes + Creating news feed is just too painful in firebase. Damn the horrors I faced !
I had those features created earlier for different project with laravel and mysql and it was breeze but chose firebase next time because it just felt modern and more to fun to use.
No, because I am on Rails. I always second guess the frontend choices, though.
I regretted one part of our stack for Hardcover that I ended up taking the time to rewrite (within the first 8 months).
Our stack at that time was all TypeScript, Next.js, Express and Hasura as a GraphQL API. Ended up loving Next and Hasura, but Express was slowing things down. It took about 3 weeks, but I migrated that piece to Ruby on Rails (which I’m also much more familiar with).
I’d still use Express for other parts (and actually still plan to use it for Tensorflow.js), but since so much of this application is it’s data model, having ActiveRecord there to rely on makes organization and access easy and consistent for bringing in new devs.
Out of curiosity, how did Express slow you down? Was it that you were doing data-intensive calculations?
We're not doing any major data-processing intensive work at the moment - mostly just storage/retrieval from a DB. Any data-intensive work will all happen in Tensorflow–either in Python or JavaScript. This app is mostly just a web endpoint and background jobs accessing the database. In this case a data model for books (books, editions, authors, genres, series, maps to external data about a book from Google and other sources).
I set this all up with Express using Sequelize after researching JS ORMs. I got everything working, but a few things were never as good as Rails w/ActiveRecord. For example, I wanted to use migrations rather than Sequelize's DB schema sync. That meant adding more libraries for that (so I ended up using Hasura migrations instead). One very basic thing in JS didn't have a decent Sequelize library either: slugifying content. While I could write that piece, I'd rather leverage it. That's going to be a huge part of this app, so relying on Ruby's FriendlyID was a lot more useful. I suspect with a different ORM some of these problems could have been bypassed.
I think the most painful part was working with other people in Express is nowhere near as organized as Rails. Every Express app has its own organization, structure, and way of solving a problem that each new dev needs to learn (ex: what's done in a route vs other js scripts somewhere). With Rails, there's typically Right Way, which means less thought implementing something and less work for new developers to get up to speed. I suspect if I'd worked on large-scale Express apps before–I've only worked on smaller apps with a few dozen routes at most and a small data model–I might have known better solutions. But now after this attempt, I'm not so sure.
That being said, there were parts that were a lot better in JS. We have an importer that reads in a CSV of your Goodreads data and loads it into Hardcover. That piece was faster and more efficient in JS. We also load data from external services via API requests, which is a LOT more efficient in Node due to threading than in Ruby (ugh). Luckily Ruby's new Async library might clean some of that up, but unfortunately, it doesn't work with ActiveRecord.
Overall, I'd go back to the same advice most people give: build with what you're most familiar and productive with. I thought I'd be similarly productive in Express, but that proved to not be the case.
Thanks for the additional context!
No regrets, but productivity
(Laravel, Vue 3, Inertia.js)
Also important factor when choosing a tech stack is how well you know it
Absolutely. In one year I went from Wordpress (doesn’t really count as a tech stack), to bootstrap (sucked), then finally I was like let me do this properly. Building a marketplace, what did Airbnb do? MERN, fine. Took a lot of money, but I wish I did more research in the beginning. Learned a lot though.
Diving into React & learn Vue instead of doing stuff with Svelte before.
I love comparing Svelte to Cinema 4D, it put creativity at the first plan.
I mildly regret using Firestore on Firebase as my DB.
I'd rather use Postgres but Firestore is free at my scale, whereas running Postgres on GCP would've cost me around £60 per month.
All my DB calls are through API's though so when the time comes, I'm confident enough that the re-write won't be massive but it's still going to be a bit of a pain.
I am on Rails and I am starting to have some doubts...
Why doubts? You have lots of options on how to use Rails for a project
I am mostly concerned Rails is not a perfect fit for serving front-end facing content, which has to be quickly served, and easily changed and maintained. I guess statically compiled JS/HTML can be much better optimized for speed and delivery to the browser, independently of your backend. Rails is definitely a killer when it comes to building APIs and backends.
If I had to use Rails (or Laravel, as I do), there is a feature in Inertia to add server-side rendering. You can then put response-caching to make it work even faster.
Alternatively, the website can easily be published to a static version (even automated for deployments), so that you don't have to rewrite the project only to make it static.
(I'm sure there are similar tools for Rails)
Isn't this a hot topic! I am a proud PHP dev but I can work with node or django too ;)
Oh yes! As a co-founder of a company a few years ago our tech stack was in part a compromise because of some of the investors and their choices or portfolio. The thing was early on it was a case of something that was an "unknown unknown" the more I learned and as we progressed in development a better tech stack became more like a "known unknown".
In the past I've been more inclined to just select whatever I'm familiar with and start coding which I think is a predominant position in the indie scene. My approach has changed now and this time my Co-Founder and me took more careful planning and evaluation of tech stack and we are happy now. Choosing your stack is just as any other thing - spend time on it with consideration. Neither spending weeks chasing the holy grail of snowflake tech for your product nor choosing whatever you used previously is a best choice, former resulting in spending too much energy on planning and not executing (i.e. talking to your users & building your product) and latter is may be risky and quickly strangle your progress because of wrong tech choices.
Balancing these two extremes makes me not regret our choices now.
My tech stack is not ideal, however, it was the quickest way we could throw up our initial product.
Now that we have a bunch of subscribers it's kinda holding us back. I plan to completely rebuild it but don't regret our initial choice as it got us traction quickly 💪
You used WordPress, didn't you?
Only because I moved to other frameworks and I’ve designed a lot more components and implemented logic that I cannot reuse.
Not until it's preventing me from getting more customers or making real progress in my business 😁
I personally don't regret our stack, but I guess another way of looking at the question is: Are we moving slow because of the stack [1], or because we don't have the skills to use it in the way we want[2].
In many ways [2] is simpler to fix, hire people who are experts, even in the short term (if you can).
To me, the tech is a choice, its not the deciding factor, if the stack literally cannot do something you need it to do, you have an issue, otherwise you have to work out your next best move. Everyone is scared of "the rewrite [TM]" but if you spend more time worrying about how slow you are going, maybe it is the right choice?
Data scientist here, chose Python/R/SQL and soon to land my first job :)
What was your product?
Well, I am not a web developer as you may expect from a person answering. Right now, I am developing an MVP (freelancer hired) of an app and would like to implement my knowledge of data analysis :)
Yes! Thank you. I was actually extra curious because of your background!
Not at all. I built pingparrot.io on top of Blitz.js and have been really happy so far. The ideal stack for a solo business is the one you know best and are most efficient with. Blitz (which is based on Nextjs) ticks these boxes for me.
No! On the contrary. My tech stack is what makes my business model possible (single founder, bootstrapped, very complex app). I could not have done it with most other tech stacks that are in fashion.
To build the WBE Space I went with vanilla JS + Hugo + Google functions. Super a simple setup but I am super happy with it. Once I am making real money with it I will update.
I'm not sure if I would say I regret our stack, but I've definitely experienced doubtful moments.
For Limey I wanted to go with something super fast and light. I ended up going with SvelteKit, Supabase, and Cloudflare Pages.
In hindsight, I realize that our entire tech stack is in beta.
We've experienced unexpected issues with Supabase's CLI or SvelteKit having random bugs being worked on by the community.
As the project scales, I may think differently, but I'm content with our stack for the time being.
Nope, not at all. I think it's good advice to keep using what you already know. In our case that's Go, Vue, TypeScript, and some server stuff (Traefik, HashiStack, ...).
I've summarized our decisions here and explain a bit how this stack functions:
https://pirsch.io/blog/techstack/
Deta.sh make my dev experience amazing, more productive than ever, more focus on biz than a tech stack
does it work with django?
Interesting. What is their business model?
as far as I know is the deta space
Usually, if I pick a stack because I am curious about it, I'll end up regretting the decision as the learning burden proves to interfere too much with velocity. However, in the case of Flutter backed by Spring Boot, it worked out pretty nicely. That said, I've had extensive experience in this kind of Java framework and was pleasantly surprised at how this public library worked.
Flutter has also been fairly nice to work with. Tough in some ways, especially when it comes to the nesting of components, passing state, etc, but overall pretty nice experience. Performance became an issue eventually though which was a little annoying.
Not really because like @zerotousers said, I put some heavy consideration into where the project is now and where it potentially will be. I went back to Codeigniter for my current job board website.
No regrets but I also look forward to working with other frameworks. But Keeping It Super Simple is the best way to go 👍
Hell no, spending time on choosing my tech stack was the best decision I've made.
Yes, when I started off my Indie journey I thought that I wanted to control of how I build things. I was new to backend dev but unfortunately I was fighting with that over a period of 3-5 weeks. I ended up giving it up and choose low code tool for backend - Xano to store public data and iCloud for private data.
I was able to built an iOS app using low code tool stack. Here is the app https://apps.apple.com/us/app/bird-search/id1593852437
How I built it? https://dev.to/pradeepb28_/ive-built-an-iosmacosipados-app-using-low-code-within-3-days-158o
I am currently look at Supabase to build advance features.
No real regrets, but for the public site of AdminKit (https://adminkit.io/) I've decided to use Gatsby. I'll probably use Next.js if I have to do it all over again, as combining multiple Gatsby plugins can get messy very quickly and the official docs are kinda messy.
+1 for Next.js. It has a lot of configuration set up out-of-the-box (eg Routing, Babel, Typescript), makes server side rendering a breeze, keeps routing simple, and allows backend/API development alongside frontend (again, with a lot pre-configured for faster development)
Tunnel vision 20/20!
I think often times we put too much emphasis on the tech stack. I've seen some amazing projects accomplished in frameworks/languages I would never have chosen myself. Ultimately I believe it comes down to the skill level of the individual(s) working on said project.
Not on current projects no (using ReactJS/Laravel for backend).
Over the weekend I started something new and thought I'd give NextJS/NextAuth a try (tried them briefly but not for a proper project). Regretted it pretty quick and now re-doing it in ReactJS/Laravel.
I regret the design not the tech. I did a pivot and I don't have the time to change the design from multi schema to single schema. But... In the future when there will be enough revenue to pay someone to handle this.... but for now I just ignore this and continue until I hit a wall (a good thing though because it means customers are paying :) ).
It was slow at first, took me a year to get the grasp, but I don't regret it at all.
I love doing it the other way. I'm a wasteful rebel like that. I follow orders at my work, why do I have to do the same in my side projects?
And yes, that's bad advice. And yes, I haven't launched yet. Yes, it's taken me 2+ years.
But I used this opportunity to learn a new language, in 2020.
I looked for a problem to solve, and used that as the basis to go crazy in over-optimizing, over-engineering.
Ain't nobody telling me to stop! If I aim to create that real-time delivery entity to be created just as the order got created, in beautiful concurrency Actor model, in a virtual machine that will fire up all the core you throw it, I damn well will learn that and be slow.
Every day, just a tutorial here, reading here... was the entirety of 2020.
After 2020, in 2021 I finally got something up.
And then I got greedy. I can do local delivery, but why not shipping? Why can't I use EasyShip API? No. I should!
And yeah I'm learning this indiehacker lifestyle the hard way, but I chose to do it so.
It's so exhilarating being a rebel lol.
Oh, I have a list of regrets around Tech Stack.
I tried Golang for a while, it was great getting up and running but then making changes later or maintaining it just became a burden.
I've used different JS frameworks, you build out the product, and everything is going great. Run it for a while and gather feedback, come back to the project to make changes.
Then discover, that the JS framework has changed versions, ah I'll do an update. And then that ends up as a big mistake because you have to try and navigate a migration or rollback but being a developer that then annoys you because something is stuck on an old version.
Microservices ended up a mistake too, If you want to add a feature you end up adding it in a lot of different places, a bit of code here and there just adds up to slow you down.
But yeah, lots of regrets, pitfalls and days spent fixing issues with the tech stack that I could have been doing other things.
Yeah, updating package versions sucks (especially when Typescript is involved and suddenly it identifies all sorts of new errors across your codebase that you need to update)
I know it's trying to be helpful but it feels like it needs a note to tell me only do this when you have a big pot of coffee ready!
Nope. I don't.
My stack is Laravel + Alpine + Blade; and it solves every damn problem I'm working on. Unless you are building an API that needs to serve 1,00,000 requests from day 1; your existing stack works without issues.
If you are already at a level where the tech stack is limiting; you can always hire experts who can port the code to the new stack. If that's not possible, just throw-in some more money temporarily to scale the infrastructure while you find the experts.
I had the opportunity to redesign some of my tech stack.
Probably the biggest change was monorepo optimizations for sharing code and speeding up builds and deploys from >1hr to ~15mins. Definitely worth it there.
I put more time into my setup than I probably should, but I found in past experiences that a bad setup means bad code to workaround it. If possible, I like paying off technical debt sooner, rather than later.
For frameworks, NextJS and NestJS have been good choices so far.
Currently running a firebase stack for rapid (and non rapid haha) prototyping. Highly recommended as long has you don't have complex queries to run often.
Not a single regret because I was very mindfull when choosing my tech stack (Angular).
But daily regrets about my damn supidness of yesterdays work (wtf I was thinking while producing this mess)
Can't go wrong with JavaScript :D
This comment was deleted 2 years ago.