Hacker News new | past | comments | ask | show | jobs | submit login
The boring technology behind a one-person Internet company (listennotes.com)
2010 points by mxschumacher 30 days ago | hide | past | web | favorite | 451 comments



Technology is usually just a means to an end. Unless IP is what you are selling, boring is great. I’ve seen SO many teams burn SO much energy on complicated stacks just to drink kool-aid. It’s mind bogglingly frustrating, especially as a contractor. At the end of the day it’s great for me: I get brought into shit shows to clean up the mess. But deep down, I want projects to succeed and clean/sound systems architecture is how you do that. Doesn’t matter if it’s PHP, Python or Java.

It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.

Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.


Yes! So much this. Every startup I've worked with regretted choosing a trendy tech stack early on. Speed of development is BY FAR the most important thing and the SPA/Javascript framework de jour trend of the past few years is an antithetical to rapid iteration. As a consultant, I'll happily bill hours to untangle that mess, but it's very frustrating to see startups with lots of potential spinning their wheels with unnecessary bloat on the front end.


Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contemplated building solo a few years ago.


And then 3 years later after you moved on someone like me has to come along and cleanup the project.

The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing)

I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,


how is that any different from a custom rails server with dozens of gems that need to be upgraded. how do you build a site without any of these risks and make it last for a decade or more?


By choosing a language with a large standard library and then relying on that library rather than on frameworks of the day as much as possible.

For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.


From what I remember of php applications written around 2009, a lot of them had SQL injection and bizarre roll-your-own-security vulnerabilities. There were some pretty appalling things like the same (wrong) CSRF token validation code being copy-pasted into fifty different files, or passwords saved in plaintext, or customer credit card info sent over email, or every single site being mashed into joomla and drupal no matter whether it actually fit and then never updated.


There are a large number of non-professionals and beginners coding in PHP, they start from say an existing WP plugin ,open it in notepad and start editing until it works,

it happens in JS land too, find some js package made by a newb and run a linter on it, I see issues on code that is written by coders with a few years of experience where they do not use properly the array functions, do not use correctly the lamda, they copy paste same code in 3 or more places.

Do you think that all js,Ruby or Pthon dev would properly use SQL without an ORM? I dpn;t think so, I found recently bugs in a JS codebase where file upload would fail if the file had non US characters in it's name because some parameter was not url encoded, so all developers make mistakes and ORMs were not popular at that time to prevent this kind of mistakes for SQL.


These are all examples of pretty amateur mistakes. This reads more like an argument for keeping senior devs on the payroll than a warning about not using a framework.


It can be both. Senior devs and frameworks are two complimentary ways of managing chaos and organising your code.


A framework will not prevent things to become a mess, in the angular project I inherited in most places the rootScope is injected everywhere, I do not blame the developers either, the angular architecture is not great and when you have a lopt of new tasks for you to implement you don't always have the time to reimplement things, but sometimes the correct solution is not used , though you may want to claim that your favorite framework makes it harder to do the wrong thing.


Yes. I'm working with garbage legacy drupal stuff right now. It is so bad. Makes me die a little every day.


and yet, a lot of vanilla PHP is a mess of code whereas when i had to work on a laravel application i found it a pleasure to work with (even without having any prior PHP experience)

pick your poison i guess.


I agree with you, but what sucks is that instead of 1 or 2 frameworks that are stable you get a large number of them that get deprecated, I was brought to work into 2 PHP projects, one was using yii1 and the second Silex , both frameworks were deprecated and some of the dependencies are deprecated too. I did not worked on Laravel, I hope when I will it won't be again on an unsupported old version.

Also it sucks when you search for help and you need to double check if the solution is for yii1 not 2, or angular1 not the others etc.


that is very true. at least angular1 was stable for quite some time i'd say, it was quite usable until they started working on angular 2.

that means when selecting a framework, don't pick the newest, but look for something that promises stability, and then stick with it. i picked aurelia to once angular 1 was no longer usable. and although i mainly chose it for other reasons, it looks like it will be a stable choice.


It could be a good stable framework, though can you put yourself in my place, say in 5 years you are called to work on your current project, some new small feature must be added or some bug needs to be fixed. So I will have to learn to work with yet another old framework that is no longer populkar and the developers that wrote the code moved to the next cool thing.

It is what it is, I will have to learn and maintain others code like I always done but it would be better if we had some stability as I mentioned, some standard web framework built in JS and browsers that most developers would use and the devs that want new and shiny could ignore that and use whatever.


well, one of the key things of aurelia is to use standards as much as possible. so as javascript evolves aurelia will pick up on these things and remove any homegrown things to use whatever javascript provides instead. so it is up to javascript to grow a decent standard library.


As the other mentioned there are other devlopment stasks that are stable, to give more examples but not for Web, you can get ther code for an old .Net,Java,Qt application, download the SDK used for that version and just build it. There are not 100+ things you need, the SDK contains the compilers, a huge standard library other build tools. If the project had other dependencies those are some standalone .dll or .jar files that you place in the application folder.

For web when I inherit an older project I need to spend a lot of time in finding the correct version of things, like for an older react project it was using an official jsx transpiler but today that package is deprecated you can't just npm install it, so I would have been forced to upgrade the entire build system to use the new thing , but at that moment I had to fix a small thing so I found a hack for the issue and postpone the fixing of that issue.

What I think Web needs is some standard framework, or a framework core maybe jsx or other template thing but something standard to be used in mst projects and for side projects we can toy with the shiny new frameworks and languages.


Try Vanilla.js.


It is missing a lot of stuff, like I want a modal popup, I need to search the web for a solution,

I want a DataGrid with sortable and re sizable columns, i need to search the web, find something that is compatible and also make sure the license is compatible

I want a basic Dropdown widget that can do basic things like ex have a flag+country name or have a list of fonts where each font is using it's family to be rendered. Also the scrollbars can't be themed for when elements overflow in all browsers so you are forced to find something that reimplements the scrollbars.

When I give example of Qt,Net or Java I include the full SDK , if you did not worked with this kind of SDKs maybe you worked with Android one, basically you have the language STL plus anything you need from file I/O, Networking, Widgets, to the serial ports,screen, and a lot of things, you don't have to package install a new thing for each feature.


Sure it is not perfect, but it is still a lot better than any framework as a long-term viable foundation.

All the stuff you mention can be solved with simple libraries, maybe you could push for a library that solves such problems to be widely adopted. But frameworks always bring a new set of problems of their own, which is why no one is ever going to agree on the subject of those.


There was a lot of JS the language progress but nothing that adds this kind of features. Browsers need to fix those bare bone widgets like the select, the scrollbar, add GridViews etc otherwise developers will use some random, low quality ones .

There is no need that browsers select things that are agreed but 100% of people, it needs to satisfy the needs of a large majority that need to create boring and stabe websited or applications.


ok, so essentially the problem is the fragmented development and feature libraries. that is a fair point. let's hope that some javascript frameworks develop into that direction.


React feels safe to me at this point, look at all the JS frameworks it has coexisted with that are now virtually unused. It is stronger than ever and I see it’s future as more of a jQuery than an Angular 1.


Did the tools stabilize though?

I am wondering if in a few years you can pull a project from Github, run npm, gulp (or whatever the REAMDE says) and it will just work.


Completely agree. My default stack is now react + an api in the backend. The way you can reuse components is a great time saver (even for simple apps). I also like redux-thunk to separate all my API calls from the components. Makes everything very lean and readable.

I feel way more productive today than in the old jQuery, knockout messes


I've started to use TypeScript and React on the front end, with a JSON RPC middleware on an express server with helpers that automatically implement service interfaces for API calls, action creators and reducer handlers. And all of them are type-safe.

I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.


Sounds neat, what project are you working on?


I'm currently working on various projects at work that I cannot discuss here, but in parallel I've been working on an express / TypeORM / React (SPA & SSR) framework that I hope to release one day as an open source project.

The main focus is to:

- easily share React components that use Redux state and actions between projects

- rapidly develop new server-side services and immediately use them in React components (by removing code duplication when it comes to creating action creators and action types)

- have type safety

- provide basic server-side and client-side components for basic user actions such as login, user profile, etc

- make it easy to write tests

And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)


Sounds like a lot of work, how do you know that it is a net time saver?


Haha, I guess it is not at the moment, but it keeps me amused. In the first post I was just referring to using JSONRPC over standard REST endpoints as the time saver.


Same here! What's your choice of stack for the api?

PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).


Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD.

It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.


thats probably due to having more expirience, but you still have to do the crud yourself and all the other things that you otherwise would get for free.

i like next.js now but for simplicity's sake i think parrent is right.


For my past six or seven contracts I've been carrying around the same set of fetch util functions I wrote in ES6 a few years ago - it's less than 200 lines of code. If the API endpoints are ready to go, CRUD is the easy part. Which tools would you consider CRUD as something you get free?


It's a bigger investment I would say, but once you build a very well defined api structure and frontend components, things start getting very fast to develop. Also you get the added benefit of completely separate front and backend logic which is very useful in a multi developer environment.


I would go with spring boot. Sure rails is a faster start, but when it grows it becomes a mess. Spring boot gives you the fastest start in JVM-land, and if your product is successful and you need things to scale, or features are getting complex, you still have the spring framework in the insides that you can manage. Boot is almost just defaults.

But spring boot wouldn't exist, if rails didn't change the landscape of web development.


The only problem I see with rails is that it's hard to find devs these days (at least in Europe). Even if they could learn Rails for that project, many I've spoken to wouldn't want to take a job where Rails is required. I just witnessed a project switching from rails to React (for the frontend) because they just couldn't get enough good people willing to use Rails.


That's interesting. This year, for the first time, I've been working with Rails. It wasn't my choice but I've really enjoyed it. A lot just makes sense and it's been so quick to get things from idea to code.


I don't think devs hesitate because Rails (or Ruby in general) isn't good, they hesitate because they hope to gain more relevant experience by working with JS frameworks.

But again, that's just my experience, it may differ for other companies and/or regions.


Rails isn't enough enterprisey (in my opinion..) no firm ever considers rails.. (note, I love rails!)


I heard this before, but when we tried to find a React dev for the front-end part we couldn't find any either. There are more JS devs for sure, but you also compete with literally everybody for talent.


I kind of get the impression that there is a glut of developers who know/are learning React and a glut of companies that are having trouble finding someone willing or able to use React (at least where I'm located).


Have you tried paying more?


> The only problem I see with rails is that it's hard to find devs these days (at least in Europe).

If you need a contractor to help with a Rails project drop me a line (my email's in my profile). Been working with Rails since 2.x days. Not in Europe tho I'm GMT-4.


Why is HN so against people who _enjoy_ engineering? Why should I run some run-of-the-mill stack that has enourgmous legacy cruft and just not "fun". Not every business wants to be sillicon-valley optimized money farm - some people want to do some enjoyable work.


Dear, for your sake only, I am pasting this definition straight from wikipedia -

Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build, and test machines, systems, structures and materials TO FULFILL OBJECTIVES AND REQUIREMENTS WHILE CONSIDERING THE LIMITATIONS IMPOSED BY PRACTICALITY, REGULATION, SAFETY, AND COST.


The exact reason why most software engineers aren't really engineers.


Yes. This. There are only 700 software engineers in my province. I'm pretty sure not many are working on front end web development. Yet every front end job posting is "engineer". Just no. You don't get to call yourself a doctor because you are medically-inclined. Same applies to engineer.


That's fine, but that's not engineering. Bridge designers do not try to build bridges out of materials discovered in the laboratory last month.


... and bridge designers don't design 'to have fun', but to have structurally sound, cheap and reliable infrastructure tool to cross rivers. Or imagine hiring a construction company for your dream house, realizing only after all is built that they were experimenting and 'having fun' with new unproven materials, construction, wiring etc.

OP's approach is mighty fine for his own endeavors, but if I had such a worker hired, there would be a serious talk about priorities. If no agreement is found even 100x engineer would be let go.


Quantum bridge: its in a superposition of open and closed and will collapse to one of those states when you try to cross. Also its made out of glass and runs on the block chain.


Research engineers do. GP said he is not aiming to build a profitable above all else company. Maximizing fun in a hobby seems legit.


For a hobby and for learning it is absolutely fine. The critique is on businesses running that way fmeither since some developers want to drink the cool-aid on the job or since the company wants to be "attractive" riding the hype train. (How else could they attract the best developers? ;) )


Exactly. Look at Eiffel's Folly, for example.


Because real engineers enjoy making hard things boring.

edit: to be clear, I'm not claiming to be a 'real' engineer. I love writing whimsical, complicated stuff if it makes things easier for users, and make sure I'm writing maintainable code my colleagues are comfortable with with code reviews and removing as many flourishes as possible.


I'm sure I read a definition of engineering once that was basically "meet the requirements doing as little new as possible".


I love engineering. I don't love over-engineering.

I also love to experiment with new interesting stuff. But that's not engineering, it's learning.


If you want to hack on new technologies, great, that's understandable. But do that on your own time, not when you're being paid to achieve business objectives.


This is how you kill innovation pretty effectively, especially considering the usual length of workdays in our industry.

Remember: You will not retain talent if you want them to act like code monkeys.


If you haven't got SV money behind you that's even more reason to focus on delivering something that works.

Your own project on your own time? Go for it. Clients should get the best fit, most reliable option, not the flavour of the moment.

(That all said, RoR is not a great choice these days as it is a niche skill)


Clients are usually not hiring engineers. They have opinionns on management, on what should be done, on how you should work and in which conditions. They have opinions on you being remote or not, on how you should look like, on your mental health (cf. some pieces on whether people on the spectrum make better employees).

Most of these opinions are not grounded and you can not leverage the related tools to improve the work process.

How surprising is it that, given how few variables we are left with, these variables are heavily over-engineered?


I guess.

Those restrictions you describe are classic hallmarks of a toxic workplace IMHO, and somewhere I would leave as soon as I had the chance. I guess I'm lucky to have that choice.


RoR is absolutely not a niche skill-there a huge companies using it (GitHub, Shopify), tons of conferences on it (and a lot of Ruby conferences are heavily Rails), and my company personally has had no trouble recruiting devs. StackOverflow puts it at 8% absolutely popularity while Express is at 17%, so just little less than 50%, so it’s not niche just not in the top 3 backend web frameworks.


Assuming your field is web development, what is not a niche skill? It seems the choice of backend frameworks is somewhat fragmented with no clear default winner.


I'm not sure there's an outright winner, but RoR was the hot thing what, 12 years ago?

It can be difficult to recruit for now.

(Also no, I'm not in web development, I have just observed this)


I'm not a Rails developer myself, but definitely noticed a lot of demand for Rails work in the various remote job newsletters I'm subscribed to. Can't say how much is legacy vs greenfield or whether this is a reflection of demand for a niche skill or that Rails is still a popular choice for companies. Either way, makes me regret a little I didn't stick to Rails development years ago as it seems quite lucrative even today.


It s not fun at all 2 years later though

And it s debateable if learning other people’s apis is fun


My first thought was "I wish the startup I'm working for would read this". My second, "eh, wouldn't change anything."

> so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.

Do you have a mailing list or something to get on to get updated on this?


I will hunt down this comment and reply to you in your profile once it’s out!


Please, I too would like to know


And me please


Hunt me also.


Me too, please.


However, the post indicates React + Redux for the front-end. Perhaps it's my bias as a back-end curmudgeon, but those strike me as _unboring_ choices in the front end, particularly if you're not targeting SPAs.

My point being: one person's "boring" could be another person's anything from "clunky and archaic" to "faddy" to "efficient and sensible." Not even Rails, built upon Ruby's idiosyncratic blood magick, is an entirely uncontroversial choice.


So, boredom is in the eye of the beholder?


I agree with your overall point, however I disagree with the "just pick Rails and don't do SPA" part. For startups or any small team, the right approach is whatever boring technologies the team is comfortable with. If that is Rails, great! I personally don't know it so that would be a horrible choice for me. Likewise SPAs are comfortable and easy for me (aka boring), but a bad choice for someone else who isn't comfortable with them.


I think Phoenix LiveView is offering a very compelling value here. You are basically writing a regular server side app that will perform on par with SPA for most use cases.


What is it that Rails has that Node.js doesn't?

Node.js is missing a great ORM but other than that I don't see many things missing in Node.js anymore.

There is also Rails' admin panel but most projects don't need that.


I’m not sure if you’re familiar with what Rails really is. It doesn’t have an admin panel.

Node is a language that you could compare to Ruby.

You can ostensibly do the exact same thing with Node that you could do with Ruby on Rails... but you’d be reinventing the wheel all over the place and duct taping lots of different modules together that all utilize different design patterns.

If you’re good at designing systems, you can do it just fine, albeit slower than I could with Rails. But it’s possible. I have nothing against Node but there’s a time and a place for all tools. Getting an MVP up is not one of them, imho.


Check the top comments here https://news.ycombinator.com/item?id=20920555


I wonder what is wrong with single page apps? As I see it you can largely write the same code, you just have the additional option of modifying the page on the fly.


Nothing "wrong" with them per se, but in terms of system complexity, you're basically doubling it by having application state and logic on both the backend and frontend. When I work on a big SPA, I feel like I'm working on two applications and have to worry about syncing state and logic together.


Nothing wrong with it if you know what you’re doing and have a strong API to power it. Most people don’t know what they’re doing and end up with a duct taped ball or spaghetti. This tendency is compounded when you’re in a hurry to get shit done.


Nothing better than having to maintain 1000 line components. I wouldn't know, but I have dumped them on other people. It made sense to me when I frantically wrote it, how bad could it be? /s


But is the server side method less spaghetti-prone? I'm inclined to believe that you just believe that because it is the way you are used to programming. A beginner will write spaghetti no matter the job, no matter the tools, no matter the method.


>> It hurts to see people continue to make mistakes over and over,

Its because

https://vimeo.com/76499047


If you do write something up, I'd like to read it - solid analysis re systems architecture et al.


Got your email in my notes. Will shoot you a message once I have something out.


I ran a small company like this quite successfully earlier in my career. If you think this is awesome what goes unmentioned is how lonely it can get. Also, any issues you have (business or technology) you bear the brunt of alone. A coworking space doesn't really help either imo, if you like working with others you will miss having coworkers. Just something I think worth mentioning if you think this is something you might want to pursue.


This feels like bragging but I also run a one man company and the loneliness is what I enjoy most. Granted, I only work from 08:45 to 14:30 and some hours in the evening, because I bring my kids to school and I pick them up in the afternoon, but the hours when I’m alone, I am 100% productive. When the kids are at home I mostly do some kind of manual labor to get some sort of exercise. Right now I’m building a shed. Last year I built my home office/guest house.

To make up for the missing social interaction I play football with friends, do some consultancy jobs on the side and I help where I can with my son’s football club.

This really is my dream job and I enjoy it thoroughly. I have no problems staying motivated and every day I have loads of inspiration.

The moment I lose motivation will be a sign for me to sell everything and start something new. I ran an online marketing company before this and that was really exhausting for an introvert like me. Selling that company was the best decision I ever made, apart from marrying my wife.


I'm not criticizing your preferences at all, but I think it's really strange for you to describe them as loneliness. I would say you work alone, but you're not lonely, because you have a bunch of other social connections in your life that for some people are replaced by coworkers. If anything, your comment reflects a kind of strange default on HN where work consumes so much of your life that coworkers are your "friends" and working alone is the same as being lonely.


I should have quoted that word. What I prefer is the fact that it's quiet, I don't get interrupted, I can set my own agenda and I never have to go to a meeting that messes up my progress. I like teammates and coworkers, I just don't need them to do what I like to do.


You have described exactly the kind if work/life balance i desire! I do enjoy a lot working alone since i've got family with little children too. I won't add any value with my comment, i just wanted to thank you since it feels just a little bit easier to know somebody else is having what i want: one day i may have it too.


You can do it. A good life/work balance is something I hope everyone will find. It took me 15 years to get to where I am today.


You're living my dream. I've been working on a side project all year but struggle to find the energy and build momentum while working a full time job.

Did you quit work to start this, or did you manage to work around your day job?


I found that having 10-15 employees (and working for clients instead of yourself) took all the fun away from the work I enjoyed most so I started designing/developing/marketing my own projects as a hobby. It was already earning a living wage by the time I sold the company, and it was always my plan B. So when I got the chance to sell I did not hesitate.


How do you make money? I didn't think farming spiders would pay that well, unless they're really rare spiders.


Super broad question here but how do you guys do it? I mean, how do you go from knowing how to build a basic webpage to knowing that you need e.g. Elasticsearch for search queries. It seems like there is so much specialized tech to learn but no obvious learning progression path.


I shared this answer before on HN:

---

I only learn when I have a project in mind that I want to do. No matter if it’s work on or around my house, creating an app or designing something like a logo or interior. Then I just start. Walk into a wall. Stop. Look for learning material or inspiration. Start over.

Reiterate. Learn more. Reiterate.

I’m not easily frustrated by failure, starting over or general lack of progress. If I have an interesting goal I just keep going. It might not be the most efficient way, but it’s how I learn best.

---

There is no magic bullet. It's a combination of inspiration, motivation and perseverance. Example: I spent 1 year learning to built an app in Swift (together with a friend, one evening every two weeks), then we decided to ditch most of what we learned and start over in Flutter, knowing that it would take us another year and I just don't care. I'll get there eventually.


For how long? I kind of was at your place (no kids, just my girlfriend) for a few years and then I needed a change


Started january 2016, so I’m almost 4 years in. I’m actually thinking about dropping some consultancy clients so I can focus even more on my own projects.

I get that it’s not for everyone but I grew up on a farm so I kind of got used to the quietness early on I guess.


What product/service does your company sell if you don't mind me asking?


I have developed a network of websites (communities and marketplaces) in several very specific niches, all focused on the agricultural sector. The revenue is mostly coming from subscriptions and Adsense.


do you earn 6 digit salary?


Does it matter?


What is your current company about? How are you able to restrict your working hours?


Most of my revenue (subscriptions and advertising) is recurring, so as long as there are no incidents I can just timebox everything I do.


(author of this blog post here)

The hardest part of building this business is to keep motivated for a relatively long period of time. I'm still early in this startup journey. This is only the 2nd year of me working full-time on Listen Notes.

I think it would be helpful to surround yourself with like-minded people (online or offline) -- we are social animals. Indie Hackers is pretty good: https://www.indiehackers.com/

I live in San Francisco and I used to work for companies, so at least I can often hang out with some friends/former coworkers who are doing startups or working in tiny startups.

In my coworker space, people from different companies rarely talk to each other...


Why did you choose to have ec2s with postgres rather than using RDS? I've found it saves me a ton of time dealing with upgrades worrying about backups etc to have RDS handle it.


I love RDS, but having maintained complicated Postgres setups before (at my previous employer we had a few dozen Postgres servers for different big clients, all set up with replication to different geographical locations etc. as well as automated log shipping and backups going to a "homegrown" blob store), it's not that much effort.

What you gain is the flexibility to control e.g. which extensions you want to run, and exactly how you want to set it up. How important that is really depends on what you want to do.


Not OP, but I set up a SaaS platform, and I also ran on straight Postgres (RDS wasn't an option, we weren't on AWS). In my experience, after setting up WAL-E to continuously backup to S3 and giving it plenty of extra disk space (for stalled WAL segments), it worked pretty well with no intervention. Restores occasionally took a bit, but they never failed (we managed a couple dozen databases over five years).


If you know what you're doing (important qualifier), I'd imagine cost is a huge factor too. RDS is pretty often a significant % of your AWS bill - how valuable this is, entirely depends on how confident you are doing it yourself.


Hey, thanks for building LN. I was actually admiring the site design just yesterday while I scrolled through some episodes. "Dang, I hope I can build something like this one day."

You managed to pull me away from my previous preference, player.fm. Good job!


Interesting to hear that your WeWork building isn't an especially social space. I know you talk about why you picked a dedicated office in a coworking space over coffee shops etc., but why did you pick WeWork in particular?


because it's 2-minute walk distance from my apartment :) don't like spending too much time in commute


That coit tower view is pretty killer as well.


At the 4 year in make building a professional services firm in Shanghai, old school work, but looking constantly for online B2C and B2B opportunities, I love IH for the community aspect. Although I find one has to be careful with balancing the amount of work allocated to seeing what others are doing and the hard but inevitably more important grinding out of one's own business aspirations. Great conversation!


Was it hard to come up with the idea and believe in it enough to pursuit it to where you are today? I think self doubt must be a challenge, especially when you are alone and still far from a proven concept and nothing so show to customers. Was this idea the only one you evaluated before you chose it or did you also have other ideas, of which this one you liked best?


Hey wenbin (and any others pursuing indie-hacking), I run a virtual meetup about once a month you might find fulfilling for meeting like minded people.

We just made a Twitter recently, but it has all the links: https://twitter.com/ih_worldwide


do you need to live in SF?


Yes, the worst thing is the huge amount of decision making even over very minor details that has to be done all the time. Coding and maintaining the servers isn't even that difficult. It's all the little stuff like scheduling with clients/vendors suppliers, wondering when is a good time to chase that invoice, which words to change in your proposal for this client, and so all. If you have employees, how to manage them, how to review their work, how to mentor them. It really is death by a thousand paper cuts.


What can help with this is to start building little systems and solve these problems in general.

Dedicate a given day of the month or week for all your meetings so scheduling is simpler.

Chase invoices on the same date every month, chase all invoices that are overdue by some threshold you have set. Just follow the rule, and chase using a template. Perhaps even code the first few chases into an automated system.

Try to avoid customized proposals, use templates for many things. I agree this one is hard.

Managing employees, you have to consider each employee is a force multiplier. The idea here is to invest a day to get a week or similar.

Overall, you need to just invest a limited time into each decision. After that time, go with what feels best even if it isn't perfect and move on. I find the same thing hard myself.


My company's Slack is just me and ~12 Slack bots all doing various things (reporting subscription changes, feedback, bug reports, error alerting, CI status, etc). It's amazing to look at and functions immaculately, but occasionally does have the grim reminder of just how alone it is being on your own.

Especially when you think "this all works great, but would still work equally great with another human or two here."


Dude, I would love more insights on this. I have trouble finding assistants for the most rudimentary stuff and am constantly looking for IT solutions. Please, please, please. Maybe an HN post?


I started a Medium draft a while back just detailing what all bots I use and how I organize all the channels, but it honestly felt pretty boring/droning.

I'll see if I can clean it up and finish it though; if you have any particular questions you'd like to see included (selfish: so I can feel like it's less braggy and more interesting), I'd love to hear them. Contact info is on profile if you don't want to derail this thread. :)


This type of life sounds like only a few steps away from a Black Mirror episode


Years ago Joel Spolsky on his site "Joel on Software" had a "Business of Software" forum where a lot of very small ISVs hung out and discussed items of mutual interest. Anyone know where those kinds of folks hang out now to discuss things?



I second this. It’s a small group of people but with very focused interests and experience. Really good group.



Looks like lobste.rs. Any relation?


Yep. I've run Barnacles for a few years and became the Lobsters admin almost two years ago. They use the same codebase.

https://github.com/pushcx/barnacl.es https://github.com/lobsters/lobsters


I'd presume that they use the same codebase: https://github.com/lobsters/lobsters



Agreed. Part of a two person team, but the other is mainly on the business development front and I'm the main designer/coder.

It's so hard sometimes. No one to really bounce ideas off of, every little thing you have to do yourself. Staying inspired to work is sometimes difficult, because you are literally doing everything yourself it just gets so overwhelming.


Some people enjoy being alone, others don't. You don't know in which group you are until you experience it. Unlike you, I wasn't running my own business, I was just working remotely for a company where the HQ was on a +12h timezone. I felt the exact same way, even if I was working from a coworking space.


The lonely aspect is incredibly difficult, especially if you're an extroverted person that draws their energy from collaborating with others. I also find the lack of accountability to others as hard. I know there are services that cater to this type of founder/freelancer.


I have found that running a twitter account is helping for this. I have <20 people following and their encouragement that my stuff is not total rubbish really helps.


The part that I find the loneliest is making all the core technical and business decisions by myself. I really miss being able to bounce ideas of a partner.

Sure, you can do it with friends etc. But at some point you just become menace asking them to think about your stuff so much.


I used to do this with a friend, for me thinking about his problems was refreshing. We worked in different domains, so it felt like a challenge not work related.


"I ran a small company", what happened? Why did you stop or did it get stopped? What was the reason?

One man show / sole proprietorship is great, but its bad for family life. It's 24x7. Atleast thats how I saw my dad, dining room was the company meeting room and we all are unpaid company "helps",assisting our Dad support the family. This is the main thing that holds me back from being an entrepreneur (sole proprietorship 2.0).


you don't have to do it that way. i run a company, and i don't get my family to help me. as long as i earn enough money to cover the family expenses, i don't need to work crazy hours. i get to take time off whenever i want, or whenever the family needs it, and not when my boss allows it.


I'm kind of experencing this right now, a remote worker whose working on a thing solo. Feel like I need to dip back into a team for a while


I know a few people who have entrepreneur Marco Polo support groups- asynchronous but still seeing actual faces and human expressions.


are there any groups out there for the small technology business owner? i'm extremely hesitant of asking about this because it's a fine line between brainstorming technology problems with like-minds and getting owners who want you to problem-solve for them.


Paul Jarvis, author of "Company of One" has a private academy/community group.[1] I'm not a member, but plan to consider it after I finish the book.

[1] https://ofone.co/learn/


Indiehacker is a good starting point


Mind expanding on the coworking bit? I always think about hitting up a coworking just to have some human contact when I'm working on a project. I've yet to actually do it however.


it depends on the co-working space. at a wework place i found everyone stuck in their little offices, and hardly any opportunity for interaction.

at another space i find people are more social. they organize events, coding workshops, even cooking classes, occasionally they cook meals. there is a fully stocked kitchen that everyone can use whenever they like. just pay for materials used. people often go out for meals together. etc...

when you are working, people will leave you alone, but if you know who else is there and what they do, you can talk to them and help each other. it helps that many are freelancers and not secretive startups hustling for investment money.


artists and farmers have lived like that for centuries. i dont think it s so uncommon that we have to start warning people about it


Ansible, AWS, SES, React and Cloudflare? Gusto, Notion and 10th of different services and integrations? That's boring now?

I was expecting something more along the lines of PHP + a single MySQL machine, plus all the accounting is done on a tablet made of actual stone.

This is not that.


Agree. To learn all of this as a single developer is not an easy task either. These are real frontend, backend and devops languages, frameworks and tools. It takes time to learn.


I second that. This seems really full stack as you can get, but I'm not really a professional dev by training, so I don't know if most people are this hardcore. I built and host some web apps myself but everytime I have to switch from doing something front end to back or vice versa I find I need to refamiliarize myself with a bunch of stuff and have to stop myself from panicking


It sort of depends, if you’ve worked in a couple of corporates where you have to know a handful of various tools at each it quickly adds up to having enough knowledge to quickly deploy even what hacker news considers ‘heavyweight tooling’. Most of these tools have QuickStart guides that do get you most of the way there for a basic use case. I’m running a similar solo project with an almost-but-not-quite similar spreads of technologies.

But as I said, it depends on your history and what you work quickly with.

In the article the author says they chose Ansible because docker felt too heavyweight and unnecessary. It’s true that docker has a lot of stuff you don’t need in there, but trust me when I say Ansible is no picnic. In fact I find it easier to take what I need with Docker and Kubernetes and get running way quicker than I would ‘naked’ Ubuntu machines that I need to semi-manual previsioning with shell scripts or Ruby scripts. I got up and running with Kubernetes on DigitalOcean in less than a day, and Dockerfiles using familiar technologies I’ve used before take less than an hour to iron out.

You’ll get people who say that Docker is overkill and unnecessary and far too complicated for a solo project, but then you’ll get others who believe it’s a small file with 20 lines of declarations, sat alongside a 30 line yaml file that can provision all of your infrastructure instantly across any cloud provider you choose.


Indeed. He mentions halfway down his previous employer is a billion-dollar startup, and why what works there won't work for his micro startup. And yet ... I'm sure a lot of what he learned there is being applied here.


It’s doable for someone with several years full-stack experience. I had worked with all of those systems and more by the time I had 4-5 years experience.


I do this stuff for a living and man is that a lot of stuff for one person to be responsible for. He could probably be a CTO at a lot of big companies making more than he’s making now probably.


I love these stories. I'm a one-person company too: contribsys.com.

My production server stack is Apache + some Ruby CGI scripts, to serve static files and handle billing webhooks. I spend less than an hour per week on devops maintenance.

KISS is the #1 principle when scaling a solo operation.


Mike! Big fan of yours!

For the very few people who don't know mike or sidekiq, read this: https://www.indiehackers.com/interview/how-charging-money-fo...


That should have been the real "boring" stack we're talking about here instead of the 20+ technologies mentioned in the OP.


> some Ruby CGI scripts

Didn't ruby remove its CGI libraries from their standard library somewhat recently. I believe there were mostly helper libs, but I am curious how that works.


CGI is just running a program in response to a request. Things about the request are put into environment variables and POST/PUT bodies are on stdin. Your program writes HTTP headers, two newlines, and the response body.

You don't need libraries. If you have reasonably low traffic CGI can get you really far.


> If you have reasonably low traffic CGI can get you really far.

And even after that, I would expect that CGI augmented with some careful caching (read: all static content and some dynamic content with sensible expiration policies) will get you even farther without having to dramatically change anything.


I built an app in Perl/CGI::Application for a company which ran media campaigns with national brands over a 12-year period. It's not the fastest option but it certainly works.


This would be a nifty exercise for a web programming class. Really internalize a lot about HTTP in a short amount of time.


CGI is still in the stdlib, and AFAIK there's no plan to deprecate it. You might be thinking of a few other methods like URI.escape that have been marked obsolete in favor of CGI equivalents.


Hey I thought I recognized that domain, yay sidekiq! Keep up the good work. By the way we're seeing issues with contrast security gem and sidekiq, but we're pushing on contrast not you.


Thank you! You are always welcome to open an issue if you want a second opinion.


sidekiq! Interesting wenbin also wrote a task queue system... must be something about that type of engineer that leads to this pragmatic tech strategy.


This seems super complex to me. I am a single dev that runs a $30k\mo software based company off of PHP+MariaDB+bootstrap+jQuery+few other plugins. Hosted on a managed HIPPA setup. The firewall+app+DB servers run me about $550\month and I have excellent support. I spend effectively 100% of my time on business logic\ui and zero time keeping up to date on infrastructure (and learning it). Which means my customers benefit from me fixing problems and adding features. Kudos to what works for you....super great... And, for me at least...it is even more "boring" and awesome.


Do you mind sharing what the managed HIPPA setup is? What vendor do you go with for that?

I've always wondered about how easy it would be to setup a SAAS that adheres to HIPPA.


VMRacks (now hipaavault.com). I'm not affiliated, just a completely satisfied customer. As to setting up the business, I would also recommend a HIPAA auditing/hand-holding company. I use Compliancy Group (https://compliancy-group.com).


Just finished my undergrad in cis, and have been grasping at the many services in the industry. How did you find yourself in freelance within clients needing HIPAA compliant?


I am surrounded by people in the primarily private-pay Mental Health space because my (romantic) partner is a consultant in a tiny cottage industry. In my case, it's 100% "people you know". Dealing in PII suuuuuuucks because I constantly have an elevated anxiety about it. However, if it wasn't PII plus the people I know and met......then I probably wouldn't have the opportunity I have.

That said.....had I not done "this", then I probably would have done something more lucrative and "easy". I see non-PII opportunities everywhere, and (mostly) only hang around because what I do now pays the bills.


similarly , making half that and using dedicated servers. When you re a solo dev you dont really have time to risk learning unproven tech or tech that doesnt scale. And as a dev i like writing code that does new and interesting things, not learning tools and other people's APIs. The amount of services this guy has to manage is mind-boggling, and unfortunately i m simple and stupid. I guess i m a hermit dev but thankfully i ll never need to work for others again.


I found the list under miscellaneous to be similarly mind-boggling. There are approximately 56 moving pieces to this "boring" one-person setup.

All the things they mentioned:

Ubuntu, PostgreSQL, Elasticsearch cluster, Redis, RabbitMQ, Django / Python3, uWSGI, Nginx, Celery, Celery Beat, Supervisord, React + Redux + Webpack + ES, Amazon S3, Cloudfront, react media player, Ansible, Datadog, PagerDuty, Rollbar, Slack, PyCharm, MacBook Pro, Vagrant + VirtualBox, GitHub

WeWork, iTerm2, tmux, Notion, G Suite, MailChimp, Amazon SES, Gusto, Upwork, Google Ads Manager, Carbon Ads, BuySellAds, Cloudflare, Zapier, Trello, Medium, GoDaddy, Namecheap, Stripe, Google text-to-speech API, Stripe Atlas, Clerky, Quickbooks, 1password, Brex, Bonvoy Amex card, Capital One Spark


FWIW, this component:

  PostgreSQL, Elasticsearch cluster, Redis, RabbitMQ, Django / Python3, uWSGI, Nginx, Celery, Celery Beat, Supervisord
All of that is a very typical Django stack with React bolted onto the frontend. Whether he runs into trouble managing RabbitMQ, Redis, Postgres or any of the Python services is another story, but at least if he did there are many, many others using the exact same stack, so he should be able to easily find answers to people experiencing the same problems. All of these technologies have several year track records now, too, so (hopefully) they are stable and reliable in production. My biggest concern would be managing the ES cluster.

On the other hand, I disagree with his points about docker being overly complex. Docker images are simple. Kubernetes, once you get the hang of it, is great on GKE and gives you automatic SSL via Google or let’s encrypt, and load balancing and auto-scaling just works. It’s probably more expensive than managing your own servers, at this level, but maybe not since you could pack more services into fewer compute instances.


That's awesome and it is a tech stack that I try to mirror and am confident running myself as well!

It's incredible the amount of knowledge required for a single person tho when you think about it eh? It's the full frontend (which I would have more trouble with) + databases + caches + search engine + metrics + deployment + source control + sysadmin all baked in a single person who is also trying to make it a business!

Kudos for the effort and making it happen, one day I might be joining the same journey with the same stack! Just gotta figure out what actually motivates me to build a business on top of =)


as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners.

I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.


Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.


Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.


And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the output of a team of 5 generalists, hands down the generalists will make a better product every time because there's no buck passing or shoulder shrugging about problems.


IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient.

A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise.

But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists.

(You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)


Completely agree. IMO the optimal efficiency is easily a team of either 2 or 3, with one FE and one BE, and optionally someone doing dev-ops-y stuff for both of them. After that point your 'output per man hours' can only really go down.


In economic terms, sounds like the marginal utility of adding an engineer goes down significantly as companies get larger and past the start-up phase ;)


I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well.

The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it.

(All of this of course assumes you work in an org with lots of really good specialists).


i agree on this point. having highly specialized SMEs certainly helps with scale, for sure.

iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.


“Every time” until they are asked to build a product that requires a deep specialized skill set.

I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow.

Great teams and companies have generalists and specialists.


You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether.

I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability.

It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.


It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops. Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours. Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.



Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack.

In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.


I finally created an account because your comment resonated with me. I have created 95% of my platform by myself which itself was the manifestation of several business ideas. I started out buying servers and starting a dedicated, then vps, then shared hosting farm that requires all of the frontends you mention. I took a different approach, I went all out open-source and spent time creating glue and flashy bootstrap frontends to orchestrate everything reliably.

I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system.

So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)


There are people who create consumer products, and there are people who create the products that power those products. It's no different to when id Software sold licences of their engines to other game developers. Perhaps you can turn your infrastructure into a business of its own.


+1 for selling the golden shovels.


I thought I was reading my own blog post :) We use very similar tech stack at my current company:

- Ansible for provisioning

- Python/Django for website/api

- VueJS for frontend(where needed, some pages are simple Django templates)

- Celery for background work

- uWSGI and Nginx as servers with AWS Load balancer

- Elasticsearch for search

- Redis for caching

- Postgres with Postgis as main datastore

- Datadog for monitoring

- Cloudflare for DNS

Some differences as I am working with a team:

- We do use multiple branches and git tags for releases. Feature branches are also common as multiple devs maybe working on different features.

- We use Gitlab-CI a lot for testing and auto-deployment(ansible script can be called from our machine as well)

- Terraform for infrastructure provisioning. We have stopped provisioning any AWS service by console. Once the service is provisioned by terraform, ansible takes over.

I have tinkered with Docker, Hashicorp Packer but this setup has been dead simple to reason and scale reasonably well.


How do you feel about using a dynamically typed language like Python for all your backend code? Whenever I had a codebase that grew past several thousand LOC it became pretty unwieldy pretty quickly for me personally. I'm curious if there's a conscious tradeoff for people using Python/Django to start because it's really fast to get up and running with (for existing or new devs).


I don't think typing is the problem you make it out to be. You can specify types in Python, and mypy will type check for you. And nothing about Python means you'll have an unwieldy code base, I can only imagine you'd have the same problems in Java.

The real reason to switch would be performance. The interpreted nature of Python that makes things like Django and PyUnit possible also makes it kinda slow. Some places choose to parcel out a few key services in a faster language (C, Rust, Go) and use bindings to call out as needed.


Completely agree, and I'd like to add that it should only be broken out when performance is actually a measurable issue and there's a good business case for it.

A lot of people get caught up on "x is slow, y is fast" and try to over-architect too early on, then end up focusing on the wrong parts of their product, and sooner or later the project falls apart.


Not OP, however it is fine. I worked in a similar stack as OP with a small team (however it used Ruby/Hanami instead of Python/Django, and of course the difference between both stacks). The code had ~100k LOC for the main service (we also had some other services that had dozen of thousands LOC) and it was completely fine to maintain. Most errors we had wouldn't be avoided by static typed since they're logic errors, not programming errors.

Sure I prefer static languages nowadays since I work in a much bigger company, however I think the benefits of static languages is overhyped.


For us, we follow a very tight convention around how we write code. This has helped us in maintaining the codebase. Of-course some tools help a lot too:

- We use standard tools like flake8, isort, black for code linting.

- We are not following TDD, but we do write tests for all features. Pytest helps here

- Proper code reviews. I cannot stress this enough. As a Tech-Lead I have pushed for code reviews even when working on (supposedly) tight deadlines.

- We are also exploring to use type hints introduced in Python3.7.

PS Shout-out to Poetry(https://poetry.eustace.io/) to make our dependency management easier than ever. Updating third party libs is a lot easier now.


We’re pretty much the same - except for Poetry where we are still using plain old pip. Are you able to say how Poetry makes updating third party libs easier?


Python supports optional static typing annotations now.

There are four popular typecheckers that I'm aware of (mypy [1], pyre [2], pyright [3], pytype [4]), which is a little confusing, but any of the four will catch a lot of type issues that typical statically typed language compilers would catch. It's not as robust as true static typing - there are sometimes false positives and false negatives - but I find it helpful.

[1] https://github.com/python/mypy

[2] https://github.com/facebook/pyre-check

[3] https://github.com/microsoft/pyright

[4] https://github.com/google/pytype


Which one is your favorite?


Right - I'm totally on board with the overarching goal of keeping the stack as simple as possible, but at the app level, for the best maintenance story, I would want types.


Automated testing; with any dynamic typed language you have to unit test every single thing possible and it becomes not so bad to work with.


> with any dynamic typed language you have to unit test every single thing possible...

> ... and it becomes not so bad to work with

O_o

How did you manage to put these two statements in a single sentence implying positivity :)

Why do people choose to explicitly write unit tests over and over again for basic things which could be caught by a compiler?

People are losing so much productivity (both short and long term) and being deceived into not having the type system "stand on their way" while they're typing out the initial prototype. This always bites back when you start first significant refactoring.

I will never understand the appeal of the dynamically typed language. Modern, statically typed languages with strong type systems, provide so much more productivity, reliability and confidence in the codebase that it is really irresponsible to ignore them nowadays.


Did you do the entire stack yourself, I'm planning on using almost identical stack, but need some help, do you have some kind of blog on howto or recommend one

If you create a course on udemy/YouTube on how to setup a production full stack, there are many basic setup videos or tutorials, but none on production full stack with load balancing, replication, caching, etc


What's your website? Mine's also on the same stack (https://wakatime.com). Would love to trade notes sometime.


Ours is (https://www.analyticsvidhya.com/). We cater to Data science community. You can contact me through my profile info.

Also, I am a long time user of wakatime. Awesome product :)


I am curious, do you use Django Rest Framework on top of Django for your API?


Yes.


First, that's a great stack and very well written/presented.

One comment - he dismisses serverless as being overengineering. I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.

One can see from the snapshot the servers are indeed severely overprovisioned and underutilized. Building an api with api-gateway + lambda is less work than running django in uwsgi behind self-managed nginx, and is guaranteed to be more cost-effective for unpredicted load.

Same logic applies to the db servers - why not hosted?

And last - the inf is a good reminder that prefixing your api routes with /v1, /v2 is always a good habit.


Good point! For people who have tons of experience with serverless, serverless is probably a better choice than running servers for some use cases.

As a small business owner, there are two types of cost that I need to consider:

Time: the time I use to do A is the time I can't use to do B. Unfortunately I haven't used serverless so far in my professional career -- in this sense, I'm not full-stack enough :) It takes time for me to learn it, understand it, operate it, and experience various outage scenarios to gain the true learnings. It's more costly for me (probably not for others) to use serverless than the things that I already understand. I'd rather spend more time on other non-engineering things nowadays -- believe it or not, I spend 1/3 of my working hours replying emails :)

Money: the money I spend on A is the money I can't spend on B. I decided not to use api-gateway + lambda & hosted db servers, primarily because of $$$. I actually did the pricing calculation a few times last year. In addition, api-gateway + lambda also require some time for me to learn, which I should use to talk to users, marketing, building new product feature, thinking (yep, thinking also uses some time budget :)...


Just wanted to add another reason not to use serverless, or at least AWS. For small projects I would rather experience downtime than big invoice. I had a project running on AWS, but it turns out you can't limit the budget, the best you can do is make alerts when costs exceed some limits. I have now moved the project to old-skool server and sleep much better since.


I used a bit of serverless Javascript (Firebase functions) in a previous startup, and it actually worked really nicely for small self-contained tasks - saving files to S3, triggering customer emails, triggering notifications or webhooks in other services (and ofc in Firebase, actually doing things with the database, but it's not a fit for everything).


> We need to track the API usage

Thank you for this excellent write-up. Monetizing APIs is always a great topic; did you consider or will you consider using a 3rd party API management service such as RapidAPI or Apigee to keep track and charge for API usage?


Yes. I used rapidapi initially (v1) and built my own api gateway to replace it (v2) earlier this year.

The api was launched in Dec 2017 right here on HN: https://news.ycombinator.com/item?id=15825900


I think your next project should be open source your api gateway so others can monetize their apis too


I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.

I was all gung-ho about serverless for a while. I wanted to release a demo for my product and thought I'd cut through all the hassles of managing my own server.

I found it bewildering. It was a whole new skillset with new benefits, but also new considerations and headaches. When push came to shove and the clock to release my demo started ticking down, I just went back to a linux server.

I use the same linux distro at home and on the server, and there are about 3 technologies I need installed. On retrospect I think I made the right decision, but happy to have my mind changed.


I agree, the key here is that it's best to ship with what you know, rather than what is simplest on paper.


I've yet to find someone explain a serverless API based setup that isn't more complicated than good old fashioned LAMP or equivalent. Serverless seems to always come out more expensive as well.


I've been exploring serverless for a project at work, and this is my conclusion too. It's great that we don't need to manage any servers and can easily deploy tasks with one command - but we already have infrastructure to do all that for that for our existing apps.

For someone starting out you don't need to worry about learning Linux and how to configure Apache to serve SSL certificates in the right way, but that is important to know, unless you are happy to always rely on (and pay for) someone else to do that.

To me serverless is similar to Heroku, it's great for starting out but as you start to grow it's going to quickly become a lot cheaper to maintain you own systems. Except with serverless it's not so easy to self-host because you end up relying on all the tooling the vendor provides.


Depends on what you're familiar with. If he already knows Ansible inside and out, why risk getting stuck with some undebuggable AWS failures?

As a solo entrepreneur I can say time risk is a crucial thing to be mindful of. I'll take 10h +/-1h vs 5h +/- 15h any day.


Not to mention that he might not stick with AWS if he runs the numbers- he might hop ship to a different cloud provider if he gets a better deal. I don't think it's appropriate for such a fledgling enterprise to lock in to AWS-isms so they can keep the change provider cost as low as possible.

Also, people seem to be dismissing the value of a rock-solid local end-to-end dev stack which with the latest iteration of technology I feel has become very complicated and expensive. The OP can run the same Ansible for his dev stack as well as his prod and his dev stack doesn't turn into an AWS bill. Most of the AWS managed tech & services is only reliably testable on AWS at a functional/integration level, which is a cost that a company this small shouldn't have to absorb.


Not sure I agree with the anti-lock in sentiment. It's a nice to have, but if what you know well is AWS or GCP or whatever, definitely lock yourself in.


> Building an api with api-gateway + lambda (...) is guaranteed to be more cost-effective for unpredicted load.

Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack [1]. My service needs to handle lots of really small and simple HTTP requests, and almost every request needs to do a (small and quick) database write. I did napkin math – at the current usage levels, Lambda per-request fees alone would use up significant chunk of my current hosting budget.

[1] https://blog.healthchecks.io/2019/08/a-look-at-healthchecks-...


Someone who has been doing this for years before serverless existed can set up and manage this infrastructure trivially, using almost no time compared to developing the application and the business. It also provides you with security: you know the pitfalls and the problems with hosting these, serverless is another new technology which can go wrong.


Yes, and no. If you already have a lot of experience building apps that run on servers, there's a learning curve to switching to serverless. Is it huge? Not really. But there are certainly pitfalls and best practices to learn about. The costs can be harder to predict, especially when starting out. And the tooling is different (and much less mature). So now you have a bunch of stuff to learn about or consider, or you can just go do the same thing you already know how to do with minimal friction. It's possible that the cost savings of not overprovisioning servers is worth it, but I don't think it's that straightforward of an answer, and if your server costs aren't massive, you might be better of spending your time building a great product than learning a new way to build.


I think, and I'm replying to both above comments, that there's a non-trivial cost reduction + DevOps reduction potential here.

Of course, the overarching rule is always "if it works, don't touch it".


How? His boxes are running at 100%. He might be able save some money by switching to hosted db and maybe run his webservers serverless (and creating some keep-alive triggers).

Nontrivial cost reduction would be switching to a different host instead of aws.


As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?

As me how I know. When I was a solo dev doing my own thing, I'd spend way too much time working on things that really wouldn't affect the business but were "good engineering things" to do. If I spent more time working on things that would grow the business instead of wasting weeks writing fancy deployment scripts, maybe I'd still be doing my own thing now!


> As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?

Timeframe has to be considered. If it only takes a week, I'd strongly suggest biting the bullet. A week's budget can be quickly spent troubleshooting issues, scaling servers up and down, installing software updates, hardening systems and whatnot.

It will most likely be much cheaper to run too. Which, in a single-man operation, may be worthwhile.


Think of it the other way round - if your workload is not realtime, but "within minutes/hours", as in processing feeds here - scaling the worker nodes with an ansible scripts needs to be done on maybe a weekly (if not monthly or less) basis and you get 4/3 instead of 3/3 - for a few minutes of work. This just does not seem to be the workload for autoscaling and adding complexity. I've ran a similar setup at a past job - we planned for whatever but in the end it was one person clicking a few buttons to provision a new instance once in a while.

Also some workloads are really bad for lambda, because you can (total napkin math) run 4 cores at 100% load for 24h a day to do your processing, all at the cost of "1 instance".


If serverless were easier, more people would be using it. But it's not simple or straightforward. You have to learn new systems and conventions, it has a bunch of weird considerations depending on the use case, and most people just use it when they don't want to figure out what instance to run some periodic, one-off job on.

It's a niche, just like all solutions that aren't a single Unix process on a single Unix box. Even CGI scripts are a niche. You pick the niche that you know.


I don't know if overprovisioning servers to counter traffic spikes is over engineering, the mental model is pretty simple. May not be as cost effective or infinitely scalable, but it's simpler to wrap your head around.


I take (very minor) issue with your first line and the point "well written" (I do agree with well presented).

Since the author is reading/commenting here, and there was a large amount of space in the original article outlining tools/services he uses, can I humbly suggest they use a tool like "Grammarly" or similar to help with the word-choice(s)?

Some distracting use of plurals for terms - e.g. "traffics", "stuffs", etc - may have been avoided and other spelling and grammar aspects could have helped make this easier to read. That all being said - the 'essence' of the article is to be commended.


Completely agree. Cloud functions are in many cases a better option than maintaining a server, specially for those background tasks that fire occasionally.

The only issue I've found about using serverless is the database. In most cases (Firebase, Fauna, Cosmos, DynamoDB) you have to couple your stack to the DBaaS provider which is not a great idea. AWS recently announced Amazon Aurora PostgreSQL Serverless but while it allows you to use regular Postgres tools/queries you are again tied to AWS.


One hopes that GraphQL abstractions will enable the decoupling. So if you opt for a database that offers GraphQL natively, it might address the issue. You do have to learn the GraphQL ecosystem (new tools/language etc.)


> lambda is less work than running django in uwsgi behind self-managed nginx

If you discount building an AWS-specific deployment process that includes "pip install" from an AWS linux machine image, zipping the project, and putting it in S3.


You can go copy/paste something like https://circleci.com/blog/deploying-a-serverless-application... and get easy lambda deployments in about 10 minutes.


I think the far better consideration is picking the tech stack that requires learning the least amount of new skills.


The lb, 2 web and 3 api frontends?

You'd also see that 7 of his 8 worker boxes are almost at 100%.


This is where I'd put a 10x developer :) Complete competency across the whole stack with a solid understanding of a profitable operation.


Yep, learning how to run your own business is the only way to convert 10x development aptitude to a 5-10x pay increase. Otherwise you get 1x pay, 10x the expectations, upset colleagues that feel inferior in comparison, and very little promotion chance because the company needs you right where you are.


running many different systems is not development


PostgreSQL, Redis, RabbitMQ, Elasticsearch, Django/Python3, uWSGI, Celery, Celery Beat, Supervisord, Amazon S3, CloudFront, React, Ansible, Datadog, Rollbar, Slack, Vagrant, VirtualBox, PyCharm, iTerm2, Notion, G Suite, MailChimp, Amazon SES, Gusto, Upwork, Goodle Ads Manager, Carbon Ads, BuySellAds, Cloudfare, Zapier, Trello, Godaddy, Namecheap, Stripe, Google speech-to-text, Kaiser Permanente, Stripe Atlas, Clerky, Quickbooks, 1password, Brex.

Alright. Just make a "boring" website now, it's "easy".

If it's one thing i really dislike within both the scientific and the technological sphere it's this arrogance disguised as common knowledge. Because it's not. Articles like this is nothing but bragging. The author, whoever it is, clearly has a very long time working in the field acquiring this knowledge. Be humble.


To be fair, half of the used services do not have anything to do with the website itself but with the whole business around it. Also, most of the tools do not require a PhD in computer science; neither Rollbar nor Cloudflare are actually hard to set up. Still, you have a valid point. The setup described here is not boring at all and not easy, I expected a one-root-server-for-everything that runs some PHP and MySQL.


anyone can build a house from scratch! just read the instruction manuals for brick-laying, carpentry, electricals and plumbing. After all, none of these require a PhD.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: