Ask HN: Companies of one, what is your tech stack?
This question has most likely been asked before, but since our industry moves fast I want to ask it still. You guys that roll your own operation, what is your business (no need to out yourselves) and what tech stack did you choose to complete it?
Also, if you don't mind, do you think the tech you chose had any effects on your success? If it did, why?
117 comments
[ 3.2 ms ] story [ 212 ms ] threadI use pretty much anything that gets the job done with the least dev time.
Effects on success: I already knew this stack (no time lost learning new tech), can run with a very tight budget (suitable for starting a business on the side). And, obviously, this is a great stack that will scale far into the future if needed.
I've been working on building out a productized offering of a starter kit for this stack: https://www.saaspegasus.com
https://broadcast.listennotes.com/the-boring-technology-behi...
Would maybe add Docker (without K8s or any orchestration).
- I use Redis with Celery instead of RabbitMQ (not because it's better, but can be picked for other usages like caching, etc.)
- I use Heroku to ease deployment instead of having to deal with servers (but I'd like to add serverless to my stack, Heroku is not optimal for SPA deployment)
- Angular instead of React (mostly because at the time, I absolutely wanted to use Ionic)
Effects on success: fast to run, very reliable back-end, no need to be expert in Javascript and tooling (because angular/ionic is very opinionated)
Bad effect: need to deal with 2 languages in parallel can be exhausting sometimes.
Frontend: Angular 7, Angular Material 7, Apollo GraphQL
SaaS (free tiers): Auth0, Sentry.io, Smallchat, Braintree, Netlify
Hosting: Hetzner
This was my first project using Elixir/Phoenix and it’s been really fantastic, I couldn’t recommend it enough for being very productive and it’s fairly performant to boot.
The mobile app was built using Flutter (again my first project with Flutter), and it has honestly been great. I come from a Java background and Dart is extremely similar so it took no time at all to get acclimated.
Mobile: Xamarin
CI/CD: Azure Devops, AKS
Reason for choosing it: 15+ years of experience with C#, Vue is easy to learn, Xamarin is also C# for both Android and iOS
So i guess sticking with what you already know is the best when starting out.
Finding product/market fit is waaaay more difficult than learning new tech.
You will have time to optimize it later when you get traction and the product kept together by duct tape starts to fall apart under pressure.
It's likely been helpful because it's a stack I'm good with, and it has very mature tooling and libraries (via JVM). The alternative was basically C, which has higher quality mailserver libraries but seemed a lot harder to work with from my point of view.
Backend: NodeJS, Express, MongoDB
Frontend: React (CRA), React-Router, React-Leaflet (for maps)
Infrastructure: AWS, S3
Bonus point: no single test written (neither backend, nor frontend), project is up and running for >1year
Server: Digital Ocean / AWS
SaaS: Airtable, Helpscout, Sendinblue, Sendgrid, balsamiq, StatusCake, Typeform
Mobile: Xamarin
CI/CD: GitlabCI(Linux), GithubActions(macOS+Windows)
Soon: Rust
---
Data: Postgres
APIs: Java + Dropwizard
Frontend: Typescript, transitioning from Angular (1.x) to React
Hosting is on a cluster of cheap Linodes, and transactional email is handled by Postmark. Shout out to both of those services, which have been rock-solid compared to others I've tried. I absolutely think the choice of tech has helped Quail succeed -- it's boring software built with boring technology, which leaves me free to focus on the more interesting parts of the business.
Did you evaluate Digital Ocean as an option?
Debian, KVM, Apache, MySQL (with Percona for clustering), GlusterFS, rSync, HAProxy, PHP, jQuery
I actually own 3 servers :) I know, it's super boring, but this stack has only failed me once in about five years.
Yes, in my opinion this stack has helped me a lot in earning a living with my company because it just works and saves me time to do other things that earn money.
Think it like, I am an Indian and want this software in Hindi/Gujarati/Tamil. What I will do is grab your global English file, Translate the appropriate part of strings to my choice of language and push those changes to your software. which means user who are capable will support ecosystem.
Most of my software is written in Haskell, with the Yesod framework handling all the HTTP stuff. Data is mostly persisted in PostgreSQL, with some caching and queueing stuff done in Redis. I try to avoid JavaScript if I can help it. When I do need a richer UI, I'll add small bits of plain JavaScript, sometimes with jQuery. When I need a more complex UI, I use Elm. Everything runs on NixOS machines on AWS.
Not wrestling with constant runtime errors and not being afraid to make broad sweeping changes means I can adapt the software to the business more quickly.
I liked Ruby on Rails, but I didn't like the magic, nor did I like the runtime errors.
That's basically how I use Haskell/Yesod. A better Ruby/Rails.
You certainly can do very interesting things with Haskell, but nothing compels you to. Writing boring software in a boring way with Haskell is totally fine, and works well for my businesses.
I'll clarify though that I'm not suggesting I do OOP in Haskell, if anyone reads that into what I wrote.
I don't think relative obscurity makes the technology itself exciting. I certainly didn't choose these technologies to be different, or to be fashionable. If I wanted to play with shiny toys, there are so many others to choose from. The shiny toys don't really appeal to me. I have businesses to run, and the technologies I chose are from a position of total pragmatism.
I sincerely believe it's easier to use Haskell and NixOS for applications of beyond trivial scale than, say, Ruby and Ansible. And I say that from experience.
As simple as possible, but not simpler!
There's also the Yesod Book which is available to read for free on the same website.
db: postgres
hosting: centos on linode servers
external services: mailgun, geoipservice, paypal, paddle
When starting from nothing, these were incredible platforms. Features like the OS, web server, memcache, taskqueues, databases, startup-scripts, emailing, and auto-scaling were all built-in with almost no configuration.
The PaaS wave has pretty much come and gone. Now you need to think about and choose your linux image. If you want memcache, setup your own Redis server. For taskqueues, you need to master RabbitMQ. For email, sign up for Sendgrid or another service. App Engine still exists, but they keep stripping features from it, and push you to standalone services.
When you get very large, you'll likely need to migrate to these more tunable services eventually, but when you're just starting out, it's a huge boost in productivity to have these basic services available that just work for a large majority of use-cases.
My guess is that most of the PaaS users were smaller companies / solos that didn't have the bandwidth to manage all these services and also build their app, and I suspect many operated in the free tier. Google probably recognized they weren't making money in the space, and shifted gears to focus on larger companies that required far more complex setups, and generated far more in fees.
It's a shame there has been such a strong movement away from PaaS, it was far easier in the past to get a fully functioning platform up and running than it is today.
Database upgrades are stores in an upgrades/<version>/upgrade.sql format. There can also be upgrades/<version>/upgrade.sh shell scripts.
For testing: back end is a bunch of single files run through a small, purpose built wrapper. Front end uses Jest.
Git hooks run locally for pre-commit and releases. Deployment is handled automatically by GitHub web hooks. The server handles any upgrade file (upgrade.sql and / or upgrade.sh) as triggered by GitHub web hooks. General rule of thumb here is never commit or push to master unless you're confident everything is ready (this only really works for a single person!)
Application server runs on a single instance Debian VM on Azure. MySQL runs on a separate VM instance on Azure, with a failover configured. There's also a read-only MySQL replica which is used for pulling large amounts of reporting data.
For backup (outside of that provided by Azure), there's a series of shell scripts running on cron to dump the database to an encrypted and time stamped backup. These are periodically fetched by other servers in different locations. Backups are kept for every business hour of operation. For user generated files (>1TB per year), rsync is run every hour on a couple of backup machines. Backups are manually checked by a person (for completeness and restorability) once per month. Automated backup checks are run daily on cron.
The longest down time that has been had in six years is fifteen minutes which was due to a bad database upgrade.