74
113 Comments

What's your tech stack?

How are you building your products today?

  • What is your tech stack?
  • Your reasons for choosing them?
  • Any pain points you can help other indie hackers avoid?
  1. 48
    • Frontend - React.js (CRA) + MobXJS . Complete garbage SEO-wise, hard to migrate to SSR. Slow to develop (personal feeling).
    • Blogging - Ghost + MySQL. No pain points.
    • Backend - Ruby on Rails (api-only) + PostgreSQL, Sidekiq + Redis (background jobs). Fast development, no pain points. 98% test coverage.
    • Infrastructure - AWS. Hard and long to setup, but extremely stable and customizable. Great win in the long-term since we can enjoy AWS credits.
    • DevOps - Terraform + Docker + Bash scripts. We can spin the whole infrastructure in a click, but it takes a good effort to setup initially. Win in the long-term.
    • Continous integration - Circle.CI. Alternative that would work just as great - Github actions. We run security checks, linting both frontend and back-end and running tests with each PR.
    • Roadmap - Trello. Extremely easy to use, but gets painful once you have a lot of tasks. It becomes hard to group tasks or search them.
    • Payments - Stripe. Hard and long to setup custom integrations. Works like a charm apart from that and has a great UX.
    • Error monitoring (frontend + backend) - Sentry. No pain points. Keeping errors at zero (apart from old-school phones and browsers). Some people disable local storage / cookies, so they are not able to use our product.
    • Session recording - LogRocket. No pain points. Great way to see how customers use your product and improve UX.
    • Transactional emails - Sendgrid. No pain points. Easy integration.
    • Analytics - GA + Google Tag Manager. Haven't seen better platform yet. Tag Manager is hard to setup if you haven't used it before.
    • SEO monitoring - Google Search console + Ahrefs. No pain points.

    If you stayed till the end - thanks for reading. I tried to be as transparent and honest as I can. Hope it helps. 🤗

    1. 5

      At what point would you recommend using a third party state library like MobX, instead of just relying on the Context API?

      1. 2

        Initially we were using Context API mainly for authentication. Then the code-base grew, the complexity grew with every context pair introduced. It became hard to maintain. For example, the auth check was called multiple times on switching pages (I think it was related to how Context API renders/updates components). It began to feel like reinventing a state management solution such as Redux or MobX, so we rewritten part of the functionality to MobX + mobx-state-tree.

        Some possible signs that you might need to consider switching from Context API to Redux/MobX is observing how your state moves up the component tree. As the app grows you might end up with multiple nested providers inside the top level App. And state should lie close to the components. Unfortunately, many common use cases end up in such situation. For example: authentication, sidebar menu, notifications, messages etc.. And you naturally start doubting that you might have better chosen more mature state management solution.

    2. 3

      Did you start with all this day one or build up to it overtime as you saw the need?

      1. 2

        We built it up as we saw is needed. Well, Rails, Postgres, React, error monitoring, tracking, payment support were absolutely necessary at the start. The biggest shift happened with the infrastructure. We switched from Heroku to AWS due to ongoing problems with background job processing. The memory was leaking somewhere and we were having server crashes and the jobs were lost forever. We needed to monitor customer orders manually and reschedule them. We could have tried purchasing better Heroku instances, but they were quite expensive, so we decided to migrate to AWS. It took me 6 months part-time to migrate. I was unable to work on new features during that time and I was doubting my decision to migrate due to this fact. But after we successfully migrated, the infrastructure problems just vanished and I am fully relieved.

    3. 2

      I'm curious why you feel the React + MobX is slow to develop. I'm a newbie at web development, so I'd appreciate any info on what I should be careful about.

      1. 7

        Do not get discouraged by it - that's just my personal feeling. Let me explain why:

        • We haven't invested much time writing tests (and no, snapshots do not count as tests. Still better than nothing). That causes us some issues since we need to debug manually with each new feature released. Write tests as much as you can from the start.
        • We have a custom design. Having a theme (at the start) might speed up the development a lot.
        • We recently started using MobX. I am still learning it, but we sometimes end up in weird state situations (let's call it hardly understandable flow) that is not trivial to debug. Hard to explain without code examples.😅
        • Tracking is harder to implement in SPA applications. (conversions, pageviews, etc..).
        • I would say React has a steep learning curve. I lack opinionated decisions, convention over configuration. For example, how to structure folders, how to write css (BEM, styled-components, etc..), what 3rd libraries to choose (there are so many in JS world).

        React is great and keep learning it. However, take it with a grain of salt. It is not a silver bullet solution. Personally, next time I create a new project without the need of complex UI interactions, I would choose Stimulus + Rails server side rendering to try.

        1. 1

          Thanks for taking the time to elaborate! It makes sense, I'll keep those points in mind.

    4. 1

      You can use Jira instead of Trello, it has a free tier to start with

        1. 1

          Perhaps ClickUp as well?

    5. 3

      This comment was deleted a month ago.

      1. 1

        Yeah, Next.JS would be great SEO-wise and performance-wise. It would solve many issues for us. However, migrating an existing code-base is not an easy task. We use React Router, so we consider trying to migrate to After.JS instead sometime in the future. From initial research, it might be easier coming from a CRA app. The cost of learning and the cost of change is high right now, so we will delay the migration until we launch at least several new features to our app.

        By the way, we also tried a couple of prerendering solutions for a quick win but did not manage to make them work for us.

        1. 1

          This comment was deleted a month ago.

          1. 1

            Interesting. Did not know that. Thanks for sharing. I see it is going to be a paid product. However, if it would enable creating websites much faster and easier, I might be down for it.

            1. 1

              I absolutely love NextJS. While it does have a steeper learning curve than React CRA, it's definitely worth it.

              I recently also stumbled across Clutch, and I have been using it to build my React web app MVPs (for speed + convenience).

              I'm yet to try Remix, but will definitely take it for a spin.

  2. 11

    What is your tech stack?

    Its Ruby on Rails all the way through. Server side render HTML, with some Tailwind and Stimulus.js sprinkled on top.

    Postgres for the DB.

    Your reasons for choosing them?

    First of all, it's something that I'm comfortable with. But, compared with a lot of other stacks I feel that the fact that Rails goes with the convention over configuration approach is a huge benefit.

    Yes, you do need a little time to get familiar with those conventions, but once you are there you can iterate incredibly quickly. Simply because the framework takes a ton of work out of your hands.

    Any pain points you can help other indie hackers avoid?

    Avoid overengineering. I may sound like an old fart here, but not all that shines is gold. If your goal is to build something quick stick to tried and tested solutions that you are comfortable with instead of chasing the newest hype.

    (That is not to say that you shouldn't experiment, but that is a different goal then)

    1. 2

      What do you use to host your Rails projects?

      1. 3

        I usually start out just hosting on Heroku, simply because it is so low-friction.

        If the app grows or there's some specific technical requirements that aren't covered by Heroku I use DigitalOcean.

  3. 6

    Currently:

    backend: Rails or Python

    frontend: Tailwind + Vue.js

    development: Sublime + Digital Ocean Server

  4. 6
    • What is your tech stack?
      Web projects: JQuery, Bootstrap, Flask
      Desktop projects: PyQt5, PyInstaller, Python
      Deep Learning: Tensorflow, Keras

    • Your reasons for choosing them?
      Python is easy to learn and has lots of ready to use libraries. My main job requires using deep learning, so there was not many options to choose from.
      Earlier I was using C# and CNTK, but Microsoft dropped the support for it.

    • Any pain points you can help other indie hackers avoid?
      I would suggest to use tech stack that you are most experienced and try not to catch all the trends. Also do not premature optimize everything, because you will waste lots of time when you could launch it earlier and do it when you need it.

  5. 5

    Stack:

    • NET Core: I love C# and the EF Core 5
    • VueJS: With TypeScript and TailwindCSS
    • PostgreSQL: My favorite database, but I also use Informix, MSSQL and MySQL

    Reason:
    I really like to type C# code, and I've tried all popular languages, I think its the best language that suits me. Also I like Visual Studio to debug the backend and Visual Studio Code for the frontend. Microsoft has been doing great stuff latetly, so I trust their tech for my products future. I can use my 8-9 year experience with C# on multiplatform apps. NET Core implements modularity by architecture.

    Pain Points:

    • Maturity of NET Core, sometimes you need to figure it out yourself, but there's always a way.
    • React is more used than Vue
  6. 4
    1. PHP and HTML. Some Javascript/jQuery if needed. MySQL or PostgreSQL

    2. Fast, Easy to run, And also I am quite confident with these stacks.

    3. I hope I can help, usually for PHP developers, there is a tendency of reusing codes, say I need a function for routing, what I will do is I will find my last project, and copy paste that function. After some time, that can take efforts, and so I collect these useful functions into a book, in the hope I myself can really get up fast for upcoming projects.

    If you're interested, you can check it out https://gumroad.com/l/50phpcode/blackfriday It's still in black Friday, so you can get 20% off from $25 (so you get $20).

  7. 4

    For https://bearblog.dev (which currently runs about 2000 blogs) I have the following:

    • Django/python
    • Allauth for authentication
    • Heroku + Postgres
    • Cloudflare CDN

    It's a super simple setup (which is kinda the point here) and is chugging along marvelously.

    The reason I went with this setup is because it is battle-tested and resillient (not to mention I have a decent amount of experience in this framework). The newer the tech stack the more unknown-unknowns you will run into which means more security risks.

    Best word of advice with Django is to use Allauth to handle authentication. Django does have its own auth setup, but it gets messy when you set up your own login flow.

    1. 1

      This is a very similar stack I use for https://www.placecard.me/ and https://www.saaspegasus.com/ (and I especially agree on allauth).

      Only difference is that I run everything on a Linode VPS instead of using Heroku - mostly for cost and flexibility reasons. Though I wouldn't recommend that to anyone without some devops experience!

    2. 1

      I use close to the same! I'm curious what you find messy about djangos auth setup, I'll have to take a look at allauth.

      1. 1

        The issue I find with Django's default auth is that it has a username/password by default instead of a email/password. This means in order to get it to do email/password you need to create a custom user model and some extra steps. On top of that you need to build out the whole forgot password flow and templates, which allauth just does for you.

        1. 1

          I'm curious about this for 2 reasons.

          1. username can be email -we use this for ContractsCounsel
          2. Requiring username to be email limits the number of accounts per email. We found when doing this in the past that there are real-world users who need their own account but share emails.
          1. 1

            Yeah, I did the same thing for https://somewordsfor.me

            I ran into a few hiccups here and there because of it, and still had to build out the register/login/forgot password flow and found it a lot easier to just use allauth.

        2. 1

          Yeah I know what you mean, luckily I did all that once a long time ago so I just recycle the code for every new project. Allauth looks really great though, I think I'll try it out for my latest project, thanks!

  8. 3

    Rails with as much server rendered HTML and little JS as possible.

    Ruby is great to get going quickly, beautiful to write and yes, possible to scale if needed.

    Biggest pain point is getting any of this JS hype/crap to work. Webpack (even simplified via webpacker) - why would anyone do that to themselves?!

  9. 3

    My tech stack:

    • javascript
    • css
    • html
    • ftp server
  10. 3

    What is your tech stack?

    For Primcloud...

    Frontend: Next.js/React, in TypeScript, with Tailwind CSS/UI / Headless UI, and Apollo Client.

    Backend: Microservices, Node/TypeScript, PostgreSQL/TypeORM.

    Deployments: Primcloud uses Primcloud to deploy Primcloud.

    1. 1

      Hey, where do you host these microservices?

    2. 1

      Impressive SaaS you are building!

  11. 3

    All in on the "TALL" stack.

    The other parts are built by people experienced in and dedicated to using Laravel, so everything works together really well.

    The main pain point right now is that the parts are relatively new, and still changing quickly, but I don't see that as a big issue.

  12. 2

    Frontend:
    * VueJS + Vuex or Nuxt for SSR.

    Backend:
    * Django with PostgreSQL.
    * Django Rest Framework or Graphene.

    DevOps.
    * Docker + Kubernetes
    * Github Actions.

    Cloud:
    * Google Cloud.

    1. 2

      Hey Viktor, really curious to know about your experiences using Django Rest vs Graphene. I hear a lot of fellow devs sing praises for using the Rest framework, but I'd love to know you find graphene a better alternative, and in which instances you recommend it!

  13. 2

    TALL STACK | The best stack for the solo deventrepreneur

    • Laravel Monolith
    • Livewire for reactive components and SPA feel
    • Tailwind for design
    • AlpineJs for some minor JS stuff

    Awesome productivity so far, no complaints at all, I love that it's a big monolith and I don't need to be switching context or maintaining 2 codebases.

  14. 2

    I have a background in software engineering with a focus on backend and data engineering. I believe that with certain seniority, programming is all about syntax and paradigms. IMHO, it's way harder to choose the right tools that make you more productive than to select the right tool for the job. E.g., you can solve the majority of problems with all kinds of languages. Still, developers tend to choose fancy languages because they are trendy or because they scale more - even when scalability isn't an issue most of the time.

    • Frontend: Vue3 ( I much prefer the composition API ), Typescript, TailwindCSS, TailwindUI
    • Backend: Lambda w/ Python and/or Typescript. Rust, and Go when it comes to Systems or DevOps.
    • Data: Python, always with Pandas
    • DevOps: Docker, Terraform ( We've open-sourced all our modules here: https://github.com/mineiros-io )
    • CI: GitHub Actions
    • Payments: Paddle
    • Error Monitoring: Sentry
    • Metrics: Grafana, Prometheus

    I use as many AWS services as I can since they seamlessly integrate. The lock-in is acceptable to me. Costs are manageable if you know what you do. Most of the horror stories that you find on Reddit etc. are caused because of poor utilization.

  15. 2
    • Nodejs for as a service API for some very special task.
    • Monolithic Laravel app with Tailwind for styling. PostgreSQL. Maybe will use Livewire in the Frontend.
    • Redis for queues.
    • Digital Ocean for hosting, thinking about using AWS Lambda for some tasks.
  16. 2
    • Laravel, CodeIgniter - PHP, HTML, SCSS, jQuery, Javascript, Chartjs
    • MySQL, MongoDB, Redis ( Beginner )
    • Payment - CashFree - No pin points - for me.
    • Github - easy to use, No pin points - for me.
    • Infrastructure - AWS
    • Internal Communication: Slack
    • Marketing - ActiveCampaign, SEMRush
    • Social Mentions / Brand Value , Sentiment - Brand24, Webhose, Ahrefs
    • Quick development, has prebuild functionalities, time saving - I think. - No pin points.

    Feel free to ask.

  17. 2

    This whole stack is optimized for speed and cost, we are a small team and can't take on tools that add unnecessary complexity, also, most of the team has prior experience with these tools.
    Frontend: React, Gatsby, Typescript
    Backend: Golang, Node.js
    DB: MongoDB
    DevOps: Cycle.io
    Infrastructure: Equinix Metal, Vultr, AWS
    Project Management: Click-Up
    Customer Success: Intercom
    Internal Comms: Slack
    Payments: Stripe
    Analytics: Google Analytics/GTM, Matomo, Jepto, Pandas
    SEO: Ubersuggest, BacklinkSEO, Frase
    Marketing: Hubspot, Mautic and about 20 other small tools (I'll expand or answer any questions about these so feel free to ask!)

    That is a big chunk, but again, feel free to ask about anything.

    1. 1

      I have a similar stack, but I'm wondering why you prefer Gatsby over Next?

      I also run a very small #nocode development agency, and our preferred stack is:

      Frontend: React, Tailwind, Next (costs $0)
      FE Visual Builder: Clutch (costs $0)
      Backend: Supabase (FREE plan is quite generous), ApollographQL

      Just sharing this with you, as using this stack has allowed us to keep our costs really low while accelerating development.

  18. 2

    Backend:

    • Kotlin + JEE (selected parts)
    • PostgreSQL, ActiveMQ, Memcached, ...

    Frontend:

    • Vue, Typescript

    Desktop/CLI:

    • Kotlin MPP

    Mobile Apps:

    • Mostly native.

    Of course, a lot of libraries, tools and programming languages for other parts. Also many services from Amazon AWS, Docker, Github, etc.

    1. 1

      How has your experience been with KMP?

      I'm beginning a project with iOS/Android/Web/Desktop/watchOS/Backend sharing domain entities and with all clients sharing a networking module.

      I'm an Android Engineer full time, so I'm very comfortable with using Kotlin, but I'm worried about the stability of having this much interop when much of it is in alpha/beta.

      1. 1

        First, you need to learn how to write the native implementation. It's not a problem, but it's better to have some knowledge of C/C++, POSIX, and Win32 API. Also, it needed a bit of time to learn how to work with pointers, etc.

        We wrote a simple I/O stack for accessing files and simple functions for HTTP requests. We used ktor clients for HTTP, but it needed libcurl as a dependency (not a problem on Linux nor macOS), so for Windows, we rewrote it to Window's native WinINet API. There is a link below describing how to do so.

        Once we have the native part ready, it was a pleasure to write the business logic in Kotlin. It was Kotlin as you probably know it - you only need to omit JVM based parts.

        So far, no problems with stability or so. It works like a charm.

        For your particular case with the networking module - you will still need a native networking code. For most of your needs and platforms, ktor clients is going to work well.

        We published two articles about our experience:

  19. 2

    For www.dynablogger.com I use:

    • Backend: Ruby on Rails
    • Frontend: TailwindCSS, Stimulus
    • Database: Postgres, Redis
    • Infrastructure: Self managed Kubernetes cluster deployed with Rancher.

    The reason why I love this stuck is productivity. It's a combination that lets me do a lot of things in much less time compared to other tech. Ruby/Rails in particular are a joy to work with and the ecosystem is amazing. Kubernetes allows me to adapt to demand quickly and is a more modern way of managing infrastructure in general. I love this stuff :)

  20. 2

    Backend: Django + Django REST Framework
    Frontend: React + Next.js
    Hosting: Google Cloud Platform (App Engine for backend, Cloud Run for frontend)
    CI/CD: GitHub Actions

    For backend, I chose Django because it's a batteries included framework, with an opinionated way of doing things, which means I spend less time making those kinds of decisions. I chose React because my application requires a high level of interactivity, which would be a hassle to manage with plain JavaScript. I chose GCP because I was able to get the most credits from them and found their docs to be superior to AWS. GitHub Actions was also a solid choice for a CI/CD as I only needed to write a .yaml file in my repo and it just worked without additional configuration.

  21. 2

    Hey Rosie! So here's my stack so far:

    • Mobile app: React Native. I chose it cause I had plenty of experience with React.js so it was a smooth transition.
    • Backend: NodeJS (2 different Node apps, each hosted on 2 servers for higher availability. One app manages CRUD ops and other services, the other one does the AI detections using Tensorflow.js). I chose Node.js cause I'm a Javascript developer and didn't want to delay my progress while learning another language.
    • Those are hosted on DigitalOcean. Excelent service, great documentation, super easy to scale.
    • Files are stored on DigitalOcean Spaces. It made sense given that the backend is hosted there as well.
    • DB: MongoDB hosted on MongoDB Atlas. I already knew MongoDB. I've never had in-depth knowledge of SQL DBs so I chose the option I knew best.
    • I use Sentry to report errors and crashes, from both the app and the backend. Super easy to integrate on both ends, great pricing.
    • Stream (getstream.io) to manage feeds, follow relationships and notifications. Great service and super easy to integrate.
    • Magic links (magic.link) to manage authentication: This one really made auth a lot easier and a lot less stressful as I don't have to store any passwords and it still pretty simple to authenticate via email.
    • The AI model training was done on Google Auto ML. I wasn't a machine learning engineer and Auto ML was very simple to use, nice UI, good documentation.
    • For the website I used Gatsby, hosted on Netlify. This duo has been my goto for a while now and it's very easy to deploy and manage.

    I think that's all 🤔

  22. 2
    • What is your tech stack?

    Web: React, TypeScript
    API: NestJS, TypeScript, MySQL

    • Your reasons for choosing them?

    Very comfortable with them, TypeScript was new but helps me avoid bugs right away (stopped counting how many bugs it already avoided). Keeping Web and Server in the same language makes it much easier for me to code both at the same time.

    • Any pain points you can help other indie hackers avoid?

    I always ask myself regularly if I am over-engineering something. Sometimes I still catch myself doing that but I've learned to avoid it. Use a tech stack that you already know and avoid to over-engineer your code.

    1. 1

      This comment was deleted a month ago.

      1. 3

        Tbh I don't care which framework it is inspired from, as long as the framework helps me be productive and get shit done. I've tried both Nest and just Express and found that I write code faster and more maintainable with Nest, so that's why I choose it. I already used it in multiple projects in the past and never had problems with it, so it's still my #1 choice.

        1. 2

          This comment was deleted a month ago.

          1. 1

            Just out of curiosity what problems did you run into?

            1. 2

              This comment was deleted a month ago.

  23. 2

    Python, Flask, MySQL, PostgreSQL, Vanilla JS

    Why? Because that's what I know and feel comfortable with

    Pain point? Haven't had a lot of pain with Python till now.

  24. 1

    For Hardcover ( https://hardcover.app ), we jumped on the Next.js bandwagon.

    Front-end: Next.js, React, Tailwind.css, GraphQL.
    Back-end: Hasura, Express.js, Bull, Redis, Wordpress, TensorFlow.js.
    Database: Hasura, Postgres.

    We're using headless Wordpress w/GraphQL to generate our blog pages.

    I wrote up a detailed breakdown of how we're using all of these: https://hardcover.app/blog/the-perfect-startup-tech-stack

  25. 1
    • Django
    • Vue/Nuxt
    • Digital Ocean
    • Nginx
    • Sentry
    • Plausible

    Start lean, scales like cake. Python backend is also great for data analytics.

  26. 1

    • MERN
    • Lightweight, highly reliable, easy to learn and to get things done 🙌

  27. 1

    .Net
    Anuglar
    MS Sql
    Azure

  28. 1

    My favorite at the moment is the TEA stack:

    • Tailwind CSS
    • Eleventy
    • Alpine.js

    What I do is mostly happening on the frontend, and this stack is my absolute favorite for when one doesn't need to worry about anything backend-wise.

  29. 1

    I wrote about my tech stack and my process to build here: https://www.hackyexperiments.com/process
    Hope it helps!

  30. 1

    You know it depends on your goals and needs. If you want to reach the best SEO and you don't have a lot of interactivity or frequently changed data you should look at Gatsby.js(static generation is the best option). But if you have frequently changed data and you don't know the data beforehand check Next.js(it supports both static rendering and server side rendering).

    If SEO doesn't matter for you, for example you building some private dashboard or admin panel you can easily use React.js(client side rendering is good option for this).

    I prefer serverless approach where you just write your UI and business logic and less depending on the backend and infrastructure. I don't like using expensive and crappy AWS services and sl things that are overcomplicated, because you spend time on testing and learning a lot instead of doing.

    My suggestion to you Don't overengineer your solution, simplicity is the key. Strive to build with the stack you already know.

    My prefered stack is Next.js(SEO, architecture, api), React.js, Vercel/Netlify(hosting), SWR(requests and caching), Cloud functions, FaunaDB.

  31. 1

    What is your tech stack?
    For Svaracollective which hosts a few hundred pages, I've chosen

    • Frontend: Clojurescript app + Clojure generated static site hosted on Netlify
    • API Gateway: Clojure app hosted on Heroku
    • DB: Firebase
    • Airtable + APIs for marketing automation.

    Your reasons for choosing them?

    • Familiarity with the Clojure ecosystem, plus the same language works on both front-end and backend.
    • Good integration of hosting platforms (Netlify / Heroku) with Git

    Any pain points you can help other indie hackers avoid?

    • Prior to using Netlify, I found managing domain certificates and CDNs were a pain. Netlify solved most of that.
    • Given that Google's Web Vitals puts a high penalty (for SEO) on sites that are slow and/or heavy, its important to have fine-grained control of the web application build and deployment process, else late in your development cycle you'll need to change crucial bits.
  32. 1

    Check out my All-Star React Stack here: https://www.youtube.com/watch?v=FA3pAXKz2fo&t=257s&ab_channel=HarishVenkatesan

    It has Next.js, Bulma, Sass, CSS Modules, React Hook Form, Firebase and Firestore! I have used these technologies for most of my projects, and they work great so far especially for creating a fast MVP!

  33. 1

    My tech stack is F# SAFE (Saturn, Azure, Fable, Elmish)
    And I choosen it because I wanted a modern typed productive stack (and safe :) ).
    Fable does F# to JS translation.
    Elmish is Elm, but better, because F# is a better language.
    Saturn simplifies the use of the AspnetCore.
    Frontend is as simple as you need with Bulma, or as complex and hellish as you want with Material-UI. You can use Sass and everything, even JSS with F# works (you can import anything, the babel import does the trick).
    I use React to drive the UI, Elmish plugs right into "Redux" tools, so it serves that role to those who doesn't know elm.
    The pain points is (as always) bundling and "webpack" hell, I really should ditch it (testing Rollup).
    Backend storage is Azure Tables, but any key-value table store would run it, If I need orchestration and something more complex, then I'm going with Erlang/Elixir tools, I don't want lock-in on any vendor for my data store, so it must be OSS, my Cloud should run in "my machine" if I want/need to change cloud provider, good think almost anything will run on Azure nowadays (except for Amazon locked-in things).
    Azure Devops works nicely with everything NetCore on Linux on Docker, the usual.
    CI/CD is from Azure DevOps and all the Telemetry/Logging/Monitoring is the Application Insights.
    Azure tools are simple to use, and they are not expensive as people say (do they say that? I hear that AWS is cheap, I'm not convinced, also I fear AWS lock-in, Azure ironically has less lock-in) .
    As someone who came from doing mostly C# and was doing native development, I needed something that was better and worked fine for doing backend/frontend and getting my business up running.
    Another stack I also use is Kotlin with Ktor for Android apps (but that's another project).
    The core of my company is a native app made in C++ with the NDK.
    So that's a lot of diverse tools, and we are studying using some Rust, because C++ is costly.

    The only pain point I really have is hiring persons, but I set up a high bar with this tech stack, I guess.
    I mean its not that hard or more complex, it just less popular, which is good, you don't need thousands of people, just a knit of good developers, and knowing people in the core of the tool will always be better than the tool having lots of random users you don't know.
    So that's a good thing in a lot of ways, but also and a bad thing is some other "businessy" metrics. TS developers usually can do well with F#, so that's not bad, just as bad as finding good Typescript developers.

  34. 1

    Node.js + React.js
    Gatsby for statis website generation
    MongoDB & Redis for storage
    Sentry for error handling
    ELK stack for logs
    K8S in case microservice architecture

  35. 1

    I'm really liking my new setup...

    Frontend: React, NextJS, Vercel, Tailwind CSS
    Backend: Supabase (Postgres), Vercel
    Other: Algolia

    Why?
    TLDR: Optimizing for ease-of-use and speed

    NextJS solves SEO issues with React.
    NextJS + Vercel is fairly easy and fast.
    Tailwind CSS makes styling easier and faster, while retaining the ability to customize more than Bootstrap or similar.
    Supabase: a lot of the upside of Firebase, but Postgres. They are adding functions soon. Love their browser console.
    Algolia: UI components for search + filters are great. Very fast search speed.

  36. 1

    Frontend - React, Typescript, Redux, Material UI
    Backend - Go and some Node
    Docs - Docz.site
    Libraries - Golang, JS/TypeScript/Node, React, Python, Ruby
    CI/CD - Github actions
    Infrastructure - Kubernetes, MySQL, Redis, PubSub,
    Payments - Stripe
    Emails - Mailgun
    Roadmap - notion
    Analytics - GA
    Feature Flagging- Molasses

  37. 1

    # Tappy👈
    jitsi + webrtc + REST + electron + react

  38. 1

    Frontend - React.js, Angular
    Backend - Node.js, Java, MySQL, Redis, Spring Boot, Express.js

  39. 1

    Backend Chez Scheme, Frontend Gambit Scheme, with FoundationDB for the database.

    Pain point: do to try to contribute upstream, just get things done.

  40. 1

    I just sit with ECMA5+, usually written in ECMA6 with webpack. Know about VueJS, but my team is not ready to move on.
    My concept was work with custom build with WordPress, PHP, API.
    Considering to add TypeScript next year soon.

  41. 1

    Frontend: Vue, Nuxt, Ionic
    Backend: Firebase
    Host: Netlify
    Analytics: Google Analytics, Ahref
    Marketing: Mailchimp

  42. 1

    Indie Project stack: Typescript/Next.js/TailwindCSS/Vercel/GCP Postgres/Postmark
    Pain point is paying google for GCP SQL instance, otherwise next.js + vercel is very nice

  43. 1
    • PostgresSql

    • TypeORM

    • Type-grahpql

    • Node

    • Relay

    • React

    • Typescript

    • Your reasons for choosing them?

    TypeORM and Type graphql go nicely together, since I can easily expose entities to graphql, as well as making greater abstractions easier.

    Relay and React are made for each other, I started using relay experimental and it has a lot of new features that I have been using. Relay is also very efficient and I see some companies choosing it over Apollo.

    • Any pain points you can help other indie hackers avoid?

    Experimental Relay doesn't have a ton of documentation yet, so it could be hard getting some of then new features, the plus side is that it is very easy to go over the source code as well as the devs answering questions on github issues. I also got a lot of help from some of the relay examples.

  44. 1

    Frontend : React, Redux, Bootstrap, Materila UI
    Backend: Node JS, Express
    Database: MongoDB
    Hosting : Heroku/Vercel
    API: REST-API
    Authentication: Firebase

  45. 1

    What is your tech stack?

    Right now I am using the following tech stack to build https://metado.app.

    Backend:

    • Firebase

    Frontend:

    • React with TypeScript
    • For state management I use only React-hooks nowadays. Before I used Redux with Sagas, but realized, that makes handling (Firebase-)server-state much harder. BTW for handling REST-APIs I usually use react-query.
    • The UI-design is based on Semantic-UI.

    Your reasons for choosing them?

    Firebase is super easy to use and has great user handling.

    React make thinking about the UI very easy with its one way data flow and has a great ecosystem.

    I use TypeScript to circumvent the horrible type system in JavaScript.

    Any pain points you can help other indie hackers avoid?

    As I said before think twice if you really need to use a global state management like Redux. You end in more lines of code and probably more files and make the code harder to reason about, imo.

    Try to use a combination of local state, react context for globals and react-query.

  46. 1

    For the product I'm currently working on:
    Cloud provider: AWS
    Front-end: React (CRA)
    Back-end: Node.JS (in serverless using Serverless Framework and AWS Lambda)

  47. 1

    • Frontend - NuxtJS (SSR or SPA with VueJS) + TailwindCSS. Work's perfectly for SEO if we use SSR and it can be deployed to almost any infrastructure/cdn easily.
    • Blogging - Medium using a custom org - don't have to worry about setting up or managing anything
    • Backed - NodeJS for quick prototyping, Golang for any APIs that have to be fast. MongoDB for the database, Redis for a cache if necessary, and RabbitMQ for a message queue if it's needed
    • Infrastructure - Digital Ocean all the way. Limited features compared to AWS means getting creative with your code but it's amazing for the long term since we have Hatch credits. New Apps platform is a godsend for deploying our frontend/backend code
    • DevOps - Terraform + Docker + Bashscripts. Just can't beat the basics.
    • CI/CD - Github Actions, integrates into our workflow beautifully. Digital Ocean Apps Platform for automatic deployments.
    • Payments - Stripe. It's a pain to set up but there's nothing better on the market IMO.
    • Analytics - Google Analytics. Needed to add some text to our privacy policy, but google's tools are too powerful to pass up
    • Error monitoring - Sentry. Industry standard for a reason.
    • Transactional Emails - Pigeon Post (dogfooding our own product)

    Thought I'd add to this discussion as well since our tech stack is pretty varied.

  48. 1

    We (https://hypi.io) run on the following:

    1. Java
    2. Apache Ignite
    3. Apache Lucene
    4. Kubernetes
    5. CloudFlare
    6. Rust (minor)
    7. Docker
    8. Stripe
    9. GraphQL
    10. OpenFaaS
    11. Pulsar
    12. Bitbucket
    13. FluxCD

    Why we chose them -
    It'd get too long to go give the reasoning for each individual one at a time so just bunched together it can be described as the following:
    One of the core principles behind Hypi is to bring together tech that provides the functionality that has become common place and expected from end users but though simple to the user is often quite the engineering feat to build, run and scale.

    Big tech companies define the defacto standards users expect and so when a developer or small team sets out to innovate they find it's an uphill battle to match let alone out pace.
    We thought we'd go through the pain and climb the hill so that developers using the product start from a baseline that levels the playing field for them.

    Pain points...I could write a book.
    Chief among them however I think is the integration nightmare that comes from having such a diverse stack. Each has its own model, API and philosophy which often bleeds into their APIs. If you're going to do something which has this many or more tech involved explore enterprise integration patterns. Frameworks in the space can make it easier, although they come with their own tradeoffs.

    oh...and choose a language that is easy to learn, write tests for and have sustainable and established best practices. Your future team members will thank you.

  49. 1

    What is your tech stack?
    Recently, I tried GRAND stack which stands for Graphql, React, Apollo, Neo4j Database.
    I wrote a series about building with this stack here
    Why?
    I wanted to learn neo4j so I decided to try the GRAND stack. The major benefits on the backend is that graph databases are easy to model your business requirements in, I had a working graphql server powered by neo4j graph in just 2 hours after finishing my graph model. Apollo client on the frontend as opposed to other data management solutions for React takes away the burden of testing and maintaining common remote-data synchronization logic away from the developer and makes you really productive.
    Any pain points you can help other indie hackers avoid?
    Really try it, it will take you to good old LAMP stack days in terms of productivity. My major point point was css and trying to build out my React components with tailwind, after finally giving up and switching to Ant Design.

  50. 1

    Frontend - React.Js (CRA) i really love working on react but it pain point was SEO. so i switched to Gatsby which is a SSG it's pretty Cool.
    https://codingprep.netlify.app/ my side project.

    Learning Backend Technologies like Strapi

  51. 1

    For APIVIS...
    ReactJS + GraphQL, Axios, and Reactstrap - massaging JSON can be painful, a simple thing such as a link is not a simple link.
    Node.js + Express + Auth0 - No pain points if you learn the fundamentals.
    Google Firestore - A bit slow from cold start, but they have better docs than AWS.
    Auth0 - for authentication, can be tricky to work with many subdomains, ESPv2, and your backend server. Difficult to test locally.
    Google ESPv2 + Auth0 - about 12 steps to much for a simple update, but secure and works with Auth0.
    Google Analytics + Console, for Web and SEO. Just works.
    Google GCF - using as middlewares between ESP and DB. Small pain points.
    Cloudflare - for CDN and DNS API. No pain points.
    Hugo + Netlify - for static website. Small annoying pain points, but works and is fast.
    GitHub - for versioning and CI. No pain points.
    Render - for hosting, no pain points.
    LogDNA - for logging, no pain points.
    Stripe - for billing, no pain points.
    Partial.ly - to glue billing with Stripe and the user setup. Difficult to test.
    Telegram - for AI chatbot. No pain points.
    Yandex - for email, very strange indeed, but works.
    Trello + WhatsUp + Miro Board for ideas, chat, project planning, and agile kanban.
    Hardware: Linux/macOS - Usual pain points with bugs and hardware. But not a problem when you mitigate it with a good backup solution, VPN, Firewall, and Antivirus.

    Reason got tired of Java, strict typing, configuring Tomcat, expensive server costs, and moved to full-stack Javascript in 2010. Also used all imaginable PaaS, IaaS, MaaS, BaaS, and FaaS there is on the market before and now. Built both Angular and React apps. I prefer the old Angular MVC model with controllers, services, and a data model, that reminds me of a Coldfusion framework called FW/1. GCP and AWS work fine. The rest is more out of convenience, existing support, large supportive communities, or because it's free and open source.

  52. 1

    Xamarin + MvvmCross: native UIs and almost-native performance for cross-platform apps plus the productivity that comes with using the C#/.NET ecosystem.

  53. 1
    • Frontend: TypeScript, React, Relay, Material UI, Emotion (CSS-in-JS), Universal Router. Partial SSR.

    • Backend: TypeScript, Node.js, GraphQL.js, Knex.js, PostgreSQL

    • Hosting: Google Cloud Platform (Cloud Functions, Cloud SQL, PubSub)

    • CDN, reverse proxy: Cloudflare

    • Testing: Jest, Puppeteer

    • Logging and error reporting: GCP

    • Emails: SendGrid

    • Analysts: Google Analytics, Matomo

    • CI/CD: GitHub Actions

    • Project management: Asana, Notion

    Reasons:

    • Using JavaScript/TypeScript cross-stack allows reducing technology overhead that a small team or solo founder may face.
    • Using GraphQL allows us to design an API with a minimum number of "endpoints" that can be used universally for many use cases on the UI side, yet avoid refactoring it when UI requirements change (as would be the case with RESTful API).
    • Using serverless infrastructure by GCP allows keeping hosting expenses very low.

    Pinpoints:

    • GitHub Actions is not as good as other CI solutions, but it does the job and integrates well with the rest of GitHub.
    • Same with Google Cloud Logging - it's not the best, but good enough, and having everything under the same GCP project(s) helps to keep things lean.
    • Unfortunately, Relay/GraphQL.js is not that well documented as Apollo, but it works great.

    See https://github.com/kriasoft/nodejs-api-starter - the CI/CD build time is just 30 sec, thanks to Yarn v2 with PnP and Zero-install.

  54. 1
    • Node/Express for the Server
    • Prisma for DB interaction
    • Postgres as the DB
    • NextJS/React on the front-end
    • Heroku/Vercel for hosting

    I just wrote in detail about it yesterday in my newsletter. If you are interested, read more here: https://apvarun.com/newsletter/building-side-project-jusflo-app

  55. 1

    Front-end: React
    Back-End: Node.js
    Server: Firebase with Firestore, using Firebase Auth

    Not everyone loves Firebase, but I've had a great experience with it over many apps. The worst part, as with any serverless cloud computing, are the cold starts.

    Wrote about our tech stack here: https://www.ayrshare.com/our-firebase-tech-stack/

  56. 1
    • Next.js 💯 often wrapped with our Bison toolkit (Prisma, Apollo Client/Server, Nexus, Cypress for E2E testing, Chakra-UI)
    • TypeScript
    • Postgres, DB on Heroku or AWS RDS. Or third-party APIs if I can skip the relational DB
    • Vercel for serverless hosting

    Reasons:

    • Next.js is fast to run, and fast to develop with. It solves lots of typical challenges with isomorphic apps automagically. And it's enjoyable to work with.
    • TypeScript is flexible, but can prevent lots of issues just by having it active.
    • Vercel is fast, easy to deploy to, and can go a long way with the free plan.

    Pain points:

    • Next.js's app lifecycle is something to wrap your head around while learning it. It's awesome though.
    • This setup can also be great for SEO, but might take a little planning to setup the way you want.
  57. 1
    • Frontend - Angular (Flutter for the mobile app). We had some annoying issues with SEO due to Angular sites being SPAs but it's not too big of a deal if it's a SAAS project. You can also get round it with Angular Universal.
    • Backend - .Net Core Web API, PostreSQL, Elasticsearch and Hangfire for background jobs. I'd highly recommend .Net if you want to make your API available to the public at some point as it's really easier to setup with Swagger.
    • Infrastructure - AWS with Terraform to configure it. As others have mentioned it can be hard to get your head round at first, but it offers so much functionality and so many services that it's more than worth it. It's so useful to have all the setup in Terraform rather than doing it through the console as it makes setting up new environments super simple.
    • CI - Bitbucket Pipelines, sometime downtime issues with Bitbucket but other than that it has served me well.
    • Payments - GoCardless. I would highly recommend it!
    • Emails - SendGrid.
    • Analytics - Segment.IO and AWS QuickSight.
  58. 1

    I am learning React.js right now and will add TypeScript to my list of web technologies that I know :D

    1. 1

      This comment was deleted a month ago.

      1. 1

        Good to know. Thanks :-)

  59. 1

    Python, Django, Tailwind, Sendgrid, Airtable - For Remote Leaf

  60. 1

    For https://typeperf.com

    Frontend

    • Next.js
    • TypeScript
    • Tailwind for CSS
    • Apollo
    • XState
    • Zeit hosting

    Backend

    • Hasura + Postgress + 3Factor Architecture
    • Firebase serverless functions

    Other

    • Firebase auth

    Coming up

    • Segment + MIxpanel for analytics
    • Stripe for payments (of course). Definitely Checkout over Elements
    • Rollbar for error tracking
  61. 1

    Front: React, Redux, Tailwind
    Back: Java (Spring) or Python (Flask) depending on project, Postgres
    Other: Prometheus, Grafana, Loki, Ansible, Terraform, Docker, Auth0, Stripe, and any AWS services that make sense and are cost effective

  62. 1

    For piratepx:

    What is your tech stack?

    Frontend: Vue.js v3, Vue Router, Vuex, Tailwind CSS, and Vite to build it all together.

    Backend: Node.js using Fastify and Objection.js. PostgreSQL for the database.

    Hosting: Render.

    It's all open source on GitHub if you want to take a look.

    Your reasons for choosing them?

    Frontend: I had already built a number of apps with Vue.js v2 and Vue CLI, and wanted to learn v3 and Vite. You don't really have to re-learn anything going from Vue.js v2 => v3, which was great. The reduced bundle size and near instant development with Vite has been nothing short of pure pleasure.

    Backend: This was the first time using a web framework other than Express. I think Express is fine, but development seems to have significantly slowed, while Fastify has very active development. The speed of Fastify also intrigued me, as piratepx is a free SaaS app that I'm trying to run as cheaply as possible. The more I can get out of a low-end, single instance, the better. So far, no complaints!

    Hosting: Render's documentation is severely lacking, and their app feels MVP compared to Heroku. But their pricing is very competitive, and they responded to my support request in under 24 hours, so I'm going to keep giving them a try for now.

    Any pain points you can help other indie hackers avoid?

    I decided to co-locate both the frontend and backend in a single repository to make development, deployment, and hosting easier. The frontend is built and then served through the backend as static files. It would likely be served faster through a static site host, but it's unnoticeable at this point.

    All of that to say: It's a pretty easy setup to move quickly with in the beginning, as it helps avoid the pain of multiple repositories, deployments, and hosts.

    1. 1

      Have to check out Fastify!

  63. 1

    React + Typescript + TailwindCSS - I've used these before and I'm comfortable using them. TailwindCSS is very nice.
    FastAPI - I'm building a Python focused project so I looked around and found FastAPI which has been fantastic. It's a great API first backend framework.
    PostgreSQL - Simple, easy, battle-tested.

    For blogging I've been using substack.

    Deploying my application on digital ocean.

  64. 1

    What is your tech stack?

    Backend:

    • NodeJS with Typescript
    • PostgreSQL
    • Redis
    • RabbitMQ (when needed)

    Frontend:

    • React with Redux
    • NodeJS server (express) with server side rendering
    • CloudFront CDN for client-side asset delivery

    Infrastructure/Ops:

    • Kubernetes (currently self-hosted, AWS in the future)
    • Gitlab self-hosted for repo hosting and build pipelines
    • Prometheus and Grafana for monitoring
    • Stripe for payments
    • Segment for behavioral event collection and sending events to other services (GA, Mixpanel, FullStory, etc)

    Your reasons for choosing them?

    Because this is the stack that Ive become very familiar with over the years, both professionally and working on my own projects and have essentially built my own framework around it to allow me to develop things quickly.

    Any pain points you can help other indie hackers avoid?

    First: if you're using Javascript, just bite the bullet and learn Typescript. Once you know it, you'll be able to move faster with greater confidence.

    Second: Always be thinking about how your architecture will evolve, but don't overly pre-optimize at the beginning. Pick a stack you know, but if there are things you know wont scale or don't quite fit, go learn what will work and keep building off that. 99% of projects could be run off the AWS EC2 and RDS free tier (or GCP/Azure equivalent), so knowing how the resources your application needs and how it will perform is important.

  65. 1

    VueJS and JS Cloud Functions have been working for me! I deploy it all with Vercel, which makes it silly simple. However, depending on the needs I might go with a FeathersJS BE + VueJS FE. For a DB either Mongo or Firebase.

  66. 1

    TypeScript, Gatsby / React, Material UI, Emotion, Firebase, Google Cloud Functions, BigQuery if needed

    This tech stack is virtually free to run, productive, and allows me to share types between frontend and backend code. It also scales without me needing to think about servers ^_^

    I know people hate on GCP but I really like it. I just hope they don't discontinue anything I'm using...

  67. 1

    Currently on a JAMStack run.

    • Frontend: Typescript, React, Gatsby
    • UI: Tailwindcss
    • Hosting: Netlify
    • CMS: Google Sheets
  68. 1

    Python, Flask, PostgreSQL, HTML+Javascript

    • This ended up being my stack because Python was the language I was most comfortable in and I didn't want to learn a whole new language to build apps.
    • I think that this was a simple stack to learn but I'm still not very strong in the frontend side of things (HTML+Javascript). I'd like some sort of drag and drop tool that could autogenerate the HTML+Javascript for me so I could just focus on backend stuff
    1. 1

      Why not just hire someone to do frontend stuff for you?

      1. 1

        Not making the profit to hire someone yet 😅. Also being able to do things myself saves me the time of having to communicate my ideal design to someone

    2. 2

      This comment was deleted a month ago.

      1. 1

        I'll check it out. Thanks 👍

  69. 0

    My general philosophy is to keep the stack as simple as possible and use as much existing services as i can:

    • Everything in Typescript
    • Serverless
    • Automate everything

    To achieve this, IMO the best possible stack is this:

    • react native for mobile: b/c TypeScript and great developer experience (if you know what you are doing)
    • next.js for web: b/c TypeScript, great SEO, easy to set up and host via vercel
    • firebase for back-end: allows to avoid most of custom back end code
    • firebase auth for authentication: super easy setup (pain point: custom claims are not working well and not fixable)
    • firebase cloud functions for custom end-points: b/c it supports node + TypeScript (pain point: custom triggers take long to fire sometimes, not fixable for developer)
    • firebase firestore for data storage + api: allows for realtime state update on clients and offline first support.
    • ms app center for build automation: easy to set up (pain point: has a hard 60 min build time limit, if your app takes longer to build you cannot use app center)
  70. 0

    NodeJS! ;)

    I wrote about my stack a few months ago. That’s for when I’m self hosting.

    I’ve also been building quite a bit using serverless technologies recently, and static site generators.

    Interested to hear how many are sticking with Wordpress and how many are experimenting with new tech.

  71. 0

    Frontend:

    • Gatsby

    for styling and components I'd go in this order from "Fastest/Easiest" <---> "Most Configurable for Bigger Projects"

    • Chakra UI
    • Tailwind
    • Theme-UI

    Backend:

    • Hasura
      or...
    • Django
  72. 0

    Do check https://brainpiper.com to kick start your front apps. It will help you reduce app setup time if you're building angular/react/typescript/javascript/rxjs/sass project.

  73. 0
    • Frontend - React with Next.js - Nice for SSR, great documentation. Something I'm already familiar with
    • Backend - Node.js with Express - Considering switching to Fastify, but Express is simple and has a good selection of middleware to get up and running quickly.
    • Database - Postgres. Simple, stable, and well understood.
    • Hosting - Vercel for frontend and backend on Heroku (Free dynos).
      https://twelvemonth.vercel.app/
  74. 0

    I use Go for almost everything... I'm proficient and productive with the language and there is also a great community of developers sharing libraries, utilities and insights.

    I've been using Caddy for setting up web servers, I really enjoy how easy and simple it is to setup and that it maintains my Let's Encrypt certs automatically for me.

    MariaDB, sqlite are my go-to databases. I'm looking to migrate from MariaDB to Postgres in the future.

    DigitalOcean is my cloud provider of choice, pricing is simple and straight-forward. I use AWS when I can't get the reach (point of presence) that I need from DO. I use Vultr for this as well.

    Stripe for payments. Bulma for CSS.

    I use Fathom for my analytics. I've run Fathom with GA at the same time, and I see similar metrics. So I just use Fathom, plus, with Fathom the analytics are available to me and not Google and all of the third-parties they sell/share user data to.

    I use Packetriot (https://packetriot.com) to serve my test deployments on the Internet locally from my workstation and test before pushing out any builds.

  75. 1

    This comment was deleted 3 months ago.

  76. 10

    This comment was deleted a month ago.

    1. 4

      +1 for TypeScript

      Took me long to go all-in with it but I will never look back. Probably saved me many hours of debugging already!

      1. 2

        +1 both of you just for TS. It's a whole new life

Trending on Indie Hackers
I will promote your startup to 50K+ people 213 comments I made Session, a productivity timer that makes $5K/month in net profit, AMA! 43 comments 📈 We raised $500K pre-seed for our Reddit Marketing Tool 12 comments Steph Smith on making $130k w/ an ebook, creating a course in 20 days, and the latest trends 10 comments Feedback, please: does the landing page explain the product? 6 comments Roast my web3 app landing page 6 comments