5 ms·
Serial one-man SaaS builder here with a pair of soft-landings and one big hit: I would agree with others who have opined that this is overkill. You couldn't pa
by joshmn 6y ago
Serial one-man SaaS builder here with a pair of soft-landings and one big hit:
I would agree with others who have opined that this is overkill. You couldn't pay me to use Terraform or Kubernetes for my SaaS unless it was a much larger team.
My stack usually consists of this: A framework I am comfortable with that removes a lot of boilerplate (happens to be the one I know best in the language I know best), the database I know best, the memory store I know best, Turbolinks for load times, a theme from ThemeForest (with the commercial license), self-hosted analytics, Amplitude, and Heroku.
The author mentions "lessons learned" regarding Clickhouse and Kubernetes. I'm not sure what their original goal was when starting their SaaS. Usually mine is financially motivated more than learning things.
What I'm really saying is that just go with what you know best. Having to scale is a good problem to have. Pre-optimization is the root of all evil — asking "is x the right stack for y?" will always be yes when you ask in the x subreddit.
Stop thinking and build.
- SmellTheGlove 6y agoOOC what framework do you use? More broadly, can you help me with an opinion on my present struggle? Here goes: I have a lot of ideas, a couple of which solve problems for me and I think are even _good_ ideas. However, none have shipped because I'm spending an inordinate amount of time building out what is essentially my own SaaS template. Is it worth investing the time in doing that, or are some of the commercial SaaS templates out there (sjabloon, bullettrain, etc) I prefer Python/Flask, but I'm trying to learn Rails now, since a lot of the small saas ecosystem seems to exist there.
- joshmn 6y agoI'm a Rails guy. I've been working with it for the last 10 years and it (now) allows me to be hyper-productive. I've put other languages and frameworks into production but nothing allows me to focus like Rails does. There is a meaningful amount of boilerplate that remains for any stack if you're using it for a SaaS. It may not hurt to invest in a commercially-available solution that takes care of billing. For some products (super-hyper-MVP), I've gotten away with having a `companies` table with a `state` column which was either `active`, `inactive`, or `past_due`. I would update this manually from Stripe every day. When it became a chore (aka "I am spending an hour on this every day and my time is better spent elsewhere") I only then wrote code to handle it. There are solutions like Recurly or Chargebee that take a way a lot of pain on a platform basis. Those may be helpful in managing some of the complexities, but they come at a cost: financial, vendor-based, flexibility. It's important to keep in mind that your ultimate goal is to get customers validating your idea. While it's important that you conduct a meaningful transaction in exchange for solving their problem, that does not mean you need to handle every single last billing case. Accept their money, let your solution solve their problem, and repeat. If you want to talk more my email is in my profile.
- SmellTheGlove 6y agoThat's great insight and I really appreciate you taking the time to reply. I have it in my head that I need to get to a state where I have the boilerplate "done" - able to handle accounts, users (for areas where the two need to be 1:M or vv), admin, and basic subscription billing. I'm trying to get to the point where I have this thing, and each MVP is just an incremental build on top, but instead I have this half-baked thing and a lot of undelivered ideas. I suppose there are no shortcuts and I need to hammer at it, but as you said, not go nuts with handling edge cases.
- deleted 6y ago[deleted]
- wernst 6y agoI'm working on a product to help developers quickly get started and manage their SaaS projects. If you have a moment I'd like to hear more about your experience. To quote the other commenter: "If you want to talk more my email is in my profile." :)
- amzans 6y agoThanks for sharing your thoughts! To clarify, this has already helped me to ship features to my customers quickly. I actually spend little time working on the stack. Last time I touched the infrastructure components was probably a few weeks ago. Panelbear was originally built and launched in a weekend ($5/mo DO instance with SQLite), and I've been working on it for the past 3 months. I have been releasing a new feature every week. That is, in addition to my full-time job, so most of the time we're talking about 2 hours per day tops. I'd also like to clarify that I am not suggesting this stack should be used by other solo founder SaaS. I actually advice against it in my post :) I just wanted to share my stack, as it has worked really well in my case, and I thought it'd be interesting material for discussion.
- joshmn 6y agoThat's really great, happy to hear. I didn't mean to refute what you shared. In fact I was reinforcing some of your points. Doing things the cheap way is arguably the best way. Learning new tech while building is good, but I wouldn't recommend new tech to build a SaaS. My concern was copycats. Some starters reading your post may have this feeling that "because Panelbear did it with Clickhouse and Kubernetes and Django, that's the only way to do it." What it really should read is "because Panelbear used what he knew best, he was able to focus on getting customers; that's the only way to do it."
- amzans 6y ago> used what he knew best, he was able to focus on getting customers That's what I was going for :) Now I realize that I should have highlighted that part more on the blog post.
- ecf 6y agoPlease, please, please listen to this person’s advice about Terraform and the like. The last startup I was at hired a DevOps engineer to come in to completely containerize our simple Rails monolith at a time where they were just simply way too small to warrant it. Development velocity plummeted. Deploys started to take half an hour. Features weren’t being released. The professionals our app was servicing lost trust in the engineering team. All in the name of checking off a box on the CTO’s list of “things that Google does”.
- slow_donkey 6y agoNot sure what 'containerize' means in this context, but adding a Dockerfile, building the image and changing your box to use docker should definitely not reduce velocity or increase deploy time to half an hour...
- deckard1 6y agoit's never that simple. With docker you have to worry about how containers talk to each other. Which at a bare minimum means exposing ports and adding a network layer. Suddenly you find yourself in the weeds with docker-compose and debating whether or not it's actually suitable for a production environment, when they recommend using swarm instead. Then you find out swarm is on shaky ground and now you're hearing about nomad and ten different other solutions just to avoid k8s. Infrastructure-as-code is a wonderful idea. But the reality is it's a full time job. There will always be orphaned containers and things that need cleaned up and automated. And if you don't, then your environment will run out of space or RAM and all devs will be sitting there doing nothing. Building docker images also takes time, especially if you don't optimize the image. The simplest deploy workflow I've seen was a git hook (post-update, I think) that ran a few commands when the repo is updated. It'd really be hard to make up for the efficiency of that workflow after messing about with docker for days.
- dbmikus 6y agoIf it's a monolith you don't have to worry about composing multiple containers. I've put a monolith in Docker so I could plop it on Google Cloud Run.
- csomar 6y agoI agree about Kubernetes but not about Terraform. Terraform is easy to understand, and it's basically just declarative configuration. You have some Cloudflare records for your domain? You can put them in a file, wiki or declare them in Terraform. So maybe just use Terraform and get the benefit of free deployment?