Ask HN: Companies of one, what is your tech stack?

---

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.

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.

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//upgrade.sql format. There can also be upgrades//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.