Pieter Levels Makes $600k a Year from Nomad List and Remote OK
nocsdegree.com
nocsdegree.com
I'm basically curious which larger products have been made with this kind of relatively ultra-light technological approach and have still succeeded.
I'm particularly curious if there are products that started out as a super simple application and then grew in complexity while maintaining this kind of approach. At what point did it break? Are there examples where it did not break?
Edit - by growing in complexity I mean feature/product complexity while maintaining technical "simplicity".
Or am I thinking about this backwards? If you are a single developer, you use your basic tools, and launch products that are light on complexity where the focus is to ensure it earns money and that's it.
Also I would be very surprised if there is any code left form the early days. FB was (to my knowledge) rebuild "form scratch" several times during it's life-time.
Also I don't think one could build a website with PHP and SQLite and scale this out unmodified to millions of concurrent users for example.
But most websites don't have millions of concurrent users, and it's true that some very "basic" tech is more than enough to server one's users well in the majority of cases.
The horrible amounts of over-engineering one can see "everywhere" are imho a result of two issues: People building stuff and using tech they don't actually need! Most people don't have the problems Google or FB have for example. Still people are running static websites on Kubernetes nowadays, and things like that. (You know, in case you need to quickly scale things out this makes perfect sense, doesn't it? ;-)).
IMHO one of the main points of good engineering is to choose the right tool for the job. This means that in 99% of the cases you're actually perfectly fine with even a "bare metal PHP / MySQL" stack (or similar). Especially if you're just trying get something up the ground.
On the other hand's side a good engineer should know upfront when this won't lead to the desired result. As an engineer you should know all of your tools. The simple day to day ones but also the complex and advanced ones — you need to choose wisely which to use when. If you don't think about all of the possible design space, and all the pros & cons of going some direction, you're otherwise just a guy with a hammer; and not an engineer…
So it makes imho a big difference whether it is an informed choice to use "low tech" or just the result of "I don't know better". No matter the (first) outcome may look quite similar.
In the first case there is a chance that the people that did that will be able to "scale shit out" or add all kinds of features in a clean way. In the second case one can expect that the people that "just had an hammer" will create in the future the usual "layers and layers of mess" all over the place when tasked to extend or scale their system, as they just don't know better.
As a bottom line: Software engineering is hard, very hard. To arrive at a simple but correct solution is almost an art and requires the most skilled and knowledgeable engineers money can buy. It was a genius btw who insisted on things being as simple as possible, but not simpler. Coming up with "a simple solution" (ignoring half of the problem) or "killing flies with Bazookas" is trivial, everybody can do that. But that's not proper engineering, imho.
If you never put your work out there, you'll never be successful, so the key is to stop messing around and just build. If it's shit, it's shit, no one can see the code, if you want to rewrite it then ship it and do it after.
The quicker it's out there, the better it is for you, and it's also incredibly motivating to get feedback ASAP without guessing what people might want from your product.
Work is quite therapeutical for me because it keeps me creative, active and have goals. It keeps me on the rails really. Daily creative stuff to work on. My dad does the same as he's always renovating the house, doing woodworking, or studying film history. Just tasks to do.
Even if those tasks feeling meaningless and motivation drops (eg symptoms of sneaking up depression, especially during this crazy year), getting one task done usually helps to alleviate that and get back into it. That and a supportive girlfriend, working out a lot and trying to eat healthy.
I think it's much more common especially in entrepreneurship and ambitious pursuits than we think, so the moment I drop the word depression or anxiety people are like "omg are you okay?", but it's just a part of my and many people's existence I think.
So just so you know, while it might look like my brain has it together from afar, it's somewhat of a struggle on and off and will be the rest of my life, and I think for many people. And my work might just be a result of trying to deal with that, instead of an obstacle.
Godspeed and I hope that someday you'll grow over the worst parts of those mental issues.
Have you found that travel helps emotionally? Getting on a Plane is my "Plan E" - most problems don't carry long-distance. Nomadlist makes it easy to compare the things that can be measured about choosing a place to go; CouchSurfing/BeWelcome/Trustroots helped me to find people in those places so I would land on my feet. The hospex community is also just generally very supportive, in my experience. Musician fan clubs too; remote work has allowed me to see many of my favourite bands live.
I guess you saw the map of the Cost of 1 GB of mobile data; any plan to integrate that data into Nomadlist? https://news.ycombinator.com/item?id=24247561
Then again, travel can give you permanent solutions, like you might meet a new partner(s), or people that you will build something new with, etc. Those interactions can change the course of your life and many of us need to move out of our own home bubble to a new place to realize the possibilities that life has to offer, outside of your usual routine.
I do think a creative pursuit (because it's endless) and being around people you love (difficult these days) and working out (lifting weights esp and cardio) and eating healthy (organic, and lots of vegetables) are the most probable ways to feel somewhat satisfied. But it's not like I or anyone else really has it solved I think. And with corona now I'm failing on about half of those things.
P.S. Nomad List was also very very basic and barely functional and it took ~6 years to be somewhat pretty and properly functional and it still has bugs, so it's just a daily iterative process of fixing small things like a button.
Yes depression and anxiety are common in these circles. My work motivates me, I am 37 years old and this is my life, has always given me comfort. I have wet eyes while I write this, thanks, a million times.
- Sumit
Of course you can! I'm like you in that I haven't had a successful project yet, but it'll only happen if we keep trying!
And like Pieter said in his reply to you, pretty much everyone struggles with mental stuff, even him and people like Tim Ferriss. So don't let that hold you back. Acknowledge the hardships and then keep on going.
You can do this!
TypeScript vs. plain JS
Logic-less templates like Mustache vs. Handlebars
Vue vs. React
Using async/await, and adding the relevant infrastructure to support that (transpiler)
Clean code practices in general
Unit tests, end to end tests
CSS BEM vs. tailwind
You can make indirect connections to imply the user does care, e.g. E2E tests catch a bug which meant the user didn't see it, but generally, these things are meaningless to them.
For my first course, I put time into those things - time taken away from making content. The more I think about it for my new course, the more I wonder should I just sell on a platform which already handles all of that, like gumroad.
Where's the line though? When is gumroad or squarespace not the answer?
The problem is that a lot of developers want to work with what is 'sexy' at the moment. That's one factor that also drives e.g. job adverts; most vacancies I've seen will have "cryptocurrency" and "IoT" sprinkled in, just for the sake of looking attractive.
And old applications get rewritten in newer tech because of a combination of technical debt and developers going "I did not write this so I cannot read it and do not want to work with it".
Granted, newer programming languages (or versions thereof) often have better developer ergonomics (I spent my morning trying to get a C codebase to work while with my new Go codebase it should be a matter of installing the Go tools and doing 'go build').
Another factor is the perception of productivity; rebuilding software greenfield will feel super productive for at least the first six months to a year, after which things become more of a slog as the backlog fills with bug reports and change requests, instead of new features.
Source: I've seen this happen a number of times.
Disclaimer: I'm in a rebuild project myself now, the old codebase is nearly 200K of very poorly written PHP / JS, and the Decision was made to rewrite it from scratch. I'm going with Go and React at the moment; Go because it's unsurprising and boring code that should be fine for the next decade, and React because it's a de facto standard now and should be fine for the next 3-5 years as well. Both tools were decided on in part for future developers that will work alongside or to replace me.
But I'm sure in a few years my opinion on what is the best tech stack may change, idk.
All those things you mention don't affect the user's first experience on your site, you're right: you can use plain JS, ignore clean code practices, have no unit tests, and use the frameworks you're most familiar with even though they don't quite fit, and still start a successful service.
However, they all come into play when you start to evolve your website or service. TypeScript makes it easier to refactor your code when it gets complicated. async/await lets you serve more users. Clean code practices lets you onboard more developers easier. Unit tests and end-to-end tests mean you can iterate more quickly without worrying about breaking existing functionality — something users definitely do care about — which makes it something you should care about too, if you want to keep them around.
Gumroad is going to handle payments for you.
You mentioned a course. If you plan to offer video streaming, you'd have to come up with something to provide that platform.
There's places like Teachable and Thinkific for that. That's what I did initially and now years later I want to build my own platform because there's a massive laundry list of things that I don't like about those existing platforms.
But now it's difficult to move an audience from platform A to B because they expect a working and fairly feature rich solution since that's what they are used to. It means the custom solution needs to be shipped as something more than an MVP, which makes it take longer to develop. At the same time, like you said, building the platform takes away from creating the content.
If I could go back in the time I would have built my own platform first while testing the demand with free videos on Youtube.
Fortunately I already have my own platform for my first course, so maybe reusing that would be best rather than assuming the grass is greener, with things like gumroad/teachable.
The success of his business niche doesn't have much to do with tech stack or even programming, but rather Instagram style lifestyle businesses.
People buy into the dream.
Call me square but it's much easier to just overpay for rent in the USA and just focus on building "bulletproof" skills for a long career here.
After all, nobody stands up postgres on EC2 anymore right, we all just use redshift and lambdas? right? ok well maybe not all of us :)
I would add though that "shipping it" greatly increases your odds of success, and choosing a simple stack that lets you ship an idea quickly is a good thing.
I feel like his choice of a super basic tech stack likely contributed to Pieter's success in some way.
I mean I'm working remotely at the moment because of the 'rona and it's not glamorous at all. My desk doesn't look like a generic marketing photo (you know the type, top-down view on a wood grain desk, clean Macbook, steaming cup of coffee, phone, Moleskin notebook, random plant), I don't spend my time lounging and networking (a beer in the back yard at night maybe), I just go upstairs, do my thing for eight hours, etc.
Extroverts and narcissists make software development look a lot sexier, because they have no qualms with putting themselves forward and advertising themselves and their lifestyle.
Me, I hide behind an online moniker and shitpost on HN, often not even looking whether anyone replied to my comments because What If I'm confronted with something.
I'm sure I'd have a much cushier job if I was more extroverted (alongside my current skill level, I'm no genius but I get the job done). Maybe one day I'll go self-employed or work remote for wealthy US companies, idk.
Going solo means you have to get shit done, and you have to pick a viable niche. There's no inertia to rely on, and no safety net.
So the tech stack makes a difference. Because if it takes you months of learning before you can start making a site out of cloud + containers + automation + components you've failed before you started.
Aren't this all successful companies? There is a reason why all big companies spend 100s of millions of dollars in marketing every year.
I haven't checked since a while but a long time ago when I tried to sign up to his site it was a showcase of dark patterns. What I specifically remember is that it sucked in all my data on a sign up form before telling me that I actually have to pay for access. I specifically checked every square inch of the opening site beforehand to see if it's a paid system. But it was filled to the rim with all the other usual dishonest marketing psychology bullshit too.
Usually it's best to avoid anybody who does any business with "digital nomad" in its description. So many hustlers preying on clueless people who are sucked into the promise of easily setting up an online passive income while travelling the world. Coaches, masterminds and paid-for online communities are the worst: newcomers pay access to people who are either essentially in the same shoes as themselves or are only part of the community to make a profit out of it. Obviously the ones who are willing to pay for this (and fall for the above described dark patterns) are the ones who want to get value out of it, not the ones who can provide. Why would any serious "digital nomad" pay to be part of such a community?
Also the original nomad list site was like a distillation of everything that's wrong with the lean startup ideology. The content was not only thin, it actually looked like it was totally made up. Whenever I saw someone link it as some authority on a location I always wondered whether anybody who has ever been to that place had any input on it. But it didn't matter, it was sleek and easy to digest so it took off. And then could be used as a traffic source for the other ventures under the same umbrella.
So the guy is now making half a million a year based on a site spreading completely useless and misleading information and riding the hope of a better life of newb digital nomads. Yes I am bitter that I am not his position. But I am also bitter that this is the kind of business practice that makes money nowadays.
Sure having a modern infrastructure that is able to process thousands of requests per second is better than something that can only do a few hundred, but if you strip out a bunch of excess requests, you will process less per user, and thus reach the same level of scale on a less efficient stack.
The most important part is people paying you money.
Modern startup culture is full of inefficiencies + silly trappings (nice offices, drive to hire people, make things more complex, take more money from investors to stave off figuring out taking money from customers)
An entire app can be build in a single js file (with only one dependency... and it's 150 or so dependencies and sub dependencies).
But to the point specifically, " It’s not surprising to find successful projects run with a simple stack." - you are spot on. The "successful" HN crowd appears to favour overengineering or obscure tools, point which shows 90% are armchair philosophers who daydream of running a business, building a 0 to 1 start-up, and other things office workers imagine when they think building a webapp using GO, or Haskell will result in anything else but a line on a CV for yet another slave away job (potentially an open source project that no one wants too).
Not very representative of the entire real world of development.
It's noteworthy when tech projects are successful and simple, because in the industry there is a widespread tendency to try and replicate what "the big guys" are doing, and often times what they're doing is extremely convoluted.
In other words, it is significant when projects buck this trend, because it goes against the mistaken belief that the only way to be "web scale" to replicate some of the most complicated tech stacks out there, making it worth calling out. Significant being a synonym for noteworthy in case that needs to be clarified...
HN being an example of this doesn't somehow make every other example not noteworthy either if that was what you tried to say?
-
This concept has come up so many times I am, again, surprised anyone who is in the same tech industry as me does not realize it's a thing:
https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb...
https://programmerfriend.com/not-google/
https://link.springer.com/chapter/10.1007%2F978-3-030-31646-...
Especially on Hacker News, a place where an immense amount of gnashing of teeth has happened over what the latest complicated tech stack that people convince themselves they need to make software that scales.
Yes, the business you're in matters. No, it doesn't matter how you build them - as long as it's quickly. If you outgrow you're overly simplistic stack, that is a _great_ problem to have.
So many technical folks lose site of the fact that no matter how many "cool" technologies you deploy out of the gate, it really doesn't matter if the market and customers aren't paying you revenue. Period.
I would doubt that is what the creators of SQlite intend one to take away from their documentation:
"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites). The amount of web traffic that SQLite can handle depends on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
> The SQLite website (https://www.sqlite.org/) uses SQLite > itself, of course, and as of this writing (2015) it handles > about 400K to 500K HTTP requests per day, about 15-20% of > which are dynamic pages touching the database. Dynamic > content uses about 200 SQL statements per webpage. This > setup runs on a single VM that shares a physical server > with 23 others and yet still keeps the load average below > 0.1 most of the time." (Source: https://www.sqlite.org/whentouse.html)
So SQlite is quite a valid choice if you need a database and stay below ~500k HTTP requests per day. So it probably is "production ready" for many a site.
Thanks
> Rails comes with built-in support for SQLite, which is a lightweight serverless database application. While a busy production environment may overload SQLite, it works well for development and testing. Rails defaults to using a SQLite database when creating a new project, but you can always change it later.
> By default, the configuration uses SQLite. If you’re new to databases, or you’re just interested in trying Django, this is the easiest choice. SQLite is included in Python, so you won’t need to install anything else to support your database. When starting your first real project, however, you may want to use a more scalable database like PostgreSQL, to avoid database-switching headaches down the road.
In fact, I would argue SQLite is the most well-tested and production ready database system out there.
Maybe we need an /infamous.html page
From the website [1]
> SQLite is used by literally millions of applications with literally billions and billions of deployments.
It's also worth noting (at least, imo) that it's automated test suite is fantastic. I seems to recall it has considerably more test code than actual library code.
I'm using sqlite for a production application as well, but its load will be in the range of - at best - thousands per day. The only complexity will be that there has to be a secondary 'fallback' server; the current application just copies the whole .db file over to the secondary server after certain events.
If you can somehow architect things so a single process is doing writes (but leave multiple processes doing reads) that's likely even better.
However I would suggest doing a lot of testing. It's possible multiple write processes isn't the end of the world below some threshold.
FWIW the typican front-page article in HN sees around 10-30k visits in a single day.
Also HN: "Database X can fail in Jepsen tests during partitions, it's unusable"
I see HA as a mandatory part of what makes a system production ready...
It's likely the additional overhead worrying about HA is not worth it, not to mention the real possibility of HA just not working properly in actual failure scenarios
It seems like his business could at least afford an HA setup on a cloud provider. Moving to any hosted db with backups, updates and redundancy could be worth it.
As for HA failing, it's still less likely than not-HA failing.
Also an HA setup allows for maintenance and upgrades without downtime, which is way better than the very common "we don't upgrade if it's working, because it could break".
Also there is a third option between HA (with its increased cost and complexity) and "we don't upgrade if it's working, because it could break", which is "take the site down for a few minutes, do the upgrade, bring it back up". It's not for every site, but there's a range of sites for which that is fine.
Most websites are not Google or Amazon, and gain very little from more 9's past the initial 2~3, which is totally manageable on a single server. Why spend thousands setting up and managing distributed servers if going from 99.0% to 99.999% gains you hundreds? If you need more nines and stronger guarantees than that, absolutely, use distributed solutions, nobody is telling you otherwise.
Jepsen tests are valuable once you have decided to use a distributed solution. They showcase problems that would be extremely hard to track down in production settings but can cause serious problems there. If encountered in practice these problems can cause data corruption or other very strange bugs that would take days if not weeks to track down.
I wouldn't say that a system with failures in Jepsen tests is unusable, every system has bugs, but if a system has these problems on purpose (e.g. to make it look better on benchmarks) and there is no movement to fix these problems then I would definitely steer clear of that system.
"How much money?" Is probably the most import question, as it actually helps in evaluating if there's a business case for investing into the financial commitment, engineering effort and maintenance burden of an ha solution.
On a different note, I've seen mysql-based multi-master setups and it's really a joy to be able to treat a mysql crashing as a minor annoyance instead of a call to fire-fighting.
Edit: there is also more to be said about this. I'd research crawl-budget if you're interested.
I recently had Jon Calhoun on as a guest in my Running in Production podcast the other week where he talked about using SQLite to power his video course platform (it's focused on Go development).
He has 15,000+ active users and talks about how SQLlite hasn't been a performance issue. His whole stack is on a $5 / month DO server.
Here's a direct link to the SQLite part: https://runninginproduction.com/podcast/42-creating-a-video-...
I also have another episode coming out next week where SQLite is being used in a custom hardware appliance running on a Raspberry Pi-like device that is shipped to villages in the African Congo to give villagers affordable access to email. I wonder if the creator of SQLite had that use case in mind!
Just because it's not used in web applications as much doesn't mean it's not production ready. It's used in many hardened systems, which I think they'd avoid if it wasn't production ready.
i.e.
• Best Engineering practices set by industry leaders.
• Using state of the art tools, libraries, architectures etc.
• Being paranoid about Technical Debt.
I would say Pieter's strategy is a better if you're a serial-solopreneur. I had a CS degree, so its even hard to think of such a route and I considered my startup to be a long haul but there are valuable lessons to take from no-code/non-CS community; after all they solve problems for their consumers and make money from it.
But, I wish every solopreneur knew and suggests one advise in every interview they give 'Buy a fat health insurance, largest you can afford, take care of your health as when you go down your startup goes down and no amount of automation can save it' and that's what happened with my startup.
React is generally easier to use correctly than plain JavaScript, PostgreSQL is as easy to use as SQLite (and more powerful), Node is as easy to use as PHP (but has more libraries, and you can use TypeScript which makes it easier to write correct code), etc.
The only actually simplifying choice seems to be using a single VPS instead of a Kubernetes-based cluster.
It's far more likely that both the financial success and the tech stack are caused by a pragmatic attitude focusing on the business itself rather than tech details, rather than the tech stack being the cause of the success.
For Pieter its about staying with PHP.
Absolutely disagree. One is incredibly secure out of the box, the other is certainly not, they probably shouldn't even be compared. We can check Shodan if you want some empirical evidence for this.
His entire empire runs on one VPS that costs him just $320 a month.
[0]https://mobile.twitter.com/levelsio/status/11340898562654945...
I will say it’s been online for over a decade, information rich, with affiliate lead generation as the main source of income.
I'm actually quite amazed at most of the Show HN posts with commercial products. Unless you are actually aiming towards developer or software shop dollars the risk/reward seems incredibly off kilter.
I'm asking because these are the things that bug me when it comes to this "static all day, every day" trend.
I would re-think talent. Pieter works hard.
Talent can lead you to think people are born to be successful.
Pieter just works hard. Work beats talent when talent doesn't work hard.
The other story which is very inspiring as well is the Tailwind CSS (https://adamwathan.me/tailwindcss-from-side-project-byproduc...)
In actuality, he is an MBA who runs these two businesses.
No snark, what does having an MBA have to do with running those businesses? Curious why you chose to include that?
What's stopping a proliferation of job boards to arbitrage away his revenue?
It's always funny when junior developers come to support the product and balk at the code.
Yessir, its a one page static website that just got me $1,000,000 in three weeks and your attention and ability to pay you.
Funnier because I used to be that junior developer.
The memes that recognize this are so good and spot on: the pedantic guy with glasses and out of place bowtie complaining about some irrelevant best practice, while money printer go brrrrrrr
However, the technological choices that he makes seem fine for the type of web applications he's building: seemingly simple, one-off projects to which he adds more features as needed.
I don't know if that approach would work on maintaining a large code base in the case of a meatier project that needs to be maintained for the long term. My own experience doing web dev (which is not my specialty) is that HTML,CSS,JS quickly become unmaintainable when you try to scale them without a well though out architecture and some prior experience.
Once again, glad for him!
Although, I do think it is important to learn React now a days. I started teaching myself React a few weeks ago via this same process. Incredibly powerful for web dev
Probably the sort of thing you want over time from your devs. I'm no front-end guru but vanilla.js seems like all that most companies really need to do their job.
Having done more than enough time at $BIGCORP you'd be amazed at how much work is self-created, self-perpetuating and the lengths people will go to protecting that.
I'd even argue a crap employee who documents everything and eats vanilla icecream is probably worth far more than a superstar that builds impenetrable silos to artificially make themselves invaluable while instagramming themselves with boutique gelato.
For a solo dev, the only thing React makes simpler is dealing with JS that has to manipulate a lot of HTML. If your app doesn't do that (IDK if nomadlist does or not), then React is overkill and unnecessary. Even if you want reusable components, for many simple usecases the React lifecycle is complex and unnecessary.
That combo sounds like an ideal recipe for a security nightmare.