Ask HN: Companies of one, what is your tech stack?
Hello dear HNers.
Each year for the last two years I have asked companies of one, meaning companies that consists of only one person of what tech stacks you use. Feel free to link to your site or project for show case if you want.
Here is the last two threads:
(2020) https://news.ycombinator.com/item?id=25465582
(2019) https://news.ycombinator.com/item?id=21024041
What is your tech stack?
Why did you choose it?
Do you think your choices had any impact on your success?
Thanks in advance!
326 comments
[ 3.7 ms ] story [ 306 ms ] threadMy next backend might be on Go and just use a simple Rest service, and minimize Firebase usage (it is still good for real time chat type of apps).
If I start something new this year I think I would opt for Rails again. Even though it’s long in the tooth nowadays, I would choose it for productivity, time to market and availability of people if the project scales.
I had no real experience with either before, but I think I'd agree with your summary. I felt Django was a bit "cleaner" and the code felt less magical, but I definitely spent quite a few hours trying to get things working which "just work" on Rails. The Rails library ecosystem seems a bit better too (both in terms of quality and quantity). Both enabled me to get a lot done with very little code, which when it comes to back-end I'm a fan of!
Tech Stack:
- Ruby/ for webapp and user facing service: very quick to get the feature out, easiser to work with HTML, database access. Being a one man shop, I have to develop fast
- Go: mail server and anything that isn't user facing or doesn't involve rending HTML. Statically type to reduce bug, performance to cut cost, this is the core of business.
- React Native: for our (upcoming) mobile app so I can share code for both of android/ios
I think the ability to ship out feature fast is important to keep user engage. And with the performance of Go I can keep cost low. https://hanami.run currently handles about 50K domains and processes 10 email per second and the entire infrastructure is ~ $100 per month including redundancy.
You may want to hire a native English speaker to check the text on your website though, it's full of errors and odd wording.
I have a long term itch that I want to scratch soon, whether it's possible to dispose of PostgreSQL and just store my data in an S3 compatible object store and yet still have a SQL interface to it. https://blevesearch.com/ is on my list of things to look into for this. I'd already structured the PostgreSQL schema with the possibility of putting individual tables into an object store, but as my databases grow I'm keen to avoid becoming a DBA and I don't use most PostgreSQL features so if I have the chance to reduce my tech stack to just Go I may take it.
What I've learned from having a mix of Python + Django + some NPM... bitrot and maintaining dependencies is a debt that you have to start paying way too soon. Originally only the API was in Go, but that is the one part that over years has required virtually no debt paydown due to the language, environment, dependencies. You can leave a Go application for 8 years and all you need do is compile it to the latest Go and everything works perfectly... I can't even run or upgrade Python apps from half that time ago without major work to bring it up to date. As the side projects proliferated or grew, it is less overall effort for me to rewrite in Go than maintain everything else.
It can work if all you will ever need is a key value store, but as soon as you need SQL-like queries (joins, filtering, transactions) you will be stuck reimplementing a sql engine in your app code.
I recommend to try SQLite with some kind of replication (either Linode disk snapshots, Litestream etc).
Having your state observable and local to your application instead of a slow http hop away makes development much easier.
https://github.com/rqlite/rqlite/blob/master/DOC/FAQ.md
Only if you're intent on keeping the s3-only architecture when it no longer makes sense, and the transition to SQL need need not be hard if you've been disciplined about your data structures from the get go.
I've been part of a transition from s3 only to s3/sql when business requirements changed, it only took us a week to set up a db, set up a workflow manager to insert necessary data into the db when something uploaded to s3, and ran some batch jobs for data that already existed. Total data in s3 was ~1pb.
IMO it's all about whether your problem space fits well with s3-only, and sometimes it does!
- S3 Select: https://docs.aws.amazon.com/AmazonS3/latest/API/API_SelectOb...
- Athena: https://towardsdatascience.com/query-data-from-s3-files-usin...
How much is too much data? It depends. On things you won't be told. Varies day to day. Totally random.
For example these from a multi-tenant SaaS forum platform (it's old, but it's also OSS so I can show you)...
This helper to get connections: https://github.com/microcosm-cc/microcosm/blob/master/helper... used like this for inserts: https://github.com/microcosm-cc/microcosm/blob/master/models... and this for reads https://github.com/microcosm-cc/microcosm/blob/master/models... .
But searches... i.e. highly consistent SELECT queries with different WHERE statements (and potentially FROM statements), then in each project I tend to have an idea of a search struct ( https://github.com/microcosm-cc/microcosm/blob/master/models... ) that will validate the inputs and represent the search query, and then something that will consume that and build the SQL for it ( https://github.com/microcosm-cc/microcosm/blob/master/models... ). This isn't pretty... but it's easy for me to tune, debug, and keeps the rest of the code base very maintainable... all the complexity is here in the search.
The vast majority of SQL is very very simple and needs no ORM, and the complexity is just in the search scenario where I want to be able to tune the performance more than an ORM would allow me to do so.
To benefit from the SQL tooling (syntax highlighting, autocomplete and so on).
* Flutter frontend iOS/Android
* Parse Platform backend backed by MongoDb, hosted on Hetzner dedicated server with backups in Azure
- Migrated from Firebase
* ASP.NET 5.0 backend for various other integrations and periodic back office jobs
- Migrated from Firebase Functions
* Back office tools (CRM, billing etc) in React/Redux
- Currently experimenting with Appsmith to allow for quicker iterations
* Landing page in React
- Originally just plain HTML. Re-wrote to React to be hip.
To delete a component you have to find it in the component list, open a hamburger menu and delete. This despite having a panel with component details open with plenty of screen real estate for action buttons.
The API I use outputs data in a nested json ("results: ..."). As such Budi parsed everything into a single column. There was no clear way around it. Automations maybe?
In general there was very little use of the screen with most things being empty. I guess it is earlier in development than Appsmith. I do like the aesthetics and SSO support though. It was also much easier than Appsmith to install self-hosted. I'll keep following the project.
I'm a co-founder of Appsmith. Thanks for trying us out. Would love to know the problems you ran into while self-hosting? We are replacing the install script with a docker compose, so errors should reduce. My email is abhishek@ if you need help.
You've made a pretty great product and I look forward to following your journey. We're already using it in production.
This is fantastic feedback, thank you very much for taking the time to write this up.
We totally agree with the points you have raised - in fact we are in the process of addressing the component deletion problem; providing the ability for users to delete components with the keyboard or use an action bar that will be shown in the preview.
As for mapping data - this is something that is requested a lot and as such is high priority. We will be working on this in the coming weeks, providing full JS support and transformation logic for any source of data that you fetch from your Budibase applications.
Great to hear you had a good experience using Budibase self hosted. We are constantly trying to make the Budibase setup process easier, both through our self hosting setup CLI and through standard deployment configurations that developers are used to - such as docker compose and helm charts for kubernetes. Which method did you use?
Please do continue to follow Budibase - We are confident that you will love the features we planned on our roadmap for the next few months!
https://github.com/Budibase/Budibase/projects/10
Your product is solving a very real problem that I think is under served. I developed a lot of back office tools in my old job. It was very easy to find good ideas for tools that would improve the workflow and efficiency of our sales, marketing and accounting departments.
I found that rapid prototyping and quick iterations worked great for finding good solutions for non-technical stakeholders. It made it possible to give them something concrete to "touch and feel" after every meeting. It spurred a lot of engagement.
Low-code tools like yours will really aid this kind of process, and I look forward to seeing where you'll go.
I tried to add my REST API as a data source, but I had to initialize it with an endpoint that returned some entities. My base endpoint ('/parse') does not do this. Therefore it seems like I need to add a new connector for every API resource I have ('/parse/classes/Dog' etc).
I added a table and hooked it up to the data connector I made earlier, but despite using a previously configured connector I had to re-configure authorization headers etc. Inbuilt pagination was nice.
I clicked "Test&Finish", everything looked alright but the table in the designer did not update. After spending a few minutes trying to figure out what went wrong I tried the play button and it seems like it worked all along, just that the data changes is not reflected in the designer. That kinda ruins the WYSIWYG aspect of it.
I figured I should try one of the templates to see how a real DronaHQ app can be. It seemed to me like DronaHQ can do more complex apps than the two others. I tried the Dashboard template. It had a bunch of filter options, but nothing happened when I clicked on them.
Overall it looks like DronaHQ is more ambitious than the others. But the bugs really needs to be ironed out.
But these feedbacks encourages the team to smoothen the experience further.
Yes, you are correct the platform is capable of creating quite complex apps too. We have many operational tools built on it by IT and business teams alike.
Thanks again for taking time to share your feedback.
Fronted mostly static with Stimulus + Hotwire for a few dynamic parts.
Images via S3 + Imgix.
Metabase (also on Heroku) for analytics.
Trying to keep it as simple as possible. Not quite successful yet, but pleased with the tech stack so far.
I think there are some potential performance benefits of liveview (less sent over the wire and less work done server side) however I prefer to optimise for simplicity and fewer bugs.
Edit. Caveat this with the fact that I haven't used Livewire in anger.
- Gatsby or Next depending on how dynamic the content is
- Firebase for db, auth, and bucket storage, and sometimes hosting
- Vercel for NextJS hosting
- Recoil for state management; after years of using Redux it feels amazing, like it's a part of React
- ImmerJS for immutability
- SASS for CSS
I love my current stack. It definitely took a while to make everything work together smoothly. I don't understand the complaints about modern web dev. I've been building websites for almost 20 years and this is the most productive and fast I've ever been.
The only thing I still haven't figured out is CMS. Tried all of the fancy new headless CMSs but nothing works for me. Working on my own.
I think what the market is missing is a sort of locally run CMS that is file based with Sqlite and managed completely with Git. Something that can can be moved around with project easily and have great version control.
Let's say you have a /content folder in your project that is it's own separate git repo, and there you have .md or .txt or sqlite files, and your assets, and there's a browser based client to manage it that runs locally.
Many people don't want to be tied to a provider to this level (I think it's all about trade offs, not saying it is a good or bad thing).
In the stack you described, in my experience, it is a real headache to get a stable and realiable system where you need authentication, permissions, users management, a CMS, background jobs, input validation, migrations, internationalization, etc.
Ruby on rails, Laravel, Django, etc provide a clean, well documented and battle tested solution to all of this. The modern stack you describe, if not outsourcing all of this to a third party, it is pretty complicated and no one builds it the same way.
That's why people complain about these modern stacks being complicated, you're just not feeling it because of the trade offs you've made. (Good for you!).
Deployment: Docker Compose. It's great to just set a DOCKER_HOST environment variable and I can deploy to any server with Docker installed.
Backend: a Go service. Could be any language really but that's what I know. Just takes requests, does some business logic and returns HTML templates.
Frontend: I'm not a frontend dev so I try to avoid it as much as possible. For UI, I use Bulma (a pretty comprehensive bunch of CSS components), with a tiny sprinkling of vanilla JS for small client-side animations (e.g. burger menu toggles). For any user action that hits the backend, I use https://htmx.org/ and just return a small HTML snippet as the API response. No point using client-side JS for that (no latency gains and makes the tech stack less homogenous).
Love this - a terrific cheat code!
All quite boring and stable, the way it should be :)
I have a longer writeup, along with my reasoning for the technologies I chose: https://kubami.com/articles/my-modern-saas-software-stack/
However I'd say React is so widely use I'd say it is boring and stable (as the frontend tech goes)
Terraform, well, what is the alternative? Clicking through web interfaces, or bash scripting the cloud-provider CLIs.
- nltk - preprocessing
- spacy - preprocessing, entity recognition, part of speech recognition
- gensim - Similarity and clustering
- pytorch - ML model building
Currently looking into adding Tailwind (CSS)
* PHP with Laravel + Postgres on the back
* Blade + Livewire on the front
* hosted on Clever Cloud
I chose it, because it's a stack where almost all problems have already a solution because others had it before. Also, and this was really important at the time: There is just so much built in, PHP+Laravel is a powerhouse for rapidly developing MVPs.
I'm still pretty happy with it. It can take you pretty far if you keep your code base clean, use all the existing tooling like static analyzers, code formatter, and write tests. While success is still moderate, I don't think I could have done it with a different Tech Stack, at least not in the same time-frame and with the same confidence.
I have a question for everybody who uses Laravel or Symfony:
Did you compare it to the other one before you made a decision? What made you decide on the one you are using now?
I also would be interested in the same question regarding Django and Flask!
Breakfast of champions right there.
https://cardinia.net/
Here is my tools & workflow:
https://nudge.id.au/v5/img/Cardinia-Electronics-Workflow-202...
Professional CAD tools are not cheap, so I'm basically breaking even. I'm mainly doing it for the love it -- I love to create things to inspire others to also create.
Luckily I have a full time job to keep me going :)
I hate to say it, but maybe no one would really care if you would pirate it? It just doesn't seem right to spend so much money on such expensive software that is probably that expensive due to big business using it and no competition.
I used to pirate everything, but is it a solution? In the past perhaps, I wanted to use expensive software, I was experimenting, didn't have the means to buy a license, and there weren't many alternatives to mainstream software, either proprietary or free. But nowadays things has changed for the better, so I try to build my workflow around what I can afford.
On a tangent, in my opinion, the advent of crazy cloud subscriptions have stimulated the community to find alternatives and promote more sustainable software. GIMP or Blender wouldn't be what they are today if everyone kept easy pirating Photoshop or Maya for example.
To op, if SOLIDWORKS is draining your pockets look at these alternatives[1], it's not my field, I can't say anything about them.
[1] https://expertratings.net/solidworks-for-free-and-alternativ...
Appreciate the links! Indeed, we're seeing OSS tooling getting better and better!
Well it could be a solution if you are just starting out. CAD is very complex stuff so it's not likely that there will be a good open source replacement to Revit for example any time soon.
I really don't want to pirate software in general but if the license is like $2500 / yearly it's such a ridicolous amount that there is no good options left.
- TypeScript / Node / Express
- PostgreSQL / RabbitMQ
- HTML / Tailwind CSS / Vanilla JS
- Hosted on two DigitalOcean droplets
- Deployed as Docker
- AWS SES for sending emails
I only recently moved to Rails though. Before that I was full stack TypeScript, which was cool and I still miss the static types, but it’s worth going without them.
Node is great, but I didn't come across any frameworks that rival Django or Rails in terms of maturity, and for a side project with no special requirements in terms of scalability etc., I'm not really interested in piecing together multiple libraries or writing a lot of code myself.
I actually ended up building the back-end twice lol - I was looking for the opportunity to try out GraphQL (overkill really, and it goes against what I said about keeping things simple, but I felt it was a good opportunity to try it) and ended up hitting some big performance issues with Django + Graphene – not sure how much of it was my fault vs. Python's GraphQL being slow, but in the end I rewrote the API in Rails + ruby-graphql in half a day and the performance is 5-10x faster there.
Having had the opportunity to build the same thing in them both, I'd say that Django's ORM is quite a lot better (I prefer the Django way of "update the model and the ORM will work out what migrations you need" vs Rails where you explicitly create migrations) and I prefer the Python language (simpler syntax, Ruby has so many ways to express the same thing); but Rails is probably actually quicker to work with and the quality of the Gems available for common stuff seems better than the Django equivalents.
Ultimately both Rails and Django let you get a lot done with not much code and are pretty similar conceptually – I'm impressed with both!
- Vue / Nuxt / Plain CSS
- TypeScript / Node / Express
- Hosted in your own personal cloud thanks to Deta Space (https://deta.space/discovery/webcrate)
Nuxt made the frontend super simple and fast to build, it takes care of a lot of things for you! Deta is also awesome for devs
-NGINX
-PHP
-MariaDB
All running on 3 VPS's. Everything I want to do can still be done with this stack.
I went with Flask (python) + Bootstrap for my website.
The apps are created in Flutter, which was a great choice looking back on it. This allows me to have 1 codebase for both Android & iOS apps (most customers want both). If developing an app for just Android would be 100% effort, developing an app for Android and iOS with Flutter is around 130% effort I'd say. Those additional 30% mostly come from inconsistencies in Flutter between Android & iOS and from desired differences between the platforms, e.g. Material vs Cupertino design.
I developed native Android apps before and now I'd even use Flutter if I wanted to just create an ordinary Android app. It's just so much nicer to use in my opinion.
Summary: Flutter was a great choice, Flask is fine too, nothing to complain about there.
Also make sure to hover the image, it's animated! I love how the nested images get animated too.
All in all it was fun to work on and I learned a lot about SVG while I had nothing super important to do :)
If you like the column heights aligned on /convert/appdetails.
Small suggestion, could you not automatically display the pricing according to the location of the IP address of the user. My IP is being guessed as its from Indonesia and I see pricing that I am unable to read. And I don't see an easy way to look at the pricing in a more familiar currency.
Far too many websites do this, its so annoying :(
I'll add it to my todo list to offer a manual override :)
Also seems like a very low price tag, I guess you're working with cheaper developers, have some automation in place and/or take on simple websites? Or maybe I overestimate the difficulty of doing this?
$850 for both android + ios is about a day's worth of work as a medium paid contractor in the U.S, and I imagine it takes longer than that to do this.
Creating the apps is mostly automated and the apps use webviews along with a few native components. Without webviews and automation this would never be possible at that price point, you're totally right.
There's lots of competitors that offer pure webview apps at ridiculous prices (I've seen $5 even). You can't publish those in the app store though (even if you manage to submit it for review without any help). So native components and help with publishing the apps are quite essential. And that's where a lot of the involved effort lies: communicating and helping customers.
Working on improving that day by day though :)
- Django/Python
- SQLite
- Celery and Redis for task queues
- Bootstrap4
- jQuery
- Sentry for error tracking
- Stripe for payments
- EmailOctopus for newsletter
- SendGrid for transactional emails
- NameCheap for the domain
- Linode for hosting
Running costs are USD 7/month for Linode + USD 15/year for the domain. SendGrid is currently free through the Twilio Startup Program.
Why did I choose it?
I am a lawyer and startet to learn how to code from scratch.
Python was being recommended because it is easy to learn. So I chose that.
Further, there are many Python/Django tutorials available online and I was always able to find my answers online. That definitely helped me to keep going and not give up.
For capacity reasons (company of one) and due to my focus towards Swiss founders, the site is currently only available in German.
> What is your tech stack?
The choices are python, scala, julia, matlab and R. Of these python takes at least 90% of the market. I am using python and will do so for the forseable future. Don't like it but it's super practical thing to do. Fingers crossed Julia hits mainstream in the next few years.
Since I am mostly in the computer vision world my stack is torch, torchvision, pytorch-lighting, opencv, scikit-image, scipy and numpy. From time to time i call upon numba when it is impossible to avoid a loop (python loops are sloooooow, numba JIT compiles). Very rarely i coded stuff in C++ and used cython to link it to rest of python. Most of the stuff is already there. For model inference serving i use fast api.
> Why did you choose it?
I chose python because there is no real choice here. It's a monopoly. Winner with most ready to use packages takes all. I am rooting for Julia to eventually win over python as using python as the (big) data language is contradictory given how slow the interpreter is. Also it is not a GPU native language.
Torch was more of a personal choice as I really hated tensorflow 1.X versions and the compute graph. It was hard to debug and follow what is going on. Tensorflow 2.X moved to same mode of computation like torch but it was already too late for me.
> Do you think your choices had any impact on your success?
I think going with tensorflow would have worked as well. Lot more annoying but good base. Using language other than python would have been a bad idea. Practical ML is a lot like JavaScript WebDev. Get a bunch of stuff from 3rd party packages and write some glue code.
- Django
Enough said, really, it's a solid workhorse with a healthy ecosystem. The admin feature is very useful for simple backend data management. No other particular reason to pick this over Rails, Laravel etc other than my familiarity with Python and the framework.
- PostgreSQL
No issues here, works just fine. I use the full text search instead of a separate search indexer such as Elastic - it makes the deployment simpler and reduces overhead of serializing and syncing the search index and database. You can get good performance by paying attention to queries and indexing.
- Redis
Caching and queuing. I use rq [1] rather than Celery for running background tasks, it's less complex and generally easier to work with, especially if your needs are simple.
- HTMX and AlpineJS
SPAs can be a pain to build and maintain if you are a solo developer - it's almost like building two separate applications, and then you have to handle the integration of your backend API and frontend app. HTMX [2] lets me get 90% of the way there while still using plain Django views and templates, while still providing a smooth end-user experience. AlpineJS [3] is great for dealing with the more complex interactions where Javascript is really needed, but I still want some lightweight structure.
- Tailwind
I'm not a designer/CSS guru, so Tailwind is great for providing sensible defaults. Was a bit skeptical at first of maintaining long inline class names vs something like Bootstrap, but Tailwind turned out to be surprisingly productive.
- Dokku
Basically Heroku without the expense. Has a ton of features and buildpacks for managing single-node applications, from LetsEncrypt integration to database backups. As I run the whole thing on a single Digital Ocean droplet, this is perfect - not sure what the next step would be when/if I need to scale up to a multi-server setup.
- Ansible
For any server setup and routine maintenance stuff.
- Mailgun
Email sending. Still on free tier.
- Github Actions
CI/CD pipeline. Works fine, very few outages or issues, pretty easy to set up.
- [1] https://python-rq.org/
- [2] https://htmx.org
- [3] https://alpinejs.dev/
https://unpoly.com
I also used Hotwire for a while, but that seemed much more of a Rails thing and again, htmx was just a better fit for what I needed to do.
- React and next.js for the web app.
- Node.js & express for the API.
- React-admin for the back office.
- Postgres for the DB.
The biggest benefit to me of the above stack is running it out of AWS lambda. Pay only for what actually gets used, and more importantly it will scale to any sudden surge in customers without any effort on my part.
What do you use for accessing the database or as ORM, etc?
How do you do validations server side and show error messages to the user?
How do you do i18n in general, and also related to the previous question (error messages)
Do you use any CMS? How do you explore your data?
How do you do background jobs?
How do you do migrations?
How do you do authentication and permissions?
All these things are what drove me back to Django. I wonder how people solve this without reinventing the wheel or having to write and test a ton of glue code. I wonder if I'm missing something or I'm just too lazy or not good enough (I'm not trolling, just genuine concerns)
https://mitchel.me/slippers/
https://unpoly.com
https://surplusci.com - Rentable dedicated CPU runners for GitHub Actions/GitLab CI https://ragtime.cloud - Hosted storage for Joplin the note taking application
> What is your tech stack?
- Front: Vue + NuxtJS
- API: NestJS + Typescript
- DB: Postgres
- Infra: Kubernetes + Ansible + Pulumi
- Hosting: Hetzner
> Why did you choose it?
- Front: Vue is less complex than React, NuxtJS enables SSR and pre-rendering which is ideal for SEO (not that I'm chasing SEO too agressively just yet)
- API: NestJS is the best implementation of light yet structured MVC I've seen for (spend enough time with wild Express/Fastify codebases and you'll want some structure), has a lot of concerns taken care of just about the same way I've (re)written them on various projects myself. Typescript because life is too short to not have a compiler do some of the work for you.
- Infra: I've paid the initial cost of learning Kubernetes so it's actually a really easy way to deploy containers and manage my infra (TLS certs, open ports, machines, virtual machines, etc) for me. Ansible is great for initial setup, Pulumi is great for managing big IaaS provider pieces (AWS Route53, SES, etc)
At this point I've actually built a set of reusable projects to launch SaaSes, and at this point what it takes for me to launch a new SaaS is copying ~3 repos, find/replacing and running make a few times.
I want to make that SaaS-launching setup a SaaS itself -- as a completed/perfect implementation would cut this down to only value changes in a single file, which I could easily make a web form and then people could launch their own things. That's far in the future though.
> Do you think your choices had any impact on your success?
It delayed launching quite a bit, but I'm convinced that my problems might lie in the markets I'm aiming for and products I'm making more than the technical choices.
The technical choices are on the fanciful side -- I could have gotten by just fine with Rails + Caprover/Dokku, but at this point that cost is paid so it's much more about finding traction.
My iteration speed is much faster now as I've developed a reusable set of repos, so it should be much easier to take more shots.