Pretty nice, 1 dev 3 team members in total and 1 million users? Are there any other products with such a small team and a huge userbase?
Does this scale and when the business requires more coding and technical debt comes how do they manage it?
Does this scale and when the business requires more coding and technical debt comes how do they manage it?
Stardew Valley sold over 30m copies on a solo dev's work. I think you'd be surprised
I'm building my own product right now and never have I wished I had more technical help. It's all the other junk like sales, marketing, distribution, that makes the business so hard. Marketing and sales, in isolation, I've had success with in prior jobs. I'm a fairly productive solo developer.
However, being able to context switch and do both dev and marketing? Now that's hard. I have beyond massive respect for anyone that's even attempted it, let alone been successful doing it.
Nobody sees the extensive graveyard of massive time sink projects that got no traction and went nowhere. Even if they would have been big had they caught on.
Of course everybody sees that, and many can't stop thinking about those things when working on their own project, trying to fight the demons that say "This is a huge waste of time" and so on.
But what is the point of bringing that up when someone explicitly asks for examples of small teams with big success?
The point here is to explain how much of a risk these small teams are making.
So that is the relevance of the example. It shows how much more difficult and risky these successes are, by pointing out that even if someone puts in a lot of work, it is actually more impressive because of the large risk.
This is relevant because the sub thread/topic was this:
"Now that's hard. I have beyond massive respect for anyone that's even attempted it, let alone been successful doing it."
Therefore, bringing up failures or the fact that there is large risk, supports this point that someone else brought up, which is that it is both hard and deserving of "massive respect".
So that is why someone would bring it up and why it is definitely relevant and correct to bring it up, in response to this point.
OTOH there are lots of little indie games… I mean, how are we going to count attempts, right? As an obviously not to be included extreme case, lots of games come out with a map editor, in some sense playing around with a map editor is “making a game.” But we wouldn’t want to include all the custom Warcraft 3 maps that were made as failed businesses, haha.
[1] https://community.playstarbound.com/threads/game-development...
Iterating on all the things that make the game fun is hard, and making all the ”content” in a game like Stardew Valley is very time consuming.
But a 2D engine that should only support exactly what the features need from Stardew Valley? Doesn't seem insurmountable, although I wouldn't exactly take that approach myself.
It’s not if you just write the code you need for your game.
99% of people getting stuck on it have no real desire to make an actual game.
Iterating on the game content itself: _Insane_ amounts of effort, in my experience.
Otherwise it's a hobby, and enjoying your hobby 10 hours a day, 7 days a week is an envious life, if you can afford it. (Barone specifically could not; he had to have a part-time job as an usher in a theater; that was work.)
It is trivial to come up with activities that can consume a lot of time, but don't provide financial rewards.
Game dev is an arduous and draining process that both requires the patience to go through periods of dreary work where no progress seems to be made and yet the creative spirit to devise art, concepts, mechanics, rules, etc. If I had the time, I could easily see myself spending multiple years on a project like that without the need to see any financial reward. I wouldn't see it as work, I would see it as Work with a capital W. A hobby that requires a lot of personal effort but something I do because purely for the joy of doing it.
It's only work if you tolerate it for the reward on the payday.
All of these can be hard work, All of these can be taxing, all of these can be intrinsically fun and rewarding.
I wish people would stop conflating work with just employment.
There wasn't a "minimum viable product" launched in year 1 followed by finishing the product in year 4.
I've literally seen a post here where someone scolded a failed game developer for finishing their financial failure of a game before launch. The comment was something along the lines of:
"Read a business book. You shouldn't have spent a lot of time making your game. Instead you should have released a minimum viable product after doing market research."
Barone is still a beast, just making sure the "one guy did the whole thing" thing has some nuance.
My game Nebulous was 1.5 devs (one full time one part time) and multiple millions of MAU. 9.5 years later it's still going well.
> when the business requires more coding and technical debt comes how do they manage it
Delete bad code. Replace with good code. Sounds simple enough but in my experience at mega and mid corps, step 1 is almost never done. Whether that's because of ego or chasing local optima I'm not sure - probably a mix of both.
Generally this is not tractable because it cannot scale. But there are certain applications where it scales fine.
It is hubris to think that every problem admits the same solution, namely, throw as many devs as we can at it and hope for the best. But business isn't really known for being reflective.
The real question here is scale in terms of what? Because a lot of folks are out here trying to scale people/careers, not software.
It's extremely noticeable at BigCorps. Why do we need to scale this project from 3 -> 30 -> 300 developers? Because that's the number of reports to promo from Manager I -> Manager II -> Director
I only leave it commented out because it has a reason (they all say that, right?).
I suppose the best way would be to provide a meaningful comment "This is the place where 15 lines of coded finally found their resting place, deleted after the bug they solved was eliminated elsewhere".
But in reality, I've never seen a single of the "we could find it it in git" ever actually find it in git.
I say “sane” because I know a lot of places probably allow you to do it. You really don’t want to pollute a code base like that though.
Only if you already know it is there. There is like... zero history discoverability built in the git. and git's historical search story is pretty bad too.
I'm not suggesting that one should comment out code but I never understood why if they have version control and there is a new bug a significant amount of devs do not actually go through the history to find the working version.
Now - after writing the above and thinking while writing, I am going to suggest scenarios when you want to comment out code.
You write a great bit of code that does not work, you find out it is because API X is not correctly implemented, therefore you have to do a workaround kludge until API X is correctly implemented.
What do you do? I think the optimal solution there would be to comment out the great bit of code above the workaround kludge with a comment - API X has a bug, I have made a bug report out on the API X working group. I suggest checking periodically and then getting rid of the kludge and moving this code in. Dated, so that people can see when they should check.
It's true I have seldom had the pleasure of working with people where this optimal way of doing it would have been at all useful, but it has happened maybe twice over many years. Probably it will only help you out when you see the comment over the coming months, or when you get an email that your bug has been fixed.
I'm sure you can imagine other similar scenarios in which commenting out the code makes more sense than using version control.
Nothing. Except that in 3 years the junior dev that gets a ticket about doing something in this area will come in and not notice the code isn't a dumpster fire. Or, in 3 years, you won't notice that you didn't have to optimize this code a year ago.
What they do notice is that you were insisting on working on some mumbo jumbo and ok good they're done now they can actually work on something useful. Haha aren't these devs quirky? Sometimes they take a few days and work on something weird, and all the other senior devs nod and salute solemnly and I'm too scared to ask for more details, but they don't usually take too long so let's just indulge them for a few days to keep them happy so they don't leave too.
It takes a very, very deeply engineering-first org to really cultivate this intentionally. And similarly it seems like succeeding as a startup requires at least a decent amount of shipping some shit code fast so you get a series B, so usually you don't start in this posture and never shift into it before it's far too late.
And also unfortunately, devs often _do_ spend time optimizing/refactoring personal pet peeves as opposed to things that might have a good chance of mattering. I once saw another senior dev spend a week optimizing string allocations on our hot path. Our owner loves people who can do this kind of stuff, so it got a lot of praise. The microbenchmarks looked great, pretty graphs. Users noticed nothing, the actual metrics we track literally did not change, and now the already-complicated hot path is decorated with some contorted string-allocation-avoiding warts here and there and the next person to go in and change the code is _definitely_ going to keep doing that pattern, for sure. Meanwhile our oauth flow is still a tortured, unloved, twisted writhing mass of pain and suffering that prints bug reports like CVS receipts.
So... extraordinarily difficult to intentionally cultivate a culture that does this judiciously.
Wow, this line is a keeper. This whole comment is so insightful. Reminds me of how awesome HN can be sometimes.
I have worked with many people that spend days replacing good code with bad code because they are ”paying down technical debt”.
Then someone proposes a solution for the problem, and you review the code to see that it solves the problem. If the solution is not bad and the problem is big, you can let them merge it.
Some would say it’s the other teams fault for not adding a cross-test against my teams code. And while that would have solved it, some things are hard to test. Even in companies who have good testing standards some things are still hard-to-impossible to test. In my humble opinion tests are great if and only if they are hermetic and fast. Unfortunately, the important things that can go wrong are usually the least testable.
In either case, in a non-perfect world (ie ~all large companies and most small ones) people optimize for not breaking things, and there’s a solid argument for that being a local optima, both for short term stability and career wise.
Integration tests are hard. A lot of time it's because deployment is very seat of the pants. Even with tightly managed deployment the test environment needs to be representative of the production environment. Just setting that up is time consuming and expensive. Then actually doing tests where the test environment has useful amounts of instrumentation without major performance or behavioral penalties.
You have to be good at your job, good at the specialty, and more interested in doing the right thing for the company (and more irritated at the stupidity of the files being there 10 years after they were needed) than you are at looking productive to management. Management does not want to hear “well there was a directory structure of two million files that was a backup of a Linux machine from 8 years ago, I spent two days extracting the dozen files that we might need some day, getting the okay to proceed, and deleting the files.”
Your points are valid but there's also the issue that the more developers you have the more communication overhead there is, which makes large changes to the codebase hard/impossible.
With a handful of devs you can jump on a call, brainstorm for an hour or two and come to a mutual agreement, then one can submit a several-thousand-line PR refactoring the whole thing and nobody would bat an eye.
This kind of coordination is impossible in larger teams, if anything just because everyone is busy and can't afford to spend a couple hours brainstorming + subsequently get acquainted with the new code, but also because the more people the more opinions and mismatched incentives (bad or overly complex code might imply busywork which some people thrive on, so refactoring it to no longer require said busywork is a downside in their eyes).
And that's the real reason service architecture took off
https://highscalability.com/plentyoffish-architecture/
"POF has one single employee: the founder and CEO Markus Frind. Makes up to $10 million a year on Google ads working only two hours a day. 30+ Million Hits a Day"
Needless to say, there's a far more popular local alternative that basically every person in Croatia knows about (njuskalo.hr).
In Denmark the place to go is dba.dk or facebook marketplace.
Checking the portugese version - its 3 items in Lisbon.
And it has a founder who gives away most of his money instead of joining the monetize-everything-billionaire-$$hole club
(No affiliation with Craigslist; just like Craig's story, much like I do Nadia's).
That's too broad, the hope is you're borrowing from a point in the future when you're able to pay the debt. If you borrow too much, or from a point too close to the present - though it's hard detangle those 2, then you may fail to scale at a critical time such as positive press attention or going viral, because you're paying down tech debt. From the article: if it had taken 6 months to fix their importer instead of the 2 weeks it did, the product may have died.
At least a big part of their success was containing technical by avoiding product debt. They had a clear vision and very tight control of their product which is different from 99% of startups. They were experimenting but not throwing any crap at the wall which was never cleaned up or iterated on.
There was a very strong product-engineering connection and alignment which is unusual. Misalignment there is the genesis of much tech debt. Many product features are thrown out with little iteration to get them right but use "shipping so we can iterate" as an excuse to throw them out to users.
The game sold over 30 million copies and had an all time high of over 230K concurrent players at one point earlier this year.
Certainly there aren’t 140M MAU fore the steam deck or any of the games they’ve built themselves, that’s for sure.
Used cloudflare and a $20 cloud instance to run it. Also relied on certain other CDNs.
Don’t own it anymore, but considering starting a new project.
But that's not a VC product market.
Not sure how big it was before Notch hired anyone else, but this reddit post encouraging him to hire somebody says he'd "brought in $67,903,100.72"
https://www.reddit.com/r/Minecraft/comments/kbiuv/notch_youv...
Which maybe goes some way to your second question, as they were slightly and slowly scaled up versions of solo serving 1M. (And obviously have continued that under FB/Meta with probably now a much less impressive/unusual staff:user ratio.)
- You don't take VC money
- You are okay with it not becoming a billion dollar unicorn
- You are okay with occasional downtime (this isn't being deployed in a hospital emergency room after all)
- You don't plan to feature bloat it
- You are okay with it living its life and eventually being out-competed
I had a webapp once with 250K monthly active users for several years (Fooplot). I was the sole developer. It eventually got increasingly out-competed by VC-funded Desmos and eventually got involuntarily shutdown when AWS decided to stop supporting EC2 classic instances. But I just let it be. Its ad revenue made me a good amount of side income when I was a PhD student. It had frequent downtime when people would try to export an overly complicated graph, which would crash the server. I just restarted it when I noticed. Sometimes it would be a few days later. It died eventually when AWS terminated it. I moved onto other things.
Yeah, I wasn't the best maintainer, but the ~$30K I made from its ad revenue over the years was a pretty good payout for about 10 hours of work.
Tech debt doesn't come because the business requires more coding. It comes from poor planning and rushed implementation, often spurred by overzealous and naive management.
This is a small team with one dev, so they likely do things correctly from the start and don't acquire much if any technical debt. Nothing has to be done yesterday, ever.
If the project is well thought out in advance a single developer is enough and will do perfect code
You can't plan for a pivot because it's a known unknown. The same way you can't plan for a specific financial event in the market but you can brace yourself for a category of scenarios. Even with that, you can't predict the impact or the appropriate response your business needs to take.
In the same way so is the pivot. The nature of the pivot is the market revealing the debt you didn't know you had. The magnitude of that readjustment to the market, in the time it has to happen and the time to the next pivot is unknowable because it's information not present at design time.
Tons of FOSS projects.
See the entire JiaTan fiasco.
Notice (Dec 13): code cleanup continues; please keep reporting bugs to support@pinboard.in
The very biggest have decent sized teams (like Mr Beast), but there are plenty in the 100s of thousands/low millions of subscribers/followers range that are operated by between 1-4 people.
And yeah, games too. Quite a few big indie games have that sort of team size/setup.
> Pretty nice, 1 dev 3 team members in total and 1 million users?
So probably pretty close when they originally started their venture.