Developers October 14, 2020

What's your tech stack?

Rosie Sherry @rosiesherry

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. 24
    • 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. 3

      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. 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. 5

        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.

    3. 1

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

    4. 1

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

      1. 1

        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.

    5. 1

      Frontend - React.js (CRA) + MobXJS . Complete garbage SEO-wise, hard to migrate to SSR. Slow to develop (personal feeling).

      Have you looked up Next?

      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

          We use React Router, so we consider trying to migrate to After.JS instead sometime in the future.

          Did you know that the authors of React Router (Michael and Ryan) are currently working on a (meta)framework of their own? It's called Remix

          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.

  2. 7

    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. 1

      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. 5

    What is your tech stack?

    Node/TS (Full stack JS) + postgres

    Your reasons for choosing them?

    Isomorphic code is a real thing, not having to context switch is really helpful which means I'm more productive and don't even think about my code in itself but rather about the problem I'm trying to solve.

    Any pain points you can help other indie hackers avoid?

    Oh boy. I have so much to say but I'll stick to one thing: Learn TypeScript.

    It makes the coding experience at least 2x better and at the end of the day it's just JS, still it's really helpful. TS + VS Code will basically act as another team member (even if you're a solo dev, like me)

    1. 2

      +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. 1

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

  5. 4

    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
    • 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.

  7. 3

    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

          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. 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 :)

  9. 2

    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

      Impressive SaaS you are building!

  10. 2

    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

  11. 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 🤔

  12. 2

    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.

  13. 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

      NestJS

      I always ask myself regularly if I am over-engineering something.

      Yes.

      I've had experience with Nest and while at first it does offer some productivity points thanks to its structure and what not... that'll come bite you in the ass sooner or later.

      And since it's inspired by Angular I think this blog post (I wrote it) applies to it: https://karimdaghari.netlify.app/blog/angular-vue-react/

      (Angular <=> nest; vue <=> koa; react <=> express)

      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

          I completely understand. To each their own!

          1. 1

            Just out of curiosity what problems did you run into?

            1. 2

              Not really problems per se, of the top of my head:

              • Boilerplate. Too. Much. Boiler. Plate.

              • Build time, as the app grows, so will the build time.

              • I don't really need webpack for an API. HMR? tsnd is more than enough for me.

              • Providers/Services: the idea is neat, but I don't need a resolver (gql) and a service for each module.

              • Too much abstraction for me: express is an abstraction (on top of HTTP module, which by itself is an abstraction...), typescript itself is an abstraction (on top of JS), so building an abstraction on top of abstraction is no good for me.

  14. 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.

  15. 1

    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.

  16. 1

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

  17. 1

    Our main tech stack:

    Backend - Python/Django, PostgreSQL, Redis
    Mobile - Swift, JS, Kotlin, Flutter
    Frontend - React
    DevOps - Docker
    Analytics - GA + Google Tag Manager.
    Popups - Optinmonster

    Our main tools:

    For having one-to-one or group chat or video calls with team members and clients -Slack, Hangouts, Skype, all messengers

    For sending and receiving electronic letters - Gmail

    For creating a customizable workspace with documents, files, tables, and presentations - Confluence, Google Drive

    For managing tasks, organizing work and keeping all projects on track - Jira Atlassian, Trello

    For discussing projects’ designs - Invision, Sketch, Figma, Photoshop, Adobe After Effects, Flinto

    For collaborative development - GitLab, GitHub

    For scheduling events and meetings - Google Calendar, Calendly

  18. 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

  19. 1

    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.

  20. 1
    • 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/
  21. 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.

  22. 1

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

  23. 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.

  24. 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)

  25. 1

    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.

  26. 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.

  27. 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.

  28. 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.

  29. 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

  30. 1

    I build my blog with Gridsome. I deploy it to Netlify. I set up Netlify CMS for writing.
    I use Github Actions to schedule publishing my posts.
    I also use Google Analytics
    The reason I choose them is that they are completely free. I only spend on the domain name.

  31. 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.

  32. 1

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

  33. 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.

  34. 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

  35. 1

    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.

  36. 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/

  37. 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.
  38. 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.
  39. 1

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

    1. 1

      Actually, if you know JS, TS will be more of a transition/minor change than a breaking/major change.

      1. 1

        Good to know. Thanks :-)

  40. 1

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

  41. 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
  42. 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!

  43. 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.

  44. 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.

  45. 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.

  46. 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...

  47. 1

    Currently on a JAMStack run.

    • Frontend: Typescript, React, Gatsby
    • UI: Tailwindcss
    • Hosting: Netlify
    • CMS: Google Sheets
  48. 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. 2

      I strongly recommend you try out Vue, it just works (tm). As far as design is concerned, you could use a something like VuetifyJS (or check out this awesome list: https://github.com/vuejs/awesome-vue#frameworks)

      Note: Vue has just been upgraded to v3 so it's in a weird spot right now, the ecosystem needs some time to catch up. So if you need an SPA, you can safely use v3. If you need SSR or SSG, use Nuxt (which still uses Vue 2 underneath).

      1. 1

        I'll check it out. Thanks 👍

    2. 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

Recommended Posts