Questions to Ask Before Joining a Startup

The concept here is closer to "firing your investors" or "buying back your equity", but they haven't necessarily done that yet.

Five-year-old well-funded-and-profitable companies with 50 employees, where you as employee #50 are just there to toil away writing some dumb CRUD backoffice code—are still referred to as "start-ups."

And, in fact, since the other kind of startup dies more often than it succeeds and grows into this kind, most startups that are hiring at any given moment are this kind of startup.

Benefits - very bad.

Both of these are valid reasons to work at a startup, if you have a family to feed and care for.

Sometimes any job is a good job, even if it's only temporary while you try to find the perfect gig.

Edit to add:

I've been in exactly this position. I took a dev job with a startup I knew was a complete loser, run by scam artists. But I had to put food on the table. Fortunately, I was only there about eight months before I landed a real job with a real company.

The dodgy company imploded, exactly as I expected it to.

The ideal order of tasks for a startup usually looks something like this (and I say "ideal" because very few startups actually take paths resembling anything close to this):

1.) Figure out what & for whom you're building the product. The founders should do this before hiring employees.

2.) Validate that the people for whom you're building the product will use it, and ideally will pay for it. The founders should do this before hiring employees.

3.) Take investment. Ideally this would get pushed as late as possible or skipped entirely, both because you get better terms for that money when you've made more progress and because it often comes with strings that prevent you from going back to step #1 if necessary, but it's usually a prerequisite for step #4.

4.) Build the product. If the founders can do this themselves, they're at a huge advantage, because oftentimes you find you need to go back to step #1 after this is complete. But usually you need employees for this.

5.) Charge money, so that it becomes a sustainable business.

6.) Everything else that goes with being an actual business, from getting HR policies right to development practices to career ladders for employees to working out company mission statements.

And if you're doing step #6 before you've completed step #5, there is a very large chance that you've made a critical error in judgment that will kill the company. Why? Because you haven't actually validated step #1, and all the work in steps #4-6 depends upon getting that right. You might have setup a beautiful CI dashboard with 100% test coverage, only to find that all your unit tests & continuous integration need to be thrown out because your product needs to be rewritten in another language because the product concept requires a large & critical library that's only available in another language. You might have spent months developing & building relationships with employees only to find they need to be fired because you need a completely different skillset to build a different product for a different market.

It's fine to want a nice, orderly, 100% tested with CI setup and a robust release process development process as your working environment. At an earlier point in my career, I certainly did. But if that's what you want, I would highly recommend not working at a startup and going to Google instead, where you have a full test suite run on 1000s of machines on every commit and the results of it are instantly visible on their code review dashboard. That's what I did, and it was only when I realized that Google in 1999 was about as far away from that as it's possible to get that I became more comfortable with the codebase being a complete mess as long as it works & has happy users.