HACKER Q&A
📣 amichail

Is solo indie dev mostly about avoiding difficult programming problems?


Don't difficult programming problems just get in the way of a someone wanting to create a novel app/game?

And so avoiding difficult programming problems allows you to more easily experiment with novel ideas and achieve your creative vision more quickly?


  👤 muzani Accepted Answer ✓
The original DOS was practically indie. Doom and Quake were indie. Roller Coaster Tycoon was indie and built on Assembly. Minecraft was indie. Dwarf Fortress, Ultima Ratio Regum, and Rimworld are indie.

If anything, evidence suggests that indie is capable of tackling the hardest problems.

How? I would argue that once something is done as a group, there's deadlines. Deadlines create cruft (aka tech debt). Cruft slows down development. You end up with product teams who are incentivized to constantly push out something as opposed to dealing with tech debt. Things that would normally take a month solo end up taking five man months. Instead of running something through your head, there are UX/product/event storming workshops.

You also have to adopt industrial architecture approaches like "clean architecture". You can't pick up obscure codebases like Lisp, or experimental features.

Non indie rewards consistency. You can only be consistent by avoiding risks, and doing a lot of CYA.

Basically, the difference between indie and non-indie is like your obscure cafe and Starbucks.


👤 groffee
Being a 'solo indie dev' means you don't need to deal with people. Code is easy, even 'difficult' problems, people are what get in the way.

👤 skydhash
The main constraints of being a solo developer at scale and time. You cannot scale because that means doing a lot of stuff (coding, support, business planning) at the same time. And you can only work on one or two features, meaning development speed is quite slow.

But coding is very easy. And once you solve something, it stays that way. Unlike conflict with others.