Getting to 2M users as a one woman dev team [video]
brightonruby.com
brightonruby.com
Here’s a recent one https://m.youtube.com/watch?v=pOW4vepSX8g&pp=ygUOTmFkaWEgT2R...
I’ve also found Hardcover.app, which I quite like. It has an API and a slightly more refined UI, but it’s clearly more than one person working on it.
Of course, if your focus is book clubs, Fable is likely the app for you
StoryGraph now claims over 3 million.
Hardcover currently has 20K - and yes, a lot of those are fantasy based readers.
That just means it is easier for other readers to come in and potentially become the new largest user group. :)
GR ditching their API was one of the primary motivations for Adam Fortuna (Hardcover's founder and Lead Dev) to even think about trying to create a competitor, so when he did create one, having an API available to others was a primary focus.
Note: Hardcover is also working towards open sourcing at some level, hopefully in 2025.
Folks, don’t do that
Seriously think about whether you’d refer to an adult male startup founder as a “boy.”
When you have 20K (like Hardcover), it is much easier to be focused on each of them (or at least small groups of them) than when you have 20 million - much less a few multiples of that number.
As we grow, even Hardcover will have to evolve. This noted, I know this team (including myself, to be clear). Adam is truly focused on innovation and dev excellence. Ste, our lead designer, always has his eye on UI/ UX improvements and listening to what our users want/ how our users are using the site. As for myself, I'm the data/ social media guy - always looking to make our data as solid as possible and looking to use social media as effectively as possible. :)
Nadia has a couple of people working with her as well - Rob does some stuff, and Abby is their Head Librarian (or whatever similar title, she's effectively an all-around assistant that runs their Librarian Corps in addition to doing a few other things).
Hardcover is similarly a 3 person team - one primary Dev (Adam, Founder and Lead Dev), one primary UI/ UX guy (Ste, Lead Designer), and one primary data guy (myself, Head Librarian, also runs our Librarian Corps).
Nadia is awesome, don't get me wrong. What they've done over there is truly impressive and you'll never hear me say otherwise. Hell, I'm a paying supporter and librarian over there, I think they do such great work.
But I do think that what we've got going on at Hardcover is even better, and I'll stand by that too. :)
End of year is a big time for her as people setup reading goals for the year I think. My wife is now using it.
I wouldn't have guessed a book site would be so seasonal.
i just feel really behind on my book reading :/ havent read a good book in like a year.
Reviews are a by product IMO. I mean Goodreads reviews setup is horrible, no screening, nothing helpful in the implementation, etc
I use Nielsen's API, but the data is pretty rough, and you have to spend a lot of time cleaning it. Plus, the archaic industry standards around genre are hard to translate to what readers use - https://www.bisg.org/complete-bisac-subject-headings-list.
Ingrams and Bowker are the other big metadata providers. Ingram's is good but expensive, but the data faces the same issues.
Book metadata is very challenging. Even the publishers of said books are pretty bad at delivering good metadata.
National databases like the Library of Congress are significantly better - WorldCat is best used as a fallback for books that aren't included in the high-quality databases.
I imagine it complements or my even supersede tags.
(Admit I haven’t looked at all the sites people are mentioning in the comments yet- lots of good leads!)
StoryGraph isn’t necessarily better than Goodreads but it’s definitely just as good and it’s great to support software not owned by Amazon. They may own e-books but they don’t have to own reading.
I’ve been building an app specifically to help me manage the ebooks that I own
> I’ve been building an app
Most people live in a world where they don’t build their own ebook software. I think you actually do know this.
BTW my library (and probably yours too) has a free service where librarians will actually recommend books for you based on other books you liked or other criteria. I found those recommendations to be very good.
I won't say that it's great, there's a few things that annoys me, but it sure is better than GoodReads already and improvements are regularly added.
If these requirements are constant then one woman dev team is sufficient until the requirements become thick enough to handle with 2 hands.
And Pinterest reached 11 million users with 6 engineers, if interested https://read.engineerscodex.com/p/how-pinterest-scaled-to-11...
I'd like to have that for games and music. Stores are mostly terrible at recomending anything. Steam does better than most but still far from good.
And syncing recommendations with my mood is pretty much non-existent.
Here's the link, in case you finish watching her talk and want an even deeper-dive: https://changelog.com/podcast/577
Does this scale and when the business requires more coding and technical debt comes how do they manage it?
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.
> Pretty nice, 1 dev 3 team members in total and 1 million users?
So probably pretty close when they originally started their venture.
Notice (Dec 13): code cleanup continues; please keep reporting bugs to support@pinboard.in
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).
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
- 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.
Certainly there aren’t 140M MAU fore the steam deck or any of the games they’ve built themselves, that’s for sure.
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"
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.
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.
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.
The game sold over 30 million copies and had an all time high of over 230K concurrent players at one point earlier this year.
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.
Tons of FOSS projects.
See the entire JiaTan fiasco.
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.)
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.
I'm much more inspired to give a small one-person team some leeway about it though for a free app vs. Amazon and all its resources not even bothering to properly maintain Goodreads.
Even the built in dnla player works great.
Amazon are ridiculous and should be ashamed of such crappy software.
[good grief]
> Ruby on Rails community is so lucky to have Nadia
Another dead comment says it's not impressive, but doesn't mention gender.
Two dead comments calls the title sexist.
One dead comment predicts there will be misogyny.
Two comments say "who cares if it was a woman"
One comment laughs about "woke" complaints while being the only comment to use the word.
I think that's all of them.
I understand that putting "woman" in the title triggers a lot of talk about gender, which is off-topic and boring, but I don't really find any of the specific comments notable, hateful, or oppositional.
The fact that gender is mentioned at all, when it's never mentioned in posts that have "one man dev team" in the title, doesn't imply anything to you?
That is a charitable way to read the flagged comments.
The reality is your gender has nothing to do with your ability to write software. Software is the greatest of equalizers.
There is definitely a subset of society that feels it necessary to thrust gender into discussions where they have no place - such as this article.
Are we supposed to be more impressed because it was a female? Why?
Sure! I just find it interesting that these discussions only happen when "woman" is in the title, and never when "man" is in the title.
>There is definitely a certain subset of society that feels it necessary to thrust gender into discussions where they have no place - such as this article.
As long as you feel the same way whenever you see "one man dev team" or similar, I think that can be a good discussion.
I think the difference often is the intention of the writer. We get these types of headlines when people want to really promote how cool it is a female is capable of doing something - and we're all supposed to be amazed. That's pretty sexist if you think about it... of course a female is capable of writing high quality software! We should be amazed at what this person achieved because it is impressive on it's own merit - not because of the person's gender.
However, nobody is reading a headline like "one man dev team" and thinking "you go dude!".
It's a two-way double-standard that we should work on ending.
I think you're reading way too much into it.
Maybe they're just a women, and they did a turn on the phrase "one man team" to acknowledge that they're not a man?
I think that was my original point - who cares?
It adds nothing of value to their accomplishments, nor the article.
If anything, it detracts from the accomplishment. "Look how cute it is that the females are trying to code, applaud them!" - is the sentiment that comes out of it. It's the same affect as these all-female movie casts that then get promoted as "look how great it is that the cast is all female" instead of "look how great this movie is".
In general, we should just say person. Allow the accomplishments to carry themselves. If they are good, people will respond.
People see person and man as synonyms. One man dev team and one person dev team would illicit the same response but one woman dev team forces people to comment on the title.
Almost no one will read "one man Dev team" and think that gender is the central point, opposed to a simple descriptor.
The same phenomenon occurs with race fairly often. It is not uncommon for professionals to take offense or question gender or racial qualifiers when other people describe them.
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Society is not holding women and men to the same standards.
I think everyone making it out to be some big thing (which, the [dead] comments are bringing it up in a negative light for one reason or another) is the 'remarkable' thing.