As someone still in school, this type of article -- though inspiring-- kind of scares me, to be honest. I don't think I could do any one of the things mentioned in this article.
The boring technology behind a one-person Internet company (2018)
21–30 of 464 posts
Re: The boring technology behind a one-person Internet company (2018)
#22Re: The boring technology behind a one-person Internet company (2018)
#23Re: The boring technology behind a one-person Internet company (2018)
#24One question: what all do you use contractors for? How has your experience been in managing them?
Thanks
Re: The boring technology behind a one-person Internet company (2018)
#25Re: The boring technology behind a one-person Internet company (2018)
#26Microservices, great for companies with many teams. Not so much when it's three people scrambling to create something meaningful. Monolith all the way.
Re: The boring technology behind a one-person Internet company (2018)
#27To all the people thinking “I couldn’t possibly do this myself” just look at the mention of UpWork towards the bottom. Looks like the author has brought in contractor help at some point.
Re: The boring technology behind a one-person Internet company (2018)
#28Re: The boring technology behind a one-person Internet company (2018)
#29As someone still in school, this type of article -- though inspiring-- kind of scares me, to be honest. I don't think I could do any one of the things mentioned in this article.
Do you understand what the web, api, and DB servers are doing?
If your interested in Python and want to start small I can recommend Flask. Flask is smaller and could be more user friendly than Django.
Here’s a great tutorial. You’ll build a blog with Bootstrap, Python, Flask and SQLAlchemy.[1]
[1]https://www.youtube.com/playlist?list=PL-osiE80TeTs4UjLw5MM6...
Re: The boring technology behind a one-person Internet company (2018)
#30One 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.