Cole South, poker legend turned SaaS guy, has a tweet with general advice for launching SaaS apps. Here are some excerpts and reactions from another poker-turned-software person.
- “If you’re not experienced in SaaS/not a developer, don’t bite off more than you can chew from a technical standpoint.”
Yes, and also: (i) this is true even if you are a developer, and (ii) everything is more complicated than it initially seems. Start very small. - “If you are not a developer, your edge is going to be in creating software that nicely solves a business problem and marketing it well. not by creating something ultra complex.”
Yes–again, even if you are a developer. Much of the Gospel of Patrick is relevant here. - “Increasing your team from 1 dev to 2 devs does not 2x the complexity, it 10x’s it.”
Depending what exactly you mean, this is probably right, but:
i. It’s hard to separate effects of having two devs from effects of having a more complicated project in the first place (which is probably why you took on the extra person;
ii. There are big differences between devs in how well they reduce this kind of overhead, and the best ones can mitigate this almost entirely (or even get you under 2x, because they’re more focused on their domains and have good interfaces both in their software and interpersonally);
iii. Sometimes when you think you’re seeing efficiency gains from having just a single dev, you’re actually just taking on tech debt. Maybe not, and maybe it’s OK to have that tech debt (if the tool will never need to get more complex). But it’s easy to mistake productivity that you’re just borrowing from your future selves for a durable productivity gain. - “Pick a tech stack and developer that prioritizes speed above everything else.”
This is usually good advice, largely because speed is positively correlated with competence and (often) quality. - “I would avoid a trendy tech stack where you need both a front end and back end developer.”
No tech stack in the world is going to magically dissolve the distinction between the front and the back end, but some are definitely going to make it harder for one person to do both. The best way to read this advice is: in light of (1) and (2), don’t do something that has intensive front- and back-end needs, and take advantage of that by using a framework that makes it easy for one person to handle everything in such a situation. - “Don’t use a testing server.”
If your project is simple enough, this is probably good advice: it saves overhead and you should be able to accomplish a lot with automated tests. - “Avoid AWS (way too complex).”
To the extent AWS is complex, it’s because it is solving problems that are complex. If what you’re doing is simple, and you aren’t worried about scaling yet, then maybe you can get away without it. But when you hit a problem you need anything like AWS to solve, using AWS is–relative to the alternatives!–probably going to be simpler, faster, and least likely to require bringing on an extra dev.
I heartily agree that premature worrying about scale is a big leak (see below), but solutions like keeping all your data in flat files / SQLite in version control cause problems out of proportion to the time they save you in the short term.
If your project is so simple that you can get by without AWS or anything like it, good for you! If not, it’s just not that hard to use it from early stages. - “Don’t worry about scalability when you don’t have any customers.”
Yep. - “Push small updates often rather than huge ones rarely.”
Yep. This is often affirmed but more rarely practiced. People say it’s because it helps you debug and remediate (and that’s true), but I think the more important effect is forcing you to code in a way that large changes are composable from small ones. - “[Django is] an older language, but it just works, has tons of premade packages, and it makes development FAST.”
Yes, in that Django has just about the maximum amount of “batteries included” and is great for speed. (Nit: Python is a language; Django is a framework.)
Nate Meyvis 