Not a company of one, but honestly a great threat! Let me split it up between professional (lead of a small team (5 people working on different projects) that builds websites / apps for SME's) and personal (fun projects / potential businesses).

- Professionally:

Stacks: WordPress, Laravel, Symfony, NodeJS (TypeScript + Express / Svelte / React / Next).

Reasoning: WordPress is just the go-to for SME's, Laravel & Symfony for very custom or specific websites / apps, NodeJS for simple CRUD API's or when the customer has a high budget.

CI/CD: GitHub (+ GitHub actions).

Servers: Dedicated servers with CentOS or Ubuntu Server, managed manually.

Databases: MariaDB / MongoDB / Redis.

- Personally:

Stacks: NodeJS (TypeScript + Svelte), GoLang, or the language I want to learn.

CI/CD: GitHub (+ GitHub actions).

Servers: Hetzner shared aarch64 (price/performance is good), setup with Ansible, runs everything in Podman containers.

Databases: PostgreSQL / MongoDB.

What is your tech stack?

- NodeJS, ReactJS, Postgres, on Linux (via DigitalOcean)

- Booted with Terraform. Opened & traffic-secured with Nginx + Certbot

- Everything running in Docker

Why did you choose it?

- JS: To reduce context switching, and I have a high level of familiarity with it

- Terraform: To automate & speed up server experimentation

- Docker: To make the app easier to transport & access

Do you think your choices had any impact on your success?

(i think this question is not well formulated. "any impact"? anything & everything can have "any impact" because its "any" as in "anything". It's like asking "Does anything impact you?" "Uh, yes, I am alive. Everything I encounter and perceive impacts me.". Maybe formulate a more specific/less vague question)

I am vague with intent so it is a broad question that can be answered in many ways. You are of course free to interpret the question the way you like.

I guess the reasoning behind why I started asking was because I was curious on how one-man shows run their technical aspects and then I just continued to ask since it became quite popular.

I think it's interesting to see how technical choices evolve over time, especially with very small companies since that is what I am most interested in creating myself.

That's fair! Makes sense.

From my vantage, I would ask: What are 1-3 main advantage(s) and/or disadvantage(s) has this choice had (or do you expect it to have) on your project?

"Any impact" ... taken literally, it is a set of potentially infinite items, due to the term "any". (as far as I can understand it).

any. "used to refer to one or some of a thing or number of things, no matter how much or how many.

Yeah sure, that is great feedback. Maybe I'll make the question more specific for next year :D

Rails, Sidekiq, Postgres, Redis. A little bit of Go. I chose Rails because it gives me a high development velocity, and because I love Ruby. I chose Go for a few things, such as the CLI, for its portability. I do think my choices have had an impact on my success, but only for its effect on velocity. My customers don't tell me how glad they are that I wrote my API in Ruby. But I'm able to build and release new features much faster than my competition. And fix bugs faster. And they do notice that. I follow conventions, so things usually just flow. Some features I've built recently would have also been much harder to build in a language without strong metaprogramming.

- What is your tech stack?

I run an uptime (+ cron job) monitoring + status page service: https://onlineornot.com

Uptime monitoring:

- AWS functions spread across several regions for redundancy

- Node.js

- Postgres

Frontend:

- Next.js (React)

- GraphQL

- Tailwind CSS

Status Pages:

- Remix (React) frontend, heavily cached on Cloudflare Workers

---

- Why did you choose it?

It's what I already knew, and used professionally for several years.

- Do you think your choices had any impact on your success?

No customer has ever asked me "What are you using to build OnlineOrNot?". What they have asked me is "Hey can you extend feature X to support use case Y?".

Building with technology I already knew meant I could respond "Hell yes", and have the feature deployed and released by the next morning (if it fit my roadmap, of course).