1,860 karma · joined August 31, 2014
Email: wenbin@listennotes.com
But as an entrepreneur, I think subscription revenue is a good business model to support the ongoing development of a business.
To find a balance, I don't think it's necessary to make monthly subscription a default option. Daily or even hourly subscription could also work - https://www.listennotes.com/blog/instead-of-monthly-billing-...
I'd say that indie hackers don't need to feel pressured to build in public. You have the freedom to share or not share anything. It's your work. If you don't feel comfortable sharing too much, it's totally okay. People might blame you not open source your entire project. People might blame you for not sharing your personal income. Ignore them. Be yourself.
1. 5-hour work day, not pretending busy work for 8 or even 12 full hours (eg, 996 in China tech corps)
Knowledge work, especially creative work, is just different from hard manual labor. More work hours won’t necessarily produce more value
For some people / jobs, maybe 2-hour work day is enough.
@tobi says it well [1]: "For creative work, you can't cheat. My believe is that there are 5 creative hours in everyone's day. All I ask of people at Shopify is that 4 of those are channeled into the company."
2. One or multiple part-time jobs
For some part-time jobs, you work for money; for others, you work for fun/impact.
See how @gumroad works [2]: No Meetings, No Deadlines, No Full-Time Employees
3. Streaming income in real time, rather than bulk income once or twice per month
You have a stream of small incomes 24/7. Some are passive incomes, while others are active incomes. You get paid directly from customers you serve, not from a proxy (eg HR in big corp). Anytime during the day, you know how much you’ve made so far
---
[0] https://twitter.com/wenbinf/status/1472356359953809409
> Born in 1955, Zhang could not attend school and taught himself mathematics at the age of 11. He worked in the fields and factories for several years to make his way to Peking University, where he earned his master's degree in 1984.
> Zhang then moved to the U.S. to get a Ph.D. in mathematics from Purdue University. Failing to get himself a job, Zhang then worked as an accountant, a restaurant manager, and even a food delivery person before getting a position to teach pre-algebra and calculus at the University of New Hampshire in 1999, the SCMP report said.
> In 2013, Zhang shocked the world with his twin prime conjecture, which proposed that there were an infinite pair of prime numbers that differed by two. Prior to this, Zhang had achieved only one publication.
29 year old (1984) - Got master degree.
44 year old (1999) - Got first academic job.
So each employee generates ~$320k annual revenue ($2.4B / 7,400), which sounds about right.
SaaS companies typically do low $100,000s per employee per year.
[1] https://www.docusign.com/press-releases/docusign-announces-f...
A few days ago, I tried Stable Diffusion code and was not able to get it work :( Then I gave up...
Today, following steps in this blog post, it works for the very first try. Happy!
Our Podcast API product [2] uses RunKit to provide "run node.js code right on our API docs web page". RunKit has been acquired by Stripe. It's unlikely that they'll support more languages.
It would be great to let our api users try out all api endpoints using all different languages right on our web page.
* "I can build this over a weekend." - when someone posts their own project here
* "I don't understand why they need to hire so many people" - when learning that a tiny app (e.g., Twitter, Uber) has thousands employees.
The author, Ray Huang, got his bachelor’s degree in USA at age 36.
The way I listen to podcasts is similar to how I consume web contents:
Search by topics/people, and Find podcast episodes to listen, then move on, not subscribing to podcasts. Search by topics/people, and Find web pages to read, then move on, not bookmarking websites.
For podcast recommendations, I’d suggest focusing on topics/people that you’d like to learn more. You can search and find individual episodes [2]. At this moment, there are at least 140,000,000 podcast episodes [3] - vs there were 25,000,000 web pages indexed by google in 1998 [4]
[1] https://www.listennotes.com/playlists/wenbin-fangs-podcast-p...
[2] https://www.listennotes.com/
But in reality, most engineering time in the world is spent doing maintenance work or incremental improvements. This is the nature of building intangible digital products - it's not like tangible products (e.g., building a house), there's not a clear finished line. It's hard to declare a software product as "done". There'll be a lot of ongoing bug fixes, incremental improvements...
In other words, most engineers in the world are doing things that are not hacker news/techcrunch-worthy.
To stay intellectually curious, I think you can try to build side projects while learning new technologies. But I think it's also okay to treat your day job like ... a day job, just like other professions. No need to feel guilty for not using new tech or doing exciting things. You are bring in paychecks to support your family, and this is a great accomplishment already.
Many people/companies create fake podcasts and submit to all podcast directories / apps. The main purpose is to do blackhat SEO - links in the rss feed will be syndicated to podcast directory sites / apps.
In fact, any "directory of something" sites will be gamed if user created contents are allowed, e.g., directory of movies / podcasts / local businesses / books...
1) The boring technology behind a one-person Internet company (2018) - https://news.ycombinator.com/item?id=20985875 (Not posted by myself :)
2) Podcast API - https://news.ycombinator.com/item?id=25139833
I've been on Hacker News for over a decade. It's hacker news that made me decide to go down the join-a-startup path & later the start-my-own-company path, rather than the work-for-FAANG path (like what most of my graduate school classmates did back in 2010~2012).
I was inspired by posts like https://news.ycombinator.com/item?id=8863
I've been following Gergely's journey for quite a while. Personally I learn a ton from Gergely's writings / tweets.
As a fellow one-person business [1], the only thing I'd like to add here (after running my business for ~5 years so far) is that you are allowed to be flexible.
Businesses are different. Everyone's background / finance / skills are different. It's okay that you are doing something different from what you've read from the Internet.
For example, it's totally okay to do (or not do) micro-services for your little SaaS on the get go. It's also okay to try venture-backed route for a while then switch to do "lifestyle business". It's also okay to hire (or not hire) employees early. There's not one single formula that works for every one-person business.
Persistence really pays off long term. Good things might not happen until year 5.
[1] https://www.listennotes.com/blog/the-boring-technology-behin...
In the purest form of "indie hacker" (i.e., a single person team + use your own saving + maybe part-time outside day job), % of $100k+/yr revenue is way lower than 5%.
How do you do search result ranking? Any signals that you use to decide “this is a high quality video from reputable channel and it’s relevant”? I would imagine # of followers / likes / comments / like-comment ratio or the likes are used?
You learn programming language to talk to computer
Our database is less than 1TB. One master (for writes + some reads) + multiple slaves (read-only).
Here's what we did -
1, Launched a new read-only db with pg9.6, let's call it DB_A.
2, Stopped all offline tasks, and only maintained a minimal fleet of online servers (e.g., web, api...).
3, Changed all db hosts (no matter master or slave) in /etc/hosts on the minimal fleet of online servers (e.g., web, api...) to use old read-only db with pg9.6, let's call it DB_B. From this point on, all write ops should fail.
4, Ran pg_upgrade (with --link) on DB_A to upgrade to pg11, and promoted it to be a master db.
5, Changed /etc/hosts on the minimal fleet of online servers (e.g., web, api...) to use DB_A for all db hosts. By this point, DB_A is a master db. And write ops should be good now.
6, Changed /etc/hosts for all other servers and brought back all services.
Step 4 is the most critical. If it fails or runs too long (e.g., more than 10 minutes), then we had to rollback by changing /etc/hosts on those online servers.
We carefully rehearsed these steps for an entire week, and timed each step. By the time we did it on production, we knew how many seconds/minutes each step would take. And we tried to automate as many things as possible in bash scripts.
Hosted on Github pages. A single html file.
Today, it’s totally possible for a single person or a small team to build a domain specific search engine that indexes 10s or even 100s of million documents.
Building the index v0.1 that kind of working is not hard. But maintaining the index to handle countless edge cases is tedious and need non-stop investment (eg, infrastructure + paying salary for talents)
Also, a search engine is more than “keyword matching”. You need to do search result ranking. And it gets exponentially difficult to do as # of indexed documents increases.
1. Daily subscription and auto-cancel. For example, you can subscribe for 3 days, then it'll automatically cancel your subscription after 3 days.
In Gitlab's case, they would enable hackathon teams to use paid plans for 3 days without overpaying for an entire month.
2. Customers can toggle specific features for very fine-grained pricing.
Essentially, it's to make SaaS pricing more on-demand.
If you can figure out a way to be able to control your time as much as possible, you’ll likely be happy.
What people really want is not infinite amount of money. It’s actually ~100% control of their own time .
People may exploit paid services by creating many new accounts -
1. Free trials: When trail period ends, create a new account.
2. Services with metered billing: Use the service, then refuse to pay. Then create a new account. Then refuse to pay. Then create a new account...
Of course, (theoretically) if the service provider has enough resources (i.e., money, time, knowledge...), they can always find a better solution than banning all disposable emails.
Typically, online service provider may have empathy towards users with whatever emails, including disposable emails for privacy reasons. Then the online service becomes popular, and spams / scraping activities become out of control - Internet is big and there are a lot of bad people / bots. Try different tactics to fight bad users / bots. Eventually, the service provider joins the dark side and bans the use of all disposable emails. It's not ideal. If you are Google or Amazon, maybe you can trivially allocate 20 full time engineers to develop an elegant solution. For small businesses, you just use very limited resources and do whatever to survive.
[1] I run listennotes.com
Recent years, I have a feeling that HN commenters would assume server cost should always approach $0, not matter how big, or how different a real world online service is different from their single page web app side project :)
For any server cost sharing posts, we’ll see people making comments like “I can run this under $10/month” . Ha
In an ideal world, you build a thing, and it's done. It runs automatically and prints out money.
In reality, you still need human labors to do manual tasks, even in tech industry.
[1] https://www.searchenginejournal.com/google-eat/quality-rater...