Over the past four years, I’ve set up three monorepos for different companies as contract work. The experience was positive, but it’s essential to know your tools.
Since our monorepos were used exclusively for frontend applications, we could rely entirely on the JavaScript/TypeScript ecosystem, which kept things manageable.
What I learned is that a good monorepo often behaves like a “polyrepo in disguise.” Each project within it can be developed, hosted, and even deployed independently, yet they all coexist in the same codebase. The key benefit: all projects can share code (like UI components) to ensure a consistent look and feel across the entire product suite.
If you're looking for a more practical guide, check out [0].
Not sure if my "products" compare to yours, but I’ve seen some success with a few of them over the years, maybe there are some takeaways (or pitfalls to avoid) for you:
CloudCamping (PMS): 250+ Businesses, 2023
- Positioned as more modern, more accessible, and more affordable than the competition
- Limited competition due to the complexity of the product
- Personally visited campgrounds to demo the product
- Sent physical postcards (old school!) to campgrounds with product updates and announcements
- Due to limited competition, it is now ranking very high in the German marked on SEO
The Road to React & The Road to Next: 1000+ Users, 2024
- Gave away The Road to React for free in exchange for an email, grew the mailing list this way
- Benefited from early timing (luck!), it was the first book on the topic
- Initial version wasn’t polished, but I kept iterating and improving it each year
- In 2025, released the paid course The Road to Next to my audience, now over 1,000 students enrolled
SoundCloud (DJ/Producing as “Schlenker mit Turnbeutel”)
- Active from 2010–2015 as a hobby, grew to 10,000+ followers (a lot for the time)
- SoundCloud allowed 1,000 direct messages per track
- Carefully selected 1,000 high-engagement listeners in my music niche and personally messaged them to check out new tracks
So yeah, a mix of timing/luck, outreach that does not scale, being better than the competition I'd say.
* It includes price differentiation. Grounds that want to save the last penny can do so by handling payments themselves. I guess camping grounds are very price sensitive.
* It grows with size of the value provided
* Grounds can start using the tool without paying anything. Thus low barrier of entry
* It seems unlikely anyone can win over existing customers based on undercutting your price.
* 1% of revenue of a business sector can make up a nice indie business.
Thanks for your feedback and for validating the pricing model! We see it the same way.
Most property management systems charge campground owners several thousand dollars upfront, before they can even try the software. That’s where our approach stands out: we offer a low barrier to entry paired with a modern user experience. Many competitors started over 15 years ago, and you can tell by how outdated their products feel.
Taking just a 1% cut can pay off if it helps capture more market share, this was my thinking too. We’re not quite there yet, as not all of the 250 campgrounds on our platform have adopted online payments. Still, it’s both exciting and a bit terrifying to see some of them already processing over $250,000 in annual bookings through our system.
I’ve had a few sleepless nights, so I wouldn’t necessarily recommend building a marketplace product to everyone. Once real money flows through your platform at that scale, things get intense fast.
Was there any particular reason you stopped making music?
I'm listening to one of your mixes right now and I'm wondering if you were influenced by Klangkarussell at all (or maybe the other way around?) or if that was just the general 2014 vibe.
I’d say it was mostly the general 2014 vibe. But yes, I listened to Klangkarussell and many other German producers. I was probably most influenced by Alle Farben, who was known for his mixtapes before he started producing his own tracks (which I wasn’t really a fan of). But I also showcased a darker side in some of my mixtapes (like "Der schwerste Gang einer Ente" where I used artists like Burial).
I saw myself more as a consumer than a producer. I mainly created mixtapes because I was constantly discovering and consuming new music. When I had the chance to play at a club or an open-air event (I tried it once), I quickly realized I wasn’t too comfortable performing in front of an audience :)
Around that time, I had just started learning to code and built my first little automations to help me discover even more music on SoundCloud. So I noticed this was another (more lucrative with the similar level of passion) career path where I didn't had to be in front of an audience.
Thanks for the flashback! My first coding assignment in highschool was to build a camping management tool in Visual Basic. This is what got my into coding.
Good for you that it was just a coding assignment! I naively jumped into building this SaaS without realizing how many features a modern property management system actually needs :)
I'm not sure if they’ve added any monetization features over the years. Back then, it was arguably the best platform for getting discovered as a producer or DJ. When I stopped making music, I was getting a lot of requests to play at clubs across Germany and Europe.
At the time, I preferred to stay anonymous, so I never made the leap into the professional or public scene. Still, I was in touch with some producers early in their careers on SoundCloud when they had 1000 followers, like Robin Schulz and Felix Jaehn, if those names ring a bell.
So yes, I’d say it was (is?) definitely a launchpad for artists. But as far as I know, there was never a real way to monetize on the platform.
Unfortunately, when I stopped paying for the Pro version, they removed almost all of my music. Only 5 mixes are still up :')
Might be fortunate instead: they're setting up to be able to train AI on specifically you and then, if needed, make music AS you undercutting you. Such is the way of things these days.
I dropped Soundcloud paid version too, and migrated to just YouTube. Currently YouTube is trying very hard to learn to reply to my fans AS me, but through pushing buttons to immediately supply AI-generated responses. I'm sure anyone else with a substantial YouTube presence has seen this too.
So far, they are not self-pressing the button and taking over replying to my fans for me, against my will. So far. They'd also be looking at some challenges in AIing my content as it's weekly open source software development serving a specialized audience, though they would have a considerably easier time AIing my thumbnails, as those are a very predictable pattern and reproducible.
Regarding OP, and in the light of what I've said, maybe ask yourself in what way you can disambiguate yourself from any random AI-powered startup in targeting what for the other startup will be an arbitrary or shotgun selection of customer targets. Is there an audience you can work specifically for, and is there a way you can signal to that audience that you're particularly aware of them and interested in working for them?
Hey Jason, just saw your email and wanted to reply here.
Unfortunately, I don’t think the postcards really worked. We sent them to various regions across Germany, but my guess is they ended up in a pile at the campground reception and never reached the actual owners.
That said, we manually scraped around 500 campgrounds near us, designed postcards that highlighted CloudCamping’s key selling points, and sent them out using a different mailing service. Since we didn’t hear back from anyone specifically mentioning the postcards, I assume they didn’t convince anyone in the end.
Still, it was a fun experiment, and who knows, it might work better in a different context!
I used to run a SaaS, and I also used postcards to try to promote it! Why not use emails? I was sure that emails would get spam-collected, but physical postcards might get some attention.
I don't know if the tactic worked.
These days, if I were mailing postcards, I'd make sure to add a special QR code to them. That way, if someone went to my sales page using the QR code, I'd have an idea that the postcard had been seen by the right person. Postcards are rather expensive (both the postcard and the stamp). Who wants to keep trying that without knowing it was successful?
We use the dataloader pattern (albeit an in-house Golang implementation) and it has solved all our N+1 problems.
E2E type safety in our case is handled by Typescript code generation. It works very well. I also happen to have to work in a NextJS codebase, which is the worst piece of technology I have ever had the displeasure of working with, and I don't really see any meaningful difference on a day to day basis between the type sharing in the NextJS codebase (where server/client is a very fuzzy boundary) and the other code base that just uses code generation and is a client only SPA.
For stitching we use Nautilus and I've never observed any issues with it. We had one outage because of some description that was updated in some dependency and that sucked but for the most part it just works. Our usage is probably relatively simple though.
I have used RSCs only in Next.js, but to answer your questions:
1./2.: You can update it optimistically. [0]
3.: Depends on the framework's implementation. In Next.js, you'd invalidate the cache. [1][2]
4.: In the case of the like button, it would be a "form button" [3] which would have different ways [4] to show a pending state. It can be done with useFormStatus, useTransition or useActionState depending on your other needs in this component.
5.: You block the double request with useTransition [5] to disable the button.
6.: In Next, you would invalidate the cache and would see your like and the like of the other user.
It's not really the scope of the article, but what about adding a client directive [0] and dropping in your event handler? Just like that, you're back in a familiar CSR React world, like in the "old" days.
I've been working on The Road to Next [0] for almost a year. In the end, it's more than just a course on Next.js. It's a deep dive into full-stack development, covering key third-party integrations that empower you to build your own products.
Oh hell yeah, your Road to React was exactly what the doctor ordered when I first waded my way into the full stack ocean years ago. I'm excited to see how this progresses!
Hi HN! I know not many of you are hyped about paid courses, but here I am, almost 8 years after launching my (free) book The Road to React on HN :) [0]
Yesterday, I launched the Early Access for The Road to Next! This self-paced video course already has hours of in-depth content, and registration will be available for one week. After that, I’ll dedicate my time to supporting the cohort’s learning journey, finalizing the remaining content, and refining the course to make it even better.
In the course, students will build a complete full-stack application, covering everything from the UI to the database — and everything in between — with a strong focus on DX and UX.
There are two Journeys in the course which build up on top of each other:
The Developer Journey lays a solid foundation, equipping students with core concepts and practical skills. Along the way, they'll work with various database models, including Session (custom authentication), User, Ticket, and Comment. Developers will also face real-world challenges, e.g. understanding the quirks of floating-point arithmetic and rounding behavior.
As they progress to the Engineer Journey, they’ll dive into advanced topics like message queues and email systems, everything while implementing features such as user organizations, memberships, and invitations. For this journey the code will be available, but the recordings are still in the making.
Since I've been active here for years, I wanted to share this with you too. If you have any questions, ask me anything!
Since our monorepos were used exclusively for frontend applications, we could rely entirely on the JavaScript/TypeScript ecosystem, which kept things manageable.
What I learned is that a good monorepo often behaves like a “polyrepo in disguise.” Each project within it can be developed, hosted, and even deployed independently, yet they all coexist in the same codebase. The key benefit: all projects can share code (like UI components) to ensure a consistent look and feel across the entire product suite.
If you're looking for a more practical guide, check out [0].
[0] https://www.robinwieruch.de/javascript-monorepos/