Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The boring technology behind a one-person Internet company (2018)

broadcast.listennotes.com

Post reply on HN
Print view View original

81–90 of 464 posts

Re: The boring technology behind a one-person Internet company (2018)

#81

Post by q3k »

eloff wrote: post #43
aantix wrote: post #26

Picking your stack/architecture based on team size is something most engineers miss. Microservices, great for companies with many teams. Not so much when it's three people scrambling to create something meaningful. Monolith all the way.

It's funny because microservices are explicitly targeted at solving problems for development with many teams, and lots of single team companies cargo cult them. Did they miss the first paragraph when they were reading up on what microservices are?

They also solve some other problems:

- different SLA and scaling requirements per component/endpoint

- different security domains per component/endpoint

- different rollout strategies/policies per component/endpoint (no need to restart your long-lived client TCP sessions in parallel to rolling out a business logic fix)

- ...

I've been happily developing and deploying microservices for small customers, in teams of 1 to 10 people. But I also don't work with customers who just need simple CRUD apps.

Re: The boring technology behind a one-person Internet company (2018)

#82

Post by jcroll »

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.

Re: The boring technology behind a one-person Internet company (2018)

#83

Post by endtime »

mtnGoat wrote: post #44
aprdm wrote: post #10

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…

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, un…

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.

Re: The boring technology behind a one-person Internet company (2018)

#85

Post by yjftsjthsd-h »

zrail wrote: post #71
non-entity wrote: post #63

Earlier quoted context omitted.

> 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.

Re: The boring technology behind a one-person Internet company (2018)

#86

Post by jedberg »

I'm impressed with the profit margins. It looks like one of the main sources of revenue is transcription. From what I can tell the price seems to be about $4/hr.

OP said they are AWS. If they're using Amazon Transcribe, the cost for that is $1.44/hr.

A 150%+ profit margin is awesome! Well for that one piece of the service. Obviously at least some of the cost of the website and database, etc must be included, but still. Pretty amazing.

Re: The boring technology behind a one-person Internet company (2018)

#88

Post by grepfru_it »

aprdm wrote: post #10

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…

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 :)

Re: The boring technology behind a one-person Internet company (2018)

#90

Post by cutler »

zrail wrote: post #71
non-entity wrote: post #63

Earlier quoted context omitted.

> 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.

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.
Post reply on HN