19 ms·

The Tech Stack of a One-Man SaaS

475 points by amzans 6y ago

lnsp 6y ago
This seems like a pretty big stack for a single person to administrate - how much time do you spend on doing operations vs development?
- amzans 6y ago
  Right now the operational effort is pretty minimal to be honest. I spend most of my time developing new features and talking my customers. I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended. Most of the stack consists of "platform" tools, such as the ingress-nginx, external-dns, or cert-manager. So it's stuff I take with me for every project. It's like a personal Heroku I've been building, but way cheaper and fully customizable. I've been iterating on this stack over the years with various other projects, and also learned a lot from running Kubernetes in production at my full-time job, so it's not something I'd advise for someone who just wants to deploy their MVP for the first time.
  - vbsteven 6y ago
    Replace Python/Django with Java/Kotlin/SpringBoot and you pretty much have my preferred project stack, which also organically grew due to being exposed to these platform tools in my day job. Kubernetes/Terraform and friends are really useful as a solo-dev if, and only if you have the required experience with them.
  - Wheaties466 6y ago
    any chance you could expand on this? "I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended."
    - amzans 6y ago
      Regarding docker images, I use the image scanning feature of ECR: https://aws.amazon.com/blogs/containers/amazon-ecr-native-container-image-scanning/ https://aws.amazon.com/blogs/containers/amazon-ecr-native-co... The docs make it look really complicated, but it comes down to enabling the service on the Terraform config. Also for app dependencies, I use bots to open PRs on my repo whenever an important security fix is published for one of my dependencies.
  - jrochkind1 6y ago
    What would you advise for someone who doesn't have the pre-existing k8 expertise etc? The ops environment still looks overwhelming to me, if there's a way to do it sustainably without a really heavy-weight ops infrastructure, I haven't figured it out. Like, something that to me requires like a full-time job just to do ops, although maybe not if you've spent some years learning the ops tools, but then same same.
    - redisman 6y ago
      I don't think diving into kubernetes makes any sense for a 1 person shop if you don't already know it. People love to evangelize about k8s more than your average tech but it's just one (IMHO overkill) way to do things. A better bet I think is to leverage tools from cloud providers. They specifically offer many different easy to use scaling platforms for a premium for small/not experienced teams. Heroku has been mentioned a bunch, something like Elastic Beanstalk on AWS is super easy for the first year or two of a company. Or just go for a single machine somewhere and worry about the 5% chance you need more than that when that happens.
      - amzans 6y ago
        Yes, this is what I would also recommend. You can get really far with the managed services from your cloud provider. If you're already familiar with Docker containers, just that already gives you plenty of options. I think every platform now provides a way to just run containers behind a load balancer with a few simple steps. Yes, maybe it's a form of vendor lock-in, but if your worry is acquiring customers, and growing a company, Kubernetes is probably not helping you in this case.
- romanovcode 6y ago
  Exactly, I was expecting something like React, Next.js, Firebase, Mailchimp. This list looks huge to manage as a solo developer.
aadithpm 6y ago
As a fairly new dev, this is really great information for me. Thanks for posting this. If you don't mind me asking, roughly how much do you spend (time) on this every week? How much of that is split between development, operations and product or business development?
- amzans 6y ago
  Glad you found it useful! Since I have a full-time job too, my time on this project is pretty limited, usually no more than 2 hours per day. That's why I tried to automate and save time as much as I could using Kubernetes operators, well supported open source projects, and most importantly, tools I already feel comfortable with. I don't have hard rules in terms of how I distribute my time, but recently it may have looked like this: - 60% of the time I'm trying to understand the problem I'm solving (talking to customers, researching, evaluating features). - 20% working on features, and issues. - 20% promoting: writing blog posts, documentation, reaching out on Twitter, HN, Indie Hackers. Helping out customers integrate their website / understand how something works. Of course, there's tons of other smaller things here and there, but those are the big "buckets" of my time. Once I know what to work on next, I tend to prioritize as follows: 1) At the start of each week I pick 1-3 topics to work on next (for example writing a new blog post, working on a new feature, or even just writing documentation which I am going to next). 2) Each day when I'm working on my project I pick the most impactful thing I could work on, and start with that. I allow myself to explore a topic in depth, sometimes without a clear goal or deadline. After all it's supposed to be fun if I want to stick to it for the long term. 3) I try to respond to customer emails as soon as I can, and understand why they're giving my product a try. That's my gauge for what to work on the following week.
  - aadithpm 6y ago
    Thanks for taking the time to share this. I've been mildly interested in a side hustle with the primary goal of picking up new technologies but currently lack the motivation to, after a long job search. It's interesting to see how you split your time and how much thought goes into all this. A followup question, if you could; > and most importantly, tools I already feel comfortable with What do you do in situations where X tool would be 'better' than Y tool, but you're comfortable with Y tool? Do you do a comparison of the time/effort it takes to learn AND use X tool vs. Y?
FreekNortier 6y ago
But does Python scale for back end applications?
- derwiki 6y ago
  Ask any number of the very successful companies who use Python
- underdeserver 6y ago
  Yes, it does, as long as performance-bottlenecked code is not in Python (and it usually isn't). In the real world, you may have to extract some hot regions to C++ or Rust or Java, but 99% of your code will scale infinitely.
  - Ozzie_osman 6y ago
    Or, alternatively, if most of your heavy-lifting is already done in the database layer there's less work for Python to do.
  - amzans 6y ago
    My team migrated a service handling >1.6k req/s at peak time, from Scala (Finatra), to Python (Django). Same number of servers (3x c5.large), just higher CPU utilization (from ~15% to 70%). Scala was great, but unfortunately it made it difficult to onboard new team members into the project, so development suffered. Also the rest of our stack is mostly Python, so we couldn't use a lot of the common tooling, and libraries we had built for other projects. We migrated it within a month, and it's been running for almost a year without issues. At some point the service even recorded 3k+ req/s at ~200ms 99p latency. Yeah, maybe not Google scale, but more than enough for 99% of the businesses out there. This service handles about 2.5 billion requests per month from one AWS region. We're a small team, and that's only one of the services we support. Which is great because we don't need to spend all of our time optimizing it.
  - chrismorgan 6y ago
    Notwithstanding this (that Python will scale), Python will force you to scale horizontally a lot earlier than something like Rust. In mid-2013, NewsBlur was using 48 servers to run its Python/Django stack. The workload was reasonably precisely declared (and I could grudgingly see why it used so many servers for its stack), so I was able to run the numbers and confidently concluded that something reasonably efficient (which for me would now mean Rust) could have handled the same workload on one equivalent server, though not with a great deal of headroom, and further vertical scaling might have started running into I/O limitations. But for a one-man thing, I know I would prefer to use a single server as long as convenient, and a 98% reduction in hosting bill is very significant (though that’s a moderately extreme case, and I imagine smaller parts of the code could have been rewritten in a language like Rust to get a meaningful fraction of that resource usage reduction).
brudgers 6y ago
How long did it take you to learn enough about all those technologies? How much of it was on the job?
- amzans 6y ago
  Most of my learning was on the job, and in building some open-source projects that I have released over the years, for example: - https://github.com/anthonynsimon/bild https://github.com/anthonynsimon/bild - https://github.com/traduora/traduora https://github.com/traduora/traduora I still have a lot to learn, but IMO nothing beats struggling with something for a long time, and pushing along until you're no longer terrible at it. I feel that most of what I know I learned by starting projects on topics I initially new nothing about, and sticking to it. Regarding on the job learning, I have been working with Python/Scala for my full-time job over the past 3.5 years, and that helped too. Specially in terms of running multi-regional services, and the challenges that come with that. We run several applications on Kubernetes using AWS (combined >2k req/s at peak time), and that was a big challenge for me from which I learned a lot. Specially when you're on-call, and one faulty node brings down the entire cluster, that fails over to another region and repeat :)
robertlagrant 6y ago
Very, very similar to the tech stack we have in my engineering teams (other than we use Flask and SQLAlchemy instead of Django). Really like it. I've not heard of ClickHouse before, but that looks interesting. (If I had a requirement around time series, I was thinking of checking out Timescale - https://www.timescale.com https://www.timescale.com.)
Ozzie_osman 6y ago
At my startup we use a pretty similar tech stack, except we are on Heroku for infrastructure which makes our life a lot easier, and gives us things like review apps quite easily. One piece we've struggled with is just mypy doesn't seem to play too nicely with Django. It definitely feels like a world of difference between the type support we get in our React app with Typescript and mypy with Django. Would be curious what OP's experience has been with that.
real_ben_michel 6y ago
Super similar to what I use (http://www.casaspanish.co.uk http://www.casaspanish.co.uk). Django has just so much stability, it was an obvious decision for me to go with it. And that's speaking as someone who has mostly worked with NodeJS/React for the past 5 years. I love the pythonic principle of "There should be one obvious way to do it". This helps me cut down on decision making which is something quite annoying to deal with as sole-tech-founder. Now I get to focus on the business, and technology is just a matter of execution.
eric_b 6y ago
It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should follow the stack in this article. There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feeding it is non-trivial (see: ZooKeeper dependency and all the problems you get once you move to a distributed database). Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know. The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles.
- triangleman 6y ago
  Indeed OP uses this sort of stack in his full time job and has learned about all the kinks over the years, while getting paid to do it! I'm working on a side project and it's literally a bunch of .py files in a folder. Libraries include fastapi and sqlite3. I cannot think of a reason to use container orchestration over a "single beefy machine" in almost any use case.
  - mixmastamyk 6y ago
    Side project vs. business with paying customers and bus factor is a different equation.
  - sgarland 6y ago
    Not having to recreate your Python env, not having to worry about dependencies (once they're pinned), the ability to run the app on a hosted service like Fargate instead of managing the server...
- amzans 6y ago
  I agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. If I wanted to start a new project, I can leverage the same stack and be up and running in minutes. Which means I can take advantage of my cumulative efforts for any future project. It's definitely not for everyone as you said, but it might be a good solution for many :)
officialchicken 6y ago
I kinda wish the dogfood part was mentioned earlier... but sure glad I caught it at the end. An article on your analytics bootstrapping would be neat - how (did) you do analytics early?
mvanga 6y ago
Honestly, having gone down this path a year back, just use Heroku for your backend. Maybe Netlify if you want to separate your frontend and backend. The amount of complexity and interdependencies these "here's my stack" posts describe are always a huge cognitive overhead for running a one-person SaaS. Heroku costs more, but there's a reason for it. If you're even remotely making money from your product, and are alone in running the show, it's a no brainer to drop a couple hundred dollars a month to eliminate 99% of your ops headaches: the documentation, the add-on's, the fantastic UI, decent reliability, and ease of operations are totally worth it. Literally the worst thing one can say about Heroku is the cost, and possibly, the inability to build certain complex architectures (which most single-person SaaS services aren't).
- jrochkind1 6y ago
  I've been spending some time looking at moving to heroku, but having trouble figuring out how to use it for a real production for deploy for "only" a couple hundred dollars a month. Is that what you're doing? "Standard" dynos and just a few of them are working for you, I assume, for that budget? In my tests, with a Rails app, "standard" dynos are looking surprisingly slow, possibly unacceptably so. Very curious to hear about other people's heroku formations if anyone wants to share. What platform you're on (Rails or something else), and what your response times look like, would also be interesting.
  - dyeje 6y ago
    Checkout Hatchbox.io, just started using it myself. You basically pay a flat monthly rate for their Heroku-esque management service and then pay for the servers on your provider of choice separately (e.g. DO, AWS, etc).
    - lambda_obrien 6y ago
      I've been looking for something between Heroku (too expensive, too many features) and Dokkku (too much hassle, I have to maintain my own security and patches) and this looks like exactly the thing I wanted, except it looks like it's only for Ruby? I use a combination of Python, Elixir, and Haskell, so I'd love it if they did support other langs.
blitblitblit 6y ago
Presuming you are using Github and were using Angular, I think "Google Chrome" is missing from the "Other" stack - since I have had problems even in Firefox try to get latest Google WebComponent shinies to work.
thrower123 6y ago
I expected a much more boring stack, to be honest.
Axsuul 6y ago
Thanks for sharing! How are you liking Loki so far? I’m looking to migrate off Google Cloud‘s logging offering to Loki but was worried about its maturity.
attollos 6y ago
There is a typo on your landing page: "The short answer is: we doesn't use tracking cookies"
atlgator 6y ago
I expected a lot less for "one man." Kudos to you OP.
nojito 6y ago
The secret behind this stack is not its simplicity, but rather it's simply the stack they know the best.
anonfunction 6y ago
Have you considered Amazon’s SES for transactional email?
- ticmasta 6y ago
  Just a single data point warning: I've had nothing but bad experiences with blacklisted, shared IPs from SES. Everything gets flagged as spam.
deforciant 6y ago
I use similar stack too :) - GKE kubernetes - Managed Postgres (CloudSQL) - GCS buckets for file storage - Cloudflare for DNS - Countour for ingress - Keel for automating deployment updates - Mailgun - Sentry (errors) - Node-RED various little automations such as healthchecks Planning to introduce Elasticsearch too, so far I have been testing the operator and it seems to be pretty good quality. From maintenance perspective GKE is great, as long as the bills are paid, no need to login there pretty much ever. As a one man company this means a lot, I try to never spend any time on ops.
fxtentacle 6y ago
Here's my self-serving advice for every one-man SaaS: Use Heroku. It's super easy to get started. And when you reach $2000+ in monthly bills, hire me to move things over onto dedicated or EC2 so that you'll get 10x that performance for the same price. As for the actual language, I think PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. All those great architectural ideas don't matter much until you have your first $5k monthly in reliable revenue. And by then, you'll have a completely different perspective than what you think you need now.
- taffer 6y ago
  > PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. With JS, do you mean React or jquery or literally JavaScripting the DOM?
  - fxtentacle 6y ago
    I meant some sort of JavaScript framework. I'd say that part mostly depends on personal preference. I'm quite happy with Angular, but I've also had lots of smaller one-off pages where I used jQuery.
- tensor 6y ago
  I'd actually suggest PostgreSQL + Hasura + React with Ant Design or Material UI
  - armatav 6y ago
    This man knows the way. I use this stack and I'm pretty sure I could pump out any SaaS business in about two weeks with it. Host on Heroku, use whatever analytics system you want.
  - fxtentacle 6y ago
    For many newcomers starting out, the Rails CRUD generators are good enough to generate their entire admin area. And Rails comes with sane security defaults. I agree that GraphQL + React will be pretty and work well. But for one-man start-ups, the focus is usually on "looks good enough and kinda works". So I believe I'd go with Bootstrap & Glyphicons, just to get results faster.
mwcampbell 6y ago
Since you're using Python on the back end, which WSGI or ASGI server do you use?
ThePhysicist 6y ago
Seems it's another cookie-less, privacy-friendly Google Analytics alternative. This time from Germany! It's pretty cool that there's so much going on in this space, but is it really wise going into the market with seemingly the exact same features that Plausible, Simple Analytics, Fathom, etc. offer? Even Cloudflare recently entered the privacy-friendly analytics market with a free product, so it seems that market is getting really crowded. Then again, every (commercial) website probably needs such a solution, so maybe the market is big enough. I wonder though if these cookie-less solutions can give people the insights they need? You can do only very simple overall statistics and funnel analyses with this approach. Maybe that's enough for most websites though?
- amzans 6y ago
  Thanks for the feedback. Yes, I understand I'm entering a crowded market, but Panelbear is still in the early stages, and I'm trying to understand what problems my customers have that I could solve / how much value can I bring to them. A crowded market also means more options for you as a customer. Specially when it comes to privacy-friendly tools, not only analytics, I'd argue that there's not enough options yet. I initially built it for myself, as I was not fully satisfied with the existing solutions. And I do intend to offer more features than what you currently see, but unfortunately my time is limited and it's going to take a while to bring Panelbear to the feature-level I'd like it to be :)
zomgwat 6y ago
As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team. The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. I began doing Ruby and Ruby on Rails (RoR) development in 2006. Ruby had been around for awhile but the growing popularity of RoR was driving a lot of changes in the ecosystem in those years. It was a fun time but I was working for a large company that allowed me the time to keep up with everything. I see today’s frontend and container ecosystems in the light of that experience. I’m now more content to wait it out and let the dust settle as much as I enjoy learning new technology.
- ticmasta 6y ago
  You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.
  - zomgwat 6y ago
    Thanks! Best done as an employee is spot on.
    - herodoturtle 6y ago
      If I may chime in here, I would humbly suggest that it is best done by whoever enjoys it. Sometimes that might be your employee, and sometimes that might be you. I guess it depends on where your passion lies, and what your objectives are? I imagine that achieving one's financial ambitions in a relaxed and enjoyable work environment is great - irrespective of which part of the stack one enjoys tinkering with the most.
avan1 6y ago
Glad to see that stack works for author, but honestly one man show's shouldn't be multi lingual stacks at all IMO. for me php (laravel for back and front with blade templates) or js (express and vuejs for frontend) and docker-compose for deploying and developing stuff is fast and enough stack.
ezekg 6y ago
Fellow solo founder here. I feel like this is pretty overkill, most notably k8s (and terraform.) The last company I worked at used k8s and it felt overkill even for them. But if it works for you, great, but I definitely think that'd require spending too much of my time on devops. Maybe I should do a "counter" blog post on using Rails, Heroku, Redis and Postgres. :)
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 ago
  OOC 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 ago
    I'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.
smu 6y ago
Seems like there are a couple of tech stack posts on HN lately and I certainly enjoy reading them. But as a techie, the magic to me no longer lies in the product building, but in the ‘finding the first 10-100’ customers part. Have there been any posts on that lately?
- Wirerack 6y ago
  I'd definitely appreciate seeing something like that too. After a couple of "build it first" failures I've come to see the wisdom in finding your customers and validating your idea first. I've read several of these SaaS walkthroughs and it invariably seems to follow this pattern: 1. Author has a blog with a large following on some topic. 2. Finds niche in that topic. 3. Makes a product and pushes it via their blog. 4. "Incredibly" their product gets tons of customers.
  - amzans 6y ago
    Going from 0 paying customers to 1 is really difficult. Specially if you're asking for a recurring subscription. Getting noticed is one of the hardest parts. Just having a great product is no longer enough. For every Basecamp, there are probably tens, or even hundreds of similar competitors. Can I name a few? Maybe. What about the top 10? Probably not, and that's exactly the problem.
michaelbuckbee 6y ago
Important thing to keep in mind with this article is that this is for OPs data analytics SAAS where he's ingesting a mass amount of data, has different uptime requirements, etc than many other SAAS applications.
naicuoctavian 6y ago
That seems overkill. @levelsio ran his $1M business on "FTP" https://twitter.com/levelsio/status/1327451757975375874 https://twitter.com/levelsio/status/1327451757975375874
deleted 6y ago
[deleted]
vladletter 6y ago
Thank you for the sharing! About pricing: - Do you have any tool for cloud pricing tuning/estimations ? - Are you using specific tool to track all your expenses in general ?
- amzans 6y ago
  I have used https://calculator.aws/ https://calculator.aws/ in the past, but to be honest it's difficult to account for the egress costs/networking fees using their calculator. Simple things like networking between Availability Zones/Regions can really creep up in your monthly bills if you don't watch out. I do track my expenses on a sheet manually, using a ballpark figure. At the end of the month I compare it with my AWS bill. If something seems off, I investigate it further. But I don't try to predict exact figures, more like expected ranges. I do miss the fixed-cost nature of DigitalOcean/Linode. I didn't have to worry about sudden charges, you pay $20/mo per node and that's it. Lots of bandwidth included. But for the most part it's fine, as long no bot starts bombarding your services with useless requests, egress costs tend to scale with revenue in my case, as my product's pricing is based on usage. I also have Cloudflare in front of my AWS stack, it has blocked a few small attacks already, but nothing serious yet.
  - vladletter 6y ago
    Thank you!
k__ 6y ago
This seems like an awful small share of managed services for a one-man show. I mean, K8s? Come on!
dobg24 6y ago
PM for DO Kubernetes here. My views are biased. This is an insightful article. A learning for me was how the author managed to switch multiple cloud providers even while being a one man SAAS. Kubernetes is overwhelming because of 2 things: Overload of terminology, and Distributed systems day 2 operations. Author succeeds so well because he has a starter stack (install, CI pipeline, secure, monitor, scale) maintained as code, and it works every time. For someone starting new, the learning curve is high. Bootstrapping is easy, but day 2 on kubernetes is hard. Benefits outweigh is learning curve imho. Specific to DigitalOcean kubernetes API server issues, we have rolled out some resource provisioning improvements for newly created clusters very recently. Also making ongoing improvements to backend monitoring.
- amzans 6y ago
  Thanks for the response! To clarify, I still a happy customer of DO, and would still use it for some other projects. I have also had a fair share of issues with AWS services in the past (Athena, they took care of it a few months later), and GCP too. And I understand that no product is ever perfect.
Retailer 6y ago
To get an idea off the ground, I use Google App Engine (GAE) with Python, Google's Datastore, Flask, Bootstrap. It works, doesn't cost much and removes a lot of complexity. GAE's offering of free (and auto-renewing) certificates also makes things cheaper.
idlewords 6y ago
A good rule of thumb for success is to have more paying customers than there are layers in your tech stack. Another rule of thumb is to have a setup so basic that articles like this are no fun to read or write. The limiting factor in a one-bro setup is complexity, and this guy maxed out about one paragraph in to his description.
paxys 6y ago
Seeing a lot of criticism on this thread, but honestly as a founder the best stack for your company is the one you know. Whether you use Kubernetes/Terraform or manually rsync a bunch of files to a server under your desk – do whatever works for you.
- er4hn 6y ago
  Adding onto that - your priority is to be able to ship features and have an ease of maintaining them. This setup works for you, so it's great to see it be shared.
revskill 6y ago
To me, the biggest headache of one-man SaaS is that you have to write API by code. I always use API-generation code for my products. The real value i bring to customers is my database, not API.
- davidsawyer 6y ago
  What tools do you use for that?
wenbin 6y ago
Awesome list! I haven't read comments yet, but I bet some people would criticize the tech stack as "too complex" or "not perfect" or "not even mention my favorite tech"... 1. Typically tech stack starts very simple, then evolve into something a bit more complex. It's normal. 2. If this tech stack is the author's most familiar tech stack and it gets jobs done, then it's a perfect tech stack for the author & the business. There's not a tech stack that works well for every developer, every company, every business... 3. Treat this tech stack as a data point. Find other data points on the internet. And you'll come up with your own "perfect tech stack", just for you, for your specific business.
errantmind 6y ago
My One-Man SaaS tech stack: * AWS EC2 * .NET Core Backend (Business logic + Kestrel Web server + Let's Encrypt + JSON Web API) * NOSQL Database: The filesystem * SPA InfernoJS front-end (similar to React) -- The application is performance intensive and must deliver responses sub 100ms at at all times. Each 'request' from the user does a lot of work. I optimized to get all this to run efficiently on a $20 / mo EC2 instance, with no other costs
pirsquare 6y ago
FWIW, Pieter Levels just started using Git last week. https://twitter.com/levelsio/status/1327451757975375874 https://twitter.com/levelsio/status/1327451757975375874 This is one-man who made > $1million a year.
- redis_mlc 6y ago
  He said he started using git because it was helpful for Ghost, and he was planning to hire another developer. He didn't need git otherwise.
davnicwil 6y ago
If I were to attempt a one liner for the key takeaway from this, it'd be "use frameworks as much as possible, use managed services as much as possible". It's a position I couldn't agree with more. It might be one of those mistakes you can only truly learn from by making it yourself, but honestly, while DIY is awesome for learning its only place in a business is at the core of what your business value is. One way I think about it is anything DIY is surface area for either innovation, or mistakes. To mitigate the risk of making mistakes doing things DIY you'd better do it only in areas where innovation could actually benefit your core business value and give you magnified upside. If you innovate outside these areas, I guess it's nice, but you've taken the risk of mistakes for no significant upside. Not to mention a whole load of work invested.
qrohlf 6y ago
A lot of people here are recommending stacks that have worked for them, or cautioning against over-engineered stacks that didn't. All of that is useful, but I'd boil a lot of this down to one simple axiom: If you're a professional engineer and you're starting a tech side project with the goal of shipping - use what you know. I do a lot of work with node, cloudfront, s3, and React for my day job. All of my side projects are built on node, cloudfront, s3, and React. This works well for me because my goal with side projects right now is to be productive, not to learn new tech. An important clarification is that I use the tech that I use in my day-to-day, not what my company uses. Just because I have coworkers who know kubernetes back-to-front doesn't mean I do! Also, there's nothing wrong with doing side projects with totally crazy/new tech stacks as a way to explore and learn new tech. I just think it's good to be really intentional with whether the goals of a project are educational/process-oriented or results-oriented.
ericmcer 6y ago
How did you land on another analytics SaaS product? I think like every dev I have always dreamed of starting my own thing, but never had the time/energy to compete with existing spaces, and couldn't think of any new markets create. It just seems crazy to me when someone is like: 'oh I am gonna make a tool for people to manage their finances' when 1000 exist, but then they build it and achieve some level of success.
ishjoh 6y ago
My one man tech stack. Scala (akka http, slick, Twirl) Postgres AWS EC2 Jquery/Javascript https://www.formgadget.com/ https://www.formgadget.com/ for those curious.
amzans 6y ago
First of all, thank you all! Just the discussion on this post alone, is a goldmine for anyone trying to figure out what worked, and what not for others. This is why I love HN. To clarify a point about my article, I think everyone should do what works for them. Just because my unconventional stack for a solo founder works great for me, doesn't mean it will do the same for you. Your mileage may vary, and it all comes down to tradeoffs. Also, I'm sorry if I haven't been able to reply to each question, this post got way more attention than what I expected. But I'm happy to answer specific questions, feel free to ping me on Twitter: https://twitter.com/anthonynsimon https://twitter.com/anthonynsimon Cheers!
- xyst 6y ago
  Hi Anthony - do you have any concerns with your current employer (Stylights) trying to make an IP claim on your one man saas company?
  - amzans 6y ago
    They have been very supportive, and signed legally binding documents to allow me to work on this. We're also hiring :)
    - jacquesm 6y ago
      That's one employer that I would not mind recommending.
- raphaelj 6y ago
  Hey Anthony, I really like your product. It's crazy fast, might solve one of my issue, is super simple to use, and the UI is gorgeous. I've a few questions though: - how do you compare to other privacy focused analytics tools, such as https://usefathom.com/ https://usefathom.com/ or https://simpleanalytics.com/ https://simpleanalytics.com/? - it seems like you just launched your SaaS a couple of weeks ago. Why didn't you launch it earlier by removing some not strictly necessary/MVP features, such as the security login emails, the ability to manage multiple websites, a less scalable but simpler architecture ... ? - how much time have you spent developing the product? I've been working on my personal SaaS for more than one year, planning to launch it in the next few weeks. I'm still working at my 4/5 full time job, and I really wonder how you managed to deliver this beautiful product while still working fulltime. That would be a wonderful opportunity for blog article BTW. Great work!
ttymck 6y ago
Would love to hear more about how you deploy, manage and utilize Celery. I think there is a lack of quality case studies on celery-in-production. Thanks for sharing!
rebataur 6y ago
For early stage startups we just released fsKube: Your full-stack kubernetes enabler fsKube provides as Desktop Web UI to setup entire AWS EKS Kubernetes cluster, with all the components and Django framework template with a full DevSecOps enabled, along with monitoring and operations. The whole thing within 45 minutes. Support for Spot Instances, Graviton Processor and AMD AMI coming soon, will reduce already cheap EKS prices further. Watch the full demo here https://youtu.be/Nt5yowdwm5Q https://youtu.be/Nt5yowdwm5Q Product https://rebataur.com/tools/fskube https://rebataur.com/tools/fskube
deleted 6y ago
[deleted]
XCSme 6y ago
This is a lot more complex than I expected. I personally just use one ore more VPSs on DigitalOcean, which scale pretty well at first and if you get enough traction to need "infinite" horizontal scaling, it might be better to only focus on that once you have the money to hire some sys architect/admins.
johnestar 6y ago
wow, pretty amazing post
davidbanham 6y ago
I run three different SaaS products by myself, spend a couple of days per week consulting and lead a pretty full life with young kids, volunteer firefighting, hobbies, etc. Each of my products probably equates to around a 1/4-Man SaaS. They're all server-rendered HTML with a little ajax sprinkled around the place where required for interactivity. I use Materialize CSS to give me a leg-up on the design side but the next thing I release will be on Tailwind UI. They're all written in Go using a simple MVC-ish pattern. I write a lot of integration tests and a few unit tests. I use Google's hosted PostgreSQL database. It's not cheap but it's not expensive either and it's been rock solid. The frontends are all on Cloud Run as of a few months ago which has been wonderful. Super reliable and fuss-free. Takes care of all the application logging, etc. Task queue stuff is handled by a library on top of Postgres. It won't scale to a billion jobs per second or anything but it handles load just fine. If I ever start pushing it's boundaries it's all pluggable so I can switch it back to SQS or PubSub or whatever else. The task workers run on a single-node k8s cluster hosted on GKE. A lot of people grump about Kubernetes being "overkill" but it doesn't have to be complicated. A single YAML manifest defines your service and your environment variables, you tell GKE to make it happen, you go play in the sunshine. It takes care of restarts, logging, full disks, etc etc etc all for you. I use Amazon SES for emails. I had some real problems with deliverability until I ponied up for a dedicated IP address and now it's fine. I use Freshdesk for ticketing. I don't love it at all but I don't yet hate it enough to replace it with something else.
ianwalter 6y ago
This is probably due to my own ignorance but I haaate helm. I'd be interested to read more about how you use Flux.
b20000 6y ago
Wow, there is a like a million tools in use here. Before I clicked the link I was expecting the tool set to be extremely minimal and focused, e.g. HTML+CSS+javascript/node.js. I currently have a bunch of projects using PHP+javascript+HTML+CSS and I am seriously considering dropping PHP and focusing more on javascript, and thus using node.js instead of PHP, so I no longer have to keep up to date with PHP. Anyway, great you can manage it all and that it's working for you.
- nawgz 6y ago
  All JS is the place to be. TypeScript is an amazing dev experience, NodeJS is decently performant, and then it's all portable as hell thanks to the web.
  - b20000 6y ago
    do you know how nodeJS compares to PHP in terms of performance?
    - nawgz 6y ago
      My feeling is that they are comparable in a proverbial "straight line" computational sense, but nodeJS' non-blocking event loop / IO makes it superior for handling a webserver's request / event model under higher concurrent user counts
mrfusion 6y ago
I think if I did a saas I’d do django on heroku to get started. I want the minimal devops/sys admin work possible and have all my effort go towards adding features. If I’m successful I could cut costs later and switch to something cheaper. Is that a good strategy?
deleted 6y ago
[deleted]
tnel77 6y ago
How do you begin to learn all of those tools? The coding itself doesn’t scare me, but the configuration of all those tools is something that makes me feel like I have barely learned anything since college.
- Xavdidtheshadow 6y ago
  The easiest way to learn this (or anything, really), is to start small. You don't need to invent Facebook on day 1 - start with something small (probably the backend, that's the simplest) and add new tools when you find need for them. In the linked post, they mention both Django for the backend and Redis as a cache. Django has caching built-in though, so until you need more complex caching logic, you probably don't need to reach for Redis.
justinyan 6y ago
Taking a different line of questioning: Does anyone have any insights or resources on the non-tech stack a one-man SaaS should use? At various points, I've looked into opening a single-owner LLC to hold some small side projects I want to put on the internet for fun, but the number of decisions and amount of overhead has always seemed pretty daunting.
sawirricardo 6y ago
I use plain PHP for backend and HTML for the front-end (plus javascript and libraries from the awesome open source communities). It's just fast enough to ship. And personally, I find it very easy to scale if needed. Don't worry, debugging is not that hard as long as you don't complicate your code.
jitendrac 6y ago
Thanks for sharing, I would like to know more about how you define your deployment infrastructure and environment with code(Docker,terraform,kubernetes etc) including migration checklist. I think it deserves its own blog post and youtube video
jitendrac 6y ago
Thanks, can you share your aws/linode hosting cost per month and what kind of traffic load it get?
shean_massey 6y ago
Another one man-team here, I find it fascinating how our stacks have at least a 90% overlap. Also funny that we both build analytics tools :) For your front to back integration: I suggest you look into django-graphene and reacts apollo-client. That small addition to my stack has, at least, doubled if not tripled my churn speed. Throw in something like Django-channels and you get a modern full async websocket capable reactive framework :)

475 points by amzans 6y ago

lnsp 6y ago

This seems like a pretty big stack for a single person to administrate - how much time do you spend on doing operations vs development?

amzans 6y ago
Right now the operational effort is pretty minimal to be honest. I spend most of my time developing new features and talking my customers. I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended. Most of the stack consists of "platform" tools, such as the ingress-nginx, external-dns, or cert-manager. So it's stuff I take with me for every project. It's like a personal Heroku I've been building, but way cheaper and fully customizable. I've been iterating on this stack over the years with various other projects, and also learned a lot from running Kubernetes in production at my full-time job, so it's not something I'd advise for someone who just wants to deploy their MVP for the first time.
- vbsteven 6y ago
  Replace Python/Django with Java/Kotlin/SpringBoot and you pretty much have my preferred project stack, which also organically grew due to being exposed to these platform tools in my day job. Kubernetes/Terraform and friends are really useful as a solo-dev if, and only if you have the required experience with them.
- Wheaties466 6y ago
  any chance you could expand on this? "I know it seems like a lot of tools, but most of them are set up once and forget. Except for the occasional round of dependency updates. But even for that I have automated dependency/container scanning to detect vulnerabilities, and get notified if updating an image is recommended."
  - amzans 6y ago
    Regarding docker images, I use the image scanning feature of ECR: https://aws.amazon.com/blogs/containers/amazon-ecr-native-container-image-scanning/ https://aws.amazon.com/blogs/containers/amazon-ecr-native-co... The docs make it look really complicated, but it comes down to enabling the service on the Terraform config. Also for app dependencies, I use bots to open PRs on my repo whenever an important security fix is published for one of my dependencies.
- jrochkind1 6y ago
  What would you advise for someone who doesn't have the pre-existing k8 expertise etc? The ops environment still looks overwhelming to me, if there's a way to do it sustainably without a really heavy-weight ops infrastructure, I haven't figured it out. Like, something that to me requires like a full-time job just to do ops, although maybe not if you've spent some years learning the ops tools, but then same same.
  - redisman 6y ago
    I don't think diving into kubernetes makes any sense for a 1 person shop if you don't already know it. People love to evangelize about k8s more than your average tech but it's just one (IMHO overkill) way to do things. A better bet I think is to leverage tools from cloud providers. They specifically offer many different easy to use scaling platforms for a premium for small/not experienced teams. Heroku has been mentioned a bunch, something like Elastic Beanstalk on AWS is super easy for the first year or two of a company. Or just go for a single machine somewhere and worry about the 5% chance you need more than that when that happens.
    - amzans 6y ago
      Yes, this is what I would also recommend. You can get really far with the managed services from your cloud provider. If you're already familiar with Docker containers, just that already gives you plenty of options. I think every platform now provides a way to just run containers behind a load balancer with a few simple steps. Yes, maybe it's a form of vendor lock-in, but if your worry is acquiring customers, and growing a company, Kubernetes is probably not helping you in this case.
romanovcode 6y ago
Exactly, I was expecting something like React, Next.js, Firebase, Mailchimp. This list looks huge to manage as a solo developer.

aadithpm 6y ago

As a fairly new dev, this is really great information for me. Thanks for posting this. If you don't mind me asking, roughly how much do you spend (time) on this every week? How much of that is split between development, operations and product or business development?

amzans 6y ago
Glad you found it useful! Since I have a full-time job too, my time on this project is pretty limited, usually no more than 2 hours per day. That's why I tried to automate and save time as much as I could using Kubernetes operators, well supported open source projects, and most importantly, tools I already feel comfortable with. I don't have hard rules in terms of how I distribute my time, but recently it may have looked like this: - 60% of the time I'm trying to understand the problem I'm solving (talking to customers, researching, evaluating features). - 20% working on features, and issues. - 20% promoting: writing blog posts, documentation, reaching out on Twitter, HN, Indie Hackers. Helping out customers integrate their website / understand how something works. Of course, there's tons of other smaller things here and there, but those are the big "buckets" of my time. Once I know what to work on next, I tend to prioritize as follows: 1) At the start of each week I pick 1-3 topics to work on next (for example writing a new blog post, working on a new feature, or even just writing documentation which I am going to next). 2) Each day when I'm working on my project I pick the most impactful thing I could work on, and start with that. I allow myself to explore a topic in depth, sometimes without a clear goal or deadline. After all it's supposed to be fun if I want to stick to it for the long term. 3) I try to respond to customer emails as soon as I can, and understand why they're giving my product a try. That's my gauge for what to work on the following week.
- aadithpm 6y ago
  Thanks for taking the time to share this. I've been mildly interested in a side hustle with the primary goal of picking up new technologies but currently lack the motivation to, after a long job search. It's interesting to see how you split your time and how much thought goes into all this. A followup question, if you could; > and most importantly, tools I already feel comfortable with What do you do in situations where X tool would be 'better' than Y tool, but you're comfortable with Y tool? Do you do a comparison of the time/effort it takes to learn AND use X tool vs. Y?

FreekNortier 6y ago

But does Python scale for back end applications?

derwiki 6y ago
Ask any number of the very successful companies who use Python
underdeserver 6y ago
Yes, it does, as long as performance-bottlenecked code is not in Python (and it usually isn't). In the real world, you may have to extract some hot regions to C++ or Rust or Java, but 99% of your code will scale infinitely.
- Ozzie_osman 6y ago
  Or, alternatively, if most of your heavy-lifting is already done in the database layer there's less work for Python to do.
- amzans 6y ago
  My team migrated a service handling >1.6k req/s at peak time, from Scala (Finatra), to Python (Django). Same number of servers (3x c5.large), just higher CPU utilization (from ~15% to 70%). Scala was great, but unfortunately it made it difficult to onboard new team members into the project, so development suffered. Also the rest of our stack is mostly Python, so we couldn't use a lot of the common tooling, and libraries we had built for other projects. We migrated it within a month, and it's been running for almost a year without issues. At some point the service even recorded 3k+ req/s at ~200ms 99p latency. Yeah, maybe not Google scale, but more than enough for 99% of the businesses out there. This service handles about 2.5 billion requests per month from one AWS region. We're a small team, and that's only one of the services we support. Which is great because we don't need to spend all of our time optimizing it.
- chrismorgan 6y ago
  Notwithstanding this (that Python will scale), Python will force you to scale horizontally a lot earlier than something like Rust. In mid-2013, NewsBlur was using 48 servers to run its Python/Django stack. The workload was reasonably precisely declared (and I could grudgingly see why it used so many servers for its stack), so I was able to run the numbers and confidently concluded that something reasonably efficient (which for me would now mean Rust) could have handled the same workload on one equivalent server, though not with a great deal of headroom, and further vertical scaling might have started running into I/O limitations. But for a one-man thing, I know I would prefer to use a single server as long as convenient, and a 98% reduction in hosting bill is very significant (though that’s a moderately extreme case, and I imagine smaller parts of the code could have been rewritten in a language like Rust to get a meaningful fraction of that resource usage reduction).

brudgers 6y ago

How long did it take you to learn enough about all those technologies? How much of it was on the job?

amzans 6y ago
Most of my learning was on the job, and in building some open-source projects that I have released over the years, for example: - https://github.com/anthonynsimon/bild https://github.com/anthonynsimon/bild - https://github.com/traduora/traduora https://github.com/traduora/traduora I still have a lot to learn, but IMO nothing beats struggling with something for a long time, and pushing along until you're no longer terrible at it. I feel that most of what I know I learned by starting projects on topics I initially new nothing about, and sticking to it. Regarding on the job learning, I have been working with Python/Scala for my full-time job over the past 3.5 years, and that helped too. Specially in terms of running multi-regional services, and the challenges that come with that. We run several applications on Kubernetes using AWS (combined >2k req/s at peak time), and that was a big challenge for me from which I learned a lot. Specially when you're on-call, and one faulty node brings down the entire cluster, that fails over to another region and repeat :)

robertlagrant 6y ago

Very, very similar to the tech stack we have in my engineering teams (other than we use Flask and SQLAlchemy instead of Django). Really like it. I've not heard of ClickHouse before, but that looks interesting. (If I had a requirement around time series, I was thinking of checking out Timescale - https://www.timescale.com https://www.timescale.com.)

Ozzie_osman 6y ago

At my startup we use a pretty similar tech stack, except we are on Heroku for infrastructure which makes our life a lot easier, and gives us things like review apps quite easily. One piece we've struggled with is just mypy doesn't seem to play too nicely with Django. It definitely feels like a world of difference between the type support we get in our React app with Typescript and mypy with Django. Would be curious what OP's experience has been with that.

real_ben_michel 6y ago

Super similar to what I use (http://www.casaspanish.co.uk http://www.casaspanish.co.uk). Django has just so much stability, it was an obvious decision for me to go with it. And that's speaking as someone who has mostly worked with NodeJS/React for the past 5 years. I love the pythonic principle of "There should be one obvious way to do it". This helps me cut down on decision making which is something quite annoying to deal with as sole-tech-founder. Now I get to focus on the business, and technology is just a matter of execution.

eric_b 6y ago

It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should follow the stack in this article. There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feeding it is non-trivial (see: ZooKeeper dependency and all the problems you get once you move to a distributed database). Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know. The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles.

triangleman 6y ago
Indeed OP uses this sort of stack in his full time job and has learned about all the kinks over the years, while getting paid to do it! I'm working on a side project and it's literally a bunch of .py files in a folder. Libraries include fastapi and sqlite3. I cannot think of a reason to use container orchestration over a "single beefy machine" in almost any use case.
- mixmastamyk 6y ago
  Side project vs. business with paying customers and bus factor is a different equation.
- sgarland 6y ago
  Not having to recreate your Python env, not having to worry about dependencies (once they're pinned), the ability to run the app on a hosted service like Fargate instead of managing the server...
amzans 6y ago
I agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. If I wanted to start a new project, I can leverage the same stack and be up and running in minutes. Which means I can take advantage of my cumulative efforts for any future project. It's definitely not for everyone as you said, but it might be a good solution for many :)

officialchicken 6y ago

I kinda wish the dogfood part was mentioned earlier... but sure glad I caught it at the end. An article on your analytics bootstrapping would be neat - how (did) you do analytics early?

mvanga 6y ago

Honestly, having gone down this path a year back, just use Heroku for your backend. Maybe Netlify if you want to separate your frontend and backend. The amount of complexity and interdependencies these "here's my stack" posts describe are always a huge cognitive overhead for running a one-person SaaS. Heroku costs more, but there's a reason for it. If you're even remotely making money from your product, and are alone in running the show, it's a no brainer to drop a couple hundred dollars a month to eliminate 99% of your ops headaches: the documentation, the add-on's, the fantastic UI, decent reliability, and ease of operations are totally worth it. Literally the worst thing one can say about Heroku is the cost, and possibly, the inability to build certain complex architectures (which most single-person SaaS services aren't).

jrochkind1 6y ago
I've been spending some time looking at moving to heroku, but having trouble figuring out how to use it for a real production for deploy for "only" a couple hundred dollars a month. Is that what you're doing? "Standard" dynos and just a few of them are working for you, I assume, for that budget? In my tests, with a Rails app, "standard" dynos are looking surprisingly slow, possibly unacceptably so. Very curious to hear about other people's heroku formations if anyone wants to share. What platform you're on (Rails or something else), and what your response times look like, would also be interesting.
- dyeje 6y ago
  Checkout Hatchbox.io, just started using it myself. You basically pay a flat monthly rate for their Heroku-esque management service and then pay for the servers on your provider of choice separately (e.g. DO, AWS, etc).
  - lambda_obrien 6y ago
    I've been looking for something between Heroku (too expensive, too many features) and Dokkku (too much hassle, I have to maintain my own security and patches) and this looks like exactly the thing I wanted, except it looks like it's only for Ruby? I use a combination of Python, Elixir, and Haskell, so I'd love it if they did support other langs.

blitblitblit 6y ago

Presuming you are using Github and were using Angular, I think "Google Chrome" is missing from the "Other" stack - since I have had problems even in Firefox try to get latest Google WebComponent shinies to work.

thrower123 6y ago

I expected a much more boring stack, to be honest.

Axsuul 6y ago

Thanks for sharing! How are you liking Loki so far? I’m looking to migrate off Google Cloud‘s logging offering to Loki but was worried about its maturity.

attollos 6y ago

There is a typo on your landing page: "The short answer is: we doesn't use tracking cookies"

atlgator 6y ago

I expected a lot less for "one man." Kudos to you OP.

nojito 6y ago

The secret behind this stack is not its simplicity, but rather it's simply the stack they know the best.

anonfunction 6y ago

Have you considered Amazon’s SES for transactional email?

ticmasta 6y ago
Just a single data point warning: I've had nothing but bad experiences with blacklisted, shared IPs from SES. Everything gets flagged as spam.

deforciant 6y ago

I use similar stack too :) - GKE kubernetes - Managed Postgres (CloudSQL) - GCS buckets for file storage - Cloudflare for DNS - Countour for ingress - Keel for automating deployment updates - Mailgun - Sentry (errors) - Node-RED various little automations such as healthchecks Planning to introduce Elasticsearch too, so far I have been testing the operator and it seems to be pretty good quality. From maintenance perspective GKE is great, as long as the bills are paid, no need to login there pretty much ever. As a one man company this means a lot, I try to never spend any time on ops.

fxtentacle 6y ago

Here's my self-serving advice for every one-man SaaS: Use Heroku. It's super easy to get started. And when you reach $2000+ in monthly bills, hire me to move things over onto dedicated or EC2 so that you'll get 10x that performance for the same price. As for the actual language, I think PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. All those great architectural ideas don't matter much until you have your first $5k monthly in reliable revenue. And by then, you'll have a completely different perspective than what you think you need now.

taffer 6y ago
> PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. With JS, do you mean React or jquery or literally JavaScripting the DOM?
- fxtentacle 6y ago
  I meant some sort of JavaScript framework. I'd say that part mostly depends on personal preference. I'm quite happy with Angular, but I've also had lots of smaller one-off pages where I used jQuery.
tensor 6y ago
I'd actually suggest PostgreSQL + Hasura + React with Ant Design or Material UI
- armatav 6y ago
  This man knows the way. I use this stack and I'm pretty sure I could pump out any SaaS business in about two weeks with it. Host on Heroku, use whatever analytics system you want.
- fxtentacle 6y ago
  For many newcomers starting out, the Rails CRUD generators are good enough to generate their entire admin area. And Rails comes with sane security defaults. I agree that GraphQL + React will be pretty and work well. But for one-man start-ups, the focus is usually on "looks good enough and kinda works". So I believe I'd go with Bootstrap & Glyphicons, just to get results faster.

mwcampbell 6y ago

Since you're using Python on the back end, which WSGI or ASGI server do you use?

ThePhysicist 6y ago

Seems it's another cookie-less, privacy-friendly Google Analytics alternative. This time from Germany! It's pretty cool that there's so much going on in this space, but is it really wise going into the market with seemingly the exact same features that Plausible, Simple Analytics, Fathom, etc. offer? Even Cloudflare recently entered the privacy-friendly analytics market with a free product, so it seems that market is getting really crowded. Then again, every (commercial) website probably needs such a solution, so maybe the market is big enough. I wonder though if these cookie-less solutions can give people the insights they need? You can do only very simple overall statistics and funnel analyses with this approach. Maybe that's enough for most websites though?

amzans 6y ago
Thanks for the feedback. Yes, I understand I'm entering a crowded market, but Panelbear is still in the early stages, and I'm trying to understand what problems my customers have that I could solve / how much value can I bring to them. A crowded market also means more options for you as a customer. Specially when it comes to privacy-friendly tools, not only analytics, I'd argue that there's not enough options yet. I initially built it for myself, as I was not fully satisfied with the existing solutions. And I do intend to offer more features than what you currently see, but unfortunately my time is limited and it's going to take a while to bring Panelbear to the feature-level I'd like it to be :)

zomgwat 6y ago

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team. The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. I began doing Ruby and Ruby on Rails (RoR) development in 2006. Ruby had been around for awhile but the growing popularity of RoR was driving a lot of changes in the ecosystem in those years. It was a fun time but I was working for a large company that allowed me the time to keep up with everything. I see today’s frontend and container ecosystems in the light of that experience. I’m now more content to wait it out and let the dust settle as much as I enjoy learning new technology.

ticmasta 6y ago
You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.
- zomgwat 6y ago
  Thanks! Best done as an employee is spot on.
  - herodoturtle 6y ago
    If I may chime in here, I would humbly suggest that it is best done by whoever enjoys it. Sometimes that might be your employee, and sometimes that might be you. I guess it depends on where your passion lies, and what your objectives are? I imagine that achieving one's financial ambitions in a relaxed and enjoyable work environment is great - irrespective of which part of the stack one enjoys tinkering with the most.

avan1 6y ago

Glad to see that stack works for author, but honestly one man show's shouldn't be multi lingual stacks at all IMO. for me php (laravel for back and front with blade templates) or js (express and vuejs for frontend) and docker-compose for deploying and developing stuff is fast and enough stack.

ezekg 6y ago

Fellow solo founder here. I feel like this is pretty overkill, most notably k8s (and terraform.) The last company I worked at used k8s and it felt overkill even for them. But if it works for you, great, but I definitely think that'd require spending too much of my time on devops. Maybe I should do a "counter" blog post on using Rails, Heroku, Redis and Postgres. :)

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 ago
OOC 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 ago
  I'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.

smu 6y ago

Seems like there are a couple of tech stack posts on HN lately and I certainly enjoy reading them. But as a techie, the magic to me no longer lies in the product building, but in the ‘finding the first 10-100’ customers part. Have there been any posts on that lately?

Wirerack 6y ago
I'd definitely appreciate seeing something like that too. After a couple of "build it first" failures I've come to see the wisdom in finding your customers and validating your idea first. I've read several of these SaaS walkthroughs and it invariably seems to follow this pattern: 1. Author has a blog with a large following on some topic. 2. Finds niche in that topic. 3. Makes a product and pushes it via their blog. 4. "Incredibly" their product gets tons of customers.
- amzans 6y ago
  Going from 0 paying customers to 1 is really difficult. Specially if you're asking for a recurring subscription. Getting noticed is one of the hardest parts. Just having a great product is no longer enough. For every Basecamp, there are probably tens, or even hundreds of similar competitors. Can I name a few? Maybe. What about the top 10? Probably not, and that's exactly the problem.

michaelbuckbee 6y ago

Important thing to keep in mind with this article is that this is for OPs data analytics SAAS where he's ingesting a mass amount of data, has different uptime requirements, etc than many other SAAS applications.

naicuoctavian 6y ago

That seems overkill. @levelsio ran his $1M business on "FTP" https://twitter.com/levelsio/status/1327451757975375874 https://twitter.com/levelsio/status/1327451757975375874

deleted 6y ago

[deleted]

vladletter 6y ago

Thank you for the sharing! About pricing: - Do you have any tool for cloud pricing tuning/estimations ? - Are you using specific tool to track all your expenses in general ?

amzans 6y ago
I have used https://calculator.aws/ https://calculator.aws/ in the past, but to be honest it's difficult to account for the egress costs/networking fees using their calculator. Simple things like networking between Availability Zones/Regions can really creep up in your monthly bills if you don't watch out. I do track my expenses on a sheet manually, using a ballpark figure. At the end of the month I compare it with my AWS bill. If something seems off, I investigate it further. But I don't try to predict exact figures, more like expected ranges. I do miss the fixed-cost nature of DigitalOcean/Linode. I didn't have to worry about sudden charges, you pay $20/mo per node and that's it. Lots of bandwidth included. But for the most part it's fine, as long no bot starts bombarding your services with useless requests, egress costs tend to scale with revenue in my case, as my product's pricing is based on usage. I also have Cloudflare in front of my AWS stack, it has blocked a few small attacks already, but nothing serious yet.
- vladletter 6y ago
  Thank you!

k__ 6y ago

This seems like an awful small share of managed services for a one-man show. I mean, K8s? Come on!

dobg24 6y ago

PM for DO Kubernetes here. My views are biased. This is an insightful article. A learning for me was how the author managed to switch multiple cloud providers even while being a one man SAAS. Kubernetes is overwhelming because of 2 things: Overload of terminology, and Distributed systems day 2 operations. Author succeeds so well because he has a starter stack (install, CI pipeline, secure, monitor, scale) maintained as code, and it works every time. For someone starting new, the learning curve is high. Bootstrapping is easy, but day 2 on kubernetes is hard. Benefits outweigh is learning curve imho. Specific to DigitalOcean kubernetes API server issues, we have rolled out some resource provisioning improvements for newly created clusters very recently. Also making ongoing improvements to backend monitoring.

amzans 6y ago
Thanks for the response! To clarify, I still a happy customer of DO, and would still use it for some other projects. I have also had a fair share of issues with AWS services in the past (Athena, they took care of it a few months later), and GCP too. And I understand that no product is ever perfect.

Retailer 6y ago

To get an idea off the ground, I use Google App Engine (GAE) with Python, Google's Datastore, Flask, Bootstrap. It works, doesn't cost much and removes a lot of complexity. GAE's offering of free (and auto-renewing) certificates also makes things cheaper.

idlewords 6y ago

A good rule of thumb for success is to have more paying customers than there are layers in your tech stack. Another rule of thumb is to have a setup so basic that articles like this are no fun to read or write. The limiting factor in a one-bro setup is complexity, and this guy maxed out about one paragraph in to his description.

paxys 6y ago

Seeing a lot of criticism on this thread, but honestly as a founder the best stack for your company is the one you know. Whether you use Kubernetes/Terraform or manually rsync a bunch of files to a server under your desk – do whatever works for you.

er4hn 6y ago
Adding onto that - your priority is to be able to ship features and have an ease of maintaining them. This setup works for you, so it's great to see it be shared.

revskill 6y ago

To me, the biggest headache of one-man SaaS is that you have to write API by code. I always use API-generation code for my products. The real value i bring to customers is my database, not API.

davidsawyer 6y ago
What tools do you use for that?

wenbin 6y ago

Awesome list! I haven't read comments yet, but I bet some people would criticize the tech stack as "too complex" or "not perfect" or "not even mention my favorite tech"... 1. Typically tech stack starts very simple, then evolve into something a bit more complex. It's normal. 2. If this tech stack is the author's most familiar tech stack and it gets jobs done, then it's a perfect tech stack for the author & the business. There's not a tech stack that works well for every developer, every company, every business... 3. Treat this tech stack as a data point. Find other data points on the internet. And you'll come up with your own "perfect tech stack", just for you, for your specific business.

errantmind 6y ago

My One-Man SaaS tech stack: * AWS EC2 * .NET Core Backend (Business logic + Kestrel Web server + Let's Encrypt + JSON Web API) * NOSQL Database: The filesystem * SPA InfernoJS front-end (similar to React) -- The application is performance intensive and must deliver responses sub 100ms at at all times. Each 'request' from the user does a lot of work. I optimized to get all this to run efficiently on a $20 / mo EC2 instance, with no other costs

pirsquare 6y ago

FWIW, Pieter Levels just started using Git last week. https://twitter.com/levelsio/status/1327451757975375874 https://twitter.com/levelsio/status/1327451757975375874 This is one-man who made > $1million a year.

redis_mlc 6y ago
He said he started using git because it was helpful for Ghost, and he was planning to hire another developer. He didn't need git otherwise.

davnicwil 6y ago

If I were to attempt a one liner for the key takeaway from this, it'd be "use frameworks as much as possible, use managed services as much as possible". It's a position I couldn't agree with more. It might be one of those mistakes you can only truly learn from by making it yourself, but honestly, while DIY is awesome for learning its only place in a business is at the core of what your business value is. One way I think about it is anything DIY is surface area for either innovation, or mistakes. To mitigate the risk of making mistakes doing things DIY you'd better do it only in areas where innovation could actually benefit your core business value and give you magnified upside. If you innovate outside these areas, I guess it's nice, but you've taken the risk of mistakes for no significant upside. Not to mention a whole load of work invested.

qrohlf 6y ago

A lot of people here are recommending stacks that have worked for them, or cautioning against over-engineered stacks that didn't. All of that is useful, but I'd boil a lot of this down to one simple axiom: If you're a professional engineer and you're starting a tech side project with the goal of shipping - use what you know. I do a lot of work with node, cloudfront, s3, and React for my day job. All of my side projects are built on node, cloudfront, s3, and React. This works well for me because my goal with side projects right now is to be productive, not to learn new tech. An important clarification is that I use the tech that I use in my day-to-day, not what my company uses. Just because I have coworkers who know kubernetes back-to-front doesn't mean I do! Also, there's nothing wrong with doing side projects with totally crazy/new tech stacks as a way to explore and learn new tech. I just think it's good to be really intentional with whether the goals of a project are educational/process-oriented or results-oriented.

ericmcer 6y ago

How did you land on another analytics SaaS product? I think like every dev I have always dreamed of starting my own thing, but never had the time/energy to compete with existing spaces, and couldn't think of any new markets create. It just seems crazy to me when someone is like: 'oh I am gonna make a tool for people to manage their finances' when 1000 exist, but then they build it and achieve some level of success.

ishjoh 6y ago

My one man tech stack. Scala (akka http, slick, Twirl) Postgres AWS EC2 Jquery/Javascript https://www.formgadget.com/ https://www.formgadget.com/ for those curious.

amzans 6y ago

First of all, thank you all! Just the discussion on this post alone, is a goldmine for anyone trying to figure out what worked, and what not for others. This is why I love HN. To clarify a point about my article, I think everyone should do what works for them. Just because my unconventional stack for a solo founder works great for me, doesn't mean it will do the same for you. Your mileage may vary, and it all comes down to tradeoffs. Also, I'm sorry if I haven't been able to reply to each question, this post got way more attention than what I expected. But I'm happy to answer specific questions, feel free to ping me on Twitter: https://twitter.com/anthonynsimon https://twitter.com/anthonynsimon Cheers!

xyst 6y ago
Hi Anthony - do you have any concerns with your current employer (Stylights) trying to make an IP claim on your one man saas company?
- amzans 6y ago
  They have been very supportive, and signed legally binding documents to allow me to work on this. We're also hiring :)
  - jacquesm 6y ago
    That's one employer that I would not mind recommending.
raphaelj 6y ago
Hey Anthony, I really like your product. It's crazy fast, might solve one of my issue, is super simple to use, and the UI is gorgeous. I've a few questions though: - how do you compare to other privacy focused analytics tools, such as https://usefathom.com/ https://usefathom.com/ or https://simpleanalytics.com/ https://simpleanalytics.com/? - it seems like you just launched your SaaS a couple of weeks ago. Why didn't you launch it earlier by removing some not strictly necessary/MVP features, such as the security login emails, the ability to manage multiple websites, a less scalable but simpler architecture ... ? - how much time have you spent developing the product? I've been working on my personal SaaS for more than one year, planning to launch it in the next few weeks. I'm still working at my 4/5 full time job, and I really wonder how you managed to deliver this beautiful product while still working fulltime. That would be a wonderful opportunity for blog article BTW. Great work!

ttymck 6y ago

Would love to hear more about how you deploy, manage and utilize Celery. I think there is a lack of quality case studies on celery-in-production. Thanks for sharing!

rebataur 6y ago

For early stage startups we just released fsKube: Your full-stack kubernetes enabler fsKube provides as Desktop Web UI to setup entire AWS EKS Kubernetes cluster, with all the components and Django framework template with a full DevSecOps enabled, along with monitoring and operations. The whole thing within 45 minutes. Support for Spot Instances, Graviton Processor and AMD AMI coming soon, will reduce already cheap EKS prices further. Watch the full demo here https://youtu.be/Nt5yowdwm5Q https://youtu.be/Nt5yowdwm5Q Product https://rebataur.com/tools/fskube https://rebataur.com/tools/fskube

deleted 6y ago

[deleted]

XCSme 6y ago

This is a lot more complex than I expected. I personally just use one ore more VPSs on DigitalOcean, which scale pretty well at first and if you get enough traction to need "infinite" horizontal scaling, it might be better to only focus on that once you have the money to hire some sys architect/admins.

johnestar 6y ago

wow, pretty amazing post

davidbanham 6y ago

I run three different SaaS products by myself, spend a couple of days per week consulting and lead a pretty full life with young kids, volunteer firefighting, hobbies, etc. Each of my products probably equates to around a 1/4-Man SaaS. They're all server-rendered HTML with a little ajax sprinkled around the place where required for interactivity. I use Materialize CSS to give me a leg-up on the design side but the next thing I release will be on Tailwind UI. They're all written in Go using a simple MVC-ish pattern. I write a lot of integration tests and a few unit tests. I use Google's hosted PostgreSQL database. It's not cheap but it's not expensive either and it's been rock solid. The frontends are all on Cloud Run as of a few months ago which has been wonderful. Super reliable and fuss-free. Takes care of all the application logging, etc. Task queue stuff is handled by a library on top of Postgres. It won't scale to a billion jobs per second or anything but it handles load just fine. If I ever start pushing it's boundaries it's all pluggable so I can switch it back to SQS or PubSub or whatever else. The task workers run on a single-node k8s cluster hosted on GKE. A lot of people grump about Kubernetes being "overkill" but it doesn't have to be complicated. A single YAML manifest defines your service and your environment variables, you tell GKE to make it happen, you go play in the sunshine. It takes care of restarts, logging, full disks, etc etc etc all for you. I use Amazon SES for emails. I had some real problems with deliverability until I ponied up for a dedicated IP address and now it's fine. I use Freshdesk for ticketing. I don't love it at all but I don't yet hate it enough to replace it with something else.

ianwalter 6y ago

This is probably due to my own ignorance but I haaate helm. I'd be interested to read more about how you use Flux.

b20000 6y ago

Wow, there is a like a million tools in use here. Before I clicked the link I was expecting the tool set to be extremely minimal and focused, e.g. HTML+CSS+javascript/node.js. I currently have a bunch of projects using PHP+javascript+HTML+CSS and I am seriously considering dropping PHP and focusing more on javascript, and thus using node.js instead of PHP, so I no longer have to keep up to date with PHP. Anyway, great you can manage it all and that it's working for you.

nawgz 6y ago
All JS is the place to be. TypeScript is an amazing dev experience, NodeJS is decently performant, and then it's all portable as hell thanks to the web.
- b20000 6y ago
  do you know how nodeJS compares to PHP in terms of performance?
  - nawgz 6y ago
    My feeling is that they are comparable in a proverbial "straight line" computational sense, but nodeJS' non-blocking event loop / IO makes it superior for handling a webserver's request / event model under higher concurrent user counts

mrfusion 6y ago

I think if I did a saas I’d do django on heroku to get started. I want the minimal devops/sys admin work possible and have all my effort go towards adding features. If I’m successful I could cut costs later and switch to something cheaper. Is that a good strategy?

deleted 6y ago

[deleted]

tnel77 6y ago

How do you begin to learn all of those tools? The coding itself doesn’t scare me, but the configuration of all those tools is something that makes me feel like I have barely learned anything since college.

Xavdidtheshadow 6y ago
The easiest way to learn this (or anything, really), is to start small. You don't need to invent Facebook on day 1 - start with something small (probably the backend, that's the simplest) and add new tools when you find need for them. In the linked post, they mention both Django for the backend and Redis as a cache. Django has caching built-in though, so until you need more complex caching logic, you probably don't need to reach for Redis.

justinyan 6y ago

Taking a different line of questioning: Does anyone have any insights or resources on the non-tech stack a one-man SaaS should use? At various points, I've looked into opening a single-owner LLC to hold some small side projects I want to put on the internet for fun, but the number of decisions and amount of overhead has always seemed pretty daunting.

sawirricardo 6y ago

I use plain PHP for backend and HTML for the front-end (plus javascript and libraries from the awesome open source communities). It's just fast enough to ship. And personally, I find it very easy to scale if needed. Don't worry, debugging is not that hard as long as you don't complicate your code.

jitendrac 6y ago

Thanks for sharing, I would like to know more about how you define your deployment infrastructure and environment with code(Docker,terraform,kubernetes etc) including migration checklist. I think it deserves its own blog post and youtube video

jitendrac 6y ago

Thanks, can you share your aws/linode hosting cost per month and what kind of traffic load it get?

shean_massey 6y ago

Another one man-team here, I find it fascinating how our stacks have at least a 90% overlap. Also funny that we both build analytics tools :) For your front to back integration: I suggest you look into django-graphene and reacts apollo-client. That small addition to my stack has, at least, doubled if not tripled my churn speed. Throw in something like Django-channels and you get a modern full async websocket capable reactive framework :)