I am super inspired by Pieter. At the same time, I'm also not a believer of a one size fits all approach. A lot of Pieter's work these days is built around remote working communities. His first ideas when he was doing 12 months, 12 startups were very singular in focus. Nothing wrong with that at all. At the same time, Pieter's approach has not been used across a broad range of products in terms of product complexity.
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.
i mean, facebook started as a very light php app and then they just built layer upon layer upon layer on top of it until they basically now have their own fork of php.
To my knowledge Facebook doesn't use any PHP since years. (Hack is not a "PHP fork").
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.
Well-deserved in my opinion. His no-nonsense and unpretentious way of building products, often out in the open, should be a source of motivation for others who can come up with a dozen reasons why they shouldn't attempt to do X. His blog-posts and Tweets are not hustle-porn but just straight-up "works for me, I honestly don't care what you say". A quote that I recently read applies to him very much: "Pessimists sound smart, optimists make money". Pieter doesn't try to sound smart, after all what could possibly sound smarter than making this amount of revenue as a solo founder.
Yeah a lot of people get stuck in the loop of worrying whether they're using the right framework or programming patterns or whether their blog will scale to 1 million daily hits. They rarely ship anything.
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.
I am a solo founder and I recently saw the post of solo founder persistence, which I am yet to read in full. Pieter is one of those that can consistently deliver. He has been doing that for years now. I admire him and what he does, yet I know I can not. I am plagued by mental, emotional issues that break my routine every few months. I started focusing on perseverance and I am happy with where I am now. There is still a long way to go for me and Pieter will stay an inspiration.
Hey :) you should see my brain and discover what I'm plagued by! I struggle with moderate anxiety and depression on and off too and esp this year has been quite hard.
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.
Pieter, I do not know how to thank you enough for this. Last few weeks have been a disaster, cluelessness creeping in and I hit the bottom again. Thankfully I have YC Build Sprint so I forced myself somehow to ignore everything that is not working in my life and focus on what is working.
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.
Hang in there! Take life one step at a time. Everyone is dealing with their own challenges all the time. You can do the ting! And if you ever need someone to listen, send me a message on Twitter
I know this doesn't help you a single bit wrt depression, but anyway: I'm sure I'm not the only entrepreneur you're an inspiration for. I have a tendency to overengineer things, and I find that thinking "what would Pieter Levels do?" helps me get my feet back on the ground :-)
Godspeed and I hope that someday you'll grow over the worst parts of those mental issues.
Well done for persisting and releasing your projects! I have plenty of ideas too, I usually only get around to writing them up when I'm applying for jobs. My Show HN front-ends are functional but plain; I'm impressed that you made Nomadlist look so pretty!
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.
Oh for sure, yes. Simply "doing stuff" helps, and the novelty of traveling and experiencing new places is very exciting. The challenge is that it's like a drug, and it stops working if you keep traveling because your dopamine receptors get usd to it and then you feel the same, so it's not really a long term fix. You see that with nomads especially:
1) go nomad
2) omg life's amazing
3) yeah
4) oh shit why am i depressed?!!!
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.
Not a founder or anything like that myself, just someone with a lot of work to do who had depression in the past. I agree that consistently working out helps a lot as well as giving yourself tasks to do. You can use the good times to try to find a higher purpose for yourself, that's in my experience the best long term solution.
> I admire him and what he does, yet I know I can not.
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.
Sometimes I think it's fascinating the rabbit holes we'll go down, when ultimately, the user just doesn't care.
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?
Yeah that is what it boils down to often; the user doesn't care. It's more about what's best for the developer.
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.
Another factor here is employability. Employers go with the latest fad framework because they think it'll improve their ability to hire engineers in the short term. Unfortunately, this means that web developers need to always know the latest fad framework, whether they like it or not, or they won't get interviews let alone job offers.
> Sometimes I think it's fascinating the rabbit holes we'll go down, when ultimately, the user just doesn't care.
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.
> Where's the line though? When is gumroad or squarespace not the answer?
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.
Hey this is really helpful thanks, very interesting to know you would've built your own platform.
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.
I'm making massive assumptions and generalizations here, but, a lot of developers are pretty introverted and really dislike being in the spotlights, whereas instagram people are the opposite. Without trying to make the term sound negative (it's a personality trait IMO, not a value judgment), it's a narcissistic trait that not everyone has.
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.
Conversely working for FAANG or even just a generic corporate job can land you in a position where you can be comfortably mediocre. Are those people failures too?
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.
These are fair points, and you are very likely correct about the ratio of success to failure. Survival bias is strong on HN.
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.
And it's a very tenuous dream at that, I'd say. It requires constant handholding, upkeep, juggling, whatever you want to call it, to manage all of the visas, plane tickets, bookings, finding remote work, finding a network of people for which reason you allegedly moved to the country :)
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 am going to take the opposing side of HN's groupthink and tell why I don't like that this guy is celebrated as a hero.
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.
I don't think it's at all surprising that there is no relation between tech stack and business success. End-users don't care if you use a single PHP file or a Go binary, they never get to see that anyway. So I don't really see "it was all a single PHP file" as a gotcha. The whole thing could've been coded in Assembly, the difference is in the effort required for development, ease of maintenance/scaling up and how well-guarded you are against vulnerabilities.
Yes and no. The tech doesn't matter but that is The Point. That is, your tech won't save bad product. Using the latest cool kids framework or buzzwordy tool won't save bad product.
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.
Arguably Pieter might be at this point already and he doesn’t care. With the right tech and more people he could scale some of his businesses further but he deliberately doesn’t want that as its diminished returns for him, personally.
Right on. With complexity also comes responsibility and commitment. Sometimes less is more. It might not be sexy. It might not win awards. But that can mean less stress and less risk.
If there is one thing I've learned in this business it is that when your tech stack becomes an "issue" for your business success, you've probably "made it" success-wise.
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.
If you don't get why the fact a high successful venture is using such a barebones tech stack is not noteworthy, you must be following a different tech industry than I am
I mostly follow HN, a successful tech forum that is written in a single lisp file and runs on a single server. It’s not surprising to find successful projects run with a simple stack. The opposite is more surprising.
Any application can be said to be written in a single file if you ignore all of the libraries and just dump everything else into a single file, HN included. That's not a rational measure of simplicity, elegance or efficiency.
What the parent and original post seem to be implying is that simplicity, efficiency, tech stack (or lack there of), isn't what drives success in a business, it is instead the customers paying.
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)
100%. Shameless Plug - In fact, I'm currently building an "inefficient," "micro" web framework specifically so I can build more stuff, more quickly [1].
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).
Interesting but the way you phrased it, doesn’t sell it particularly well - it seems to simply hide the underlying dependency complexity a few layers below. It’s still a node.js app with all the pros and cons of npm etc.
Surprising and noteworthy are not the same thing, but pretending they are definitely lets you make your non-sequitur reply seem like it addresses mine...
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:
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.
The fact that I keep reading posts on HN about how successful HN is makes me wonder how soon will this forum die off, infested by cultist "contrarians", wanna be philosophers and alt right fantasists, in favour of reddit - where most of the times I read either the exact same comments as here on identical posts, or better quality comments with far more evidence and without the usual non sense downvoting of dissent.
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).
> sqLite - This is described as being unsuitable for
> production by it's makers.
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.
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.
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!
SQLite is incredibly ubiquitous and used in BILLIONS of devices and applications around the world.
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'm not sure how those are comparable. Most people don't need extreme HA for their websites. It's totally fine if a standard webshop goes down from 2AM-3AM, or if a personal blog is down for a minute because an S3 VM crashed and needs to be rebooted.
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.
Yes, people should evaluate ha needs in terms of business needs: what happens if my website goes down? Will I lose money? How much money?
"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.
For many websites it's perfectly acceptable to go down for a few hours (or however long it takes you to notice, spin up a new vm/server and restore a backup) should stuff go wrong, which is fairly unlikely if you're just running a few servers.
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
I agree not every website needs high availability... but I wouldn't bet my $600k/yr business on a single VM's availability and reliability. One day, his server is going to die and be replaced by his host, or his disks will need replacing or a RAID array will fry...
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".
Running on a single server does not mean no backups and uptime monitoring is in place. If the hardware fails, you get a ping on the channel of your choice, manually provision a new VM then download the latest sqlite backup from your backup provider. Easy to make a checklist or a script for this, too.
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.
As long as SQLite doesn't catastrophically break under load it's fine for production, but only as long as it has a single client; traditional database engines can deal with multiple applications connecting to them.
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.
Thousands per day, let's be generous and say 9,000 queries per day. In 24h and 3,600s/h that is ~0.1 req/s. Are you saying that SQLite cannot deal with 1 request every ~10 seconds? Or were you referring to 900,000 queries when you said "thousands"?
FWIW the typican front-page article in HN sees around 10-30k visits in a single day.
If I have a simple Flask or Django app, backed by sqlite, how do I make sure I only have one client? If I use a prerolled Apache or Nginx frontend (which may or may not be set up with multiple threads or whatever), and have very very low traffic, how do I make sure I'm not corrupting it with multiple writes?
It's probably fine to leave Apache or Nginx with multiple threads (probably even a good idea) but you need to make sure that uwsgi or whatever Python server you're using on the backend only has one process.
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.
hey, I posted the article. Good to know! I'm sure I had read it somewhere on their site. Maybe it was just from other developers that I got the impression it wasn't meant from production.
SQLite is staggeringly productions ready. I think the trick is to think of it less like a traditional database and more like a file format with an SQL front end.
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 also used to have this impression, I think I got this from Rails and Django docs, maybe you read something similar?
> 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.
The Django docs word it better - the chief problem with SQLite is that it's a _local_ database. If you outgrow a single server, you will now need to also migrate your database to something that can handle multiple external clients, or else figure out another way of making writes on one server be available to read on the other servers.
Having done exactly opposite to what Pieter has done as a solopreneur for many years -
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.
I don't think this has anything to do with tech stack.
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.
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.
I agree - for me, its about continuing to use React/Python/Go/Node for new projects, instead of trying (say) Elixir or Clojure. I'm already much less focused..
My (smaller) 'empire' runs comfortably on 3 VPS servers because I have more media and data IO, but that also totals around 400k. It's amazing what you can do with VPS servers when compared to 15 years ago.
I don’t usually like to toot my own horn, but I make $600k/year off a plain HTML static site that isn’t even coded well, in-line CSS, many pages not responsive, broken links, etc.
I have a site like this as well and it makes about a paltry $40k on a good year. I mostly got lucky because I had some niche domain knowledge for a specific industry that was lacking a web product. I wasted money trying to grow it for some time but I've come to accept even at it's full potential it would probably only make maybe double of what it does now at max. I hope someday though i'll stumble across a $600k a year opportunity.
You wrote in another comment that it is an "information rich" site. Has the absence of a search feature ever been a problem for you? Or did run into any issues that could have been easily solved with something like a WordPress plugin (if the site wasn't static, of course).
I'm asking because these are the things that bug me when it comes to this "static all day, every day" trend.
It was planned as a business from the start. I was running a different site that started as a hobby, and one of the affiliate links was performing well even though it wasn’t highly targeted to the audience. I knew there was a biz opportunity there.
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.
Yes it was really out of place. Same with the No CS Degree job advertisement. It was even more out of place since the main article was about a guy creating job boards, I thought perhaps Pieter had made a new one?
Levels is quite transparent about how to build and monetize communities. I 'd expect he 'll receive a lot of hate if blogs like this make him a posterchild about "making money without a degree". He is talented, which the blog fails to mention, not everyone with or without a CS degree is talented. I also like his opinionated approach of not engagint with haters.
This has nothing to do with Tech and everything to do with his MBA and business knowledge. The way he markets, writes copy and actually builds communities is what is making him a shit ton of money, not the single index.php
I met a guy travelling in South Africa / Namibia in 2013 who had two web businesses (https://www.replacementkeys.co.uk/ and InternetRadio.com). Had No Degree, just self taught / on the job training. He had written most of his stuff in Perl :o! Similar philosophy to this to Pieter Levels!
If you don't know who Pieter Levels is, the title makes it sound like this person makes $600k doing remote coding work on jobs found on Nomad List and Remote OK.
In actuality, he is an MBA who runs these two businesses.
Network effects. The value of a job board is the amount of companies and potential workers that use it. Being tied to his digital nomad community brings in a supply of workers and companies that work remotely.
I have a broken bootstrap template that I've recycled for over half a decade to make landing pages for new products.
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
3.3.4 from 2011, but this was in use for a very long time before the real flurry of upgrades started coming out. I've been using a template since 2014-2015
I did not know if this person until today, very glad for their monetary success.
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.
This is exactly how I learned to code. Started with simple coding projects online then built a personal website now building web apps.
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
Pieter's businesses are impressive, but IMO not using React nowadays is actually harder than using it. Building stuff vanilla takes more time, effort and knowledge.
> not using React nowadays is actually harder than using it
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.
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.
I think GP is referring to digital nomads. Pieter didn't start that for sure, but I can imagine more people took the dive because of Nomad List + Pieter's open and honest sharing about his own digital nomad life.
I haven't visited either site, but I sure hope he doesn't have logins or gather any sensitive user information if he has no CS background, no prior dev experience, and is running entirely on vanilla JS/PHP using no frameworks.
That combo sounds like an ideal recipe for a security nightmare.
It's worth remembering that while his tech stack is low tech stuff, the methods Pieter used to build a community is basically the marketing equivalent of using React, powered by a microservices architecture using multiple languages and feeding data from a sharded database with multiple points of redundancy and cache layers.
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.