HN

Comments (180)

• Menu

  wrs
  This is sort of a whole product, but it’s hardly managing the whole company. Financials? HR? Contracts? Pictures of the last team meeting?It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.
• Menu

  eddd-ddde
  I am a huge monorepo supporter, including "no development branches".However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo.Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.
• Menu

  sethammons
  people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api.At some point, you will have many teams. And one of them _will not_ be able to validate and accept some upgrade. Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. Yes, this happens at slightly larger orgs. I've seen it many times.And since you have to design your changes to be backwards compatible already, why not leverage a gradual roll out?Do you update your app lock-step when AWS updates something? Or when your email service provider expands their API? No, of course not. And you don't have to lock yourself to other teams in your org for the same reason.Monorepos are hotbeds of cross contamination and reaching beyond API boundaries. Having all the context for AI in one place is hard to beat though.
• Menu

  giancarlostoro
  I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too.I guess I could work with either option now.
• Menu

  Escapade5160
  This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.
• Menu

  codingdave
  > When you ask Claude to "update the pricing page to reflect the new limits," it can...wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?
• Menu

  johnfn
  This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.
• sails
  I like this for adjacent things too.Company website in the same repo means you can find branding material and company tone from blogs, meaning you can generate customer slides, video demosGoing further, Docs + Code, why not also store Bugs, Issues etc. I wonder
• Menu

  doublet00th
  I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea.Here were the downsides we ran into- Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service.- CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything")- Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time.That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released.[1]: https://pangea.cloud/
• Menu

  radial_symmetry
  I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ for.We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks.Internally we have been doing a lot of what they talk about here, doing our design work, business planning, and marketing with Claude Code in our main repo.
• Menu

  williamtrask
  "Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything.When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings?The monorepo isn't a constraint. It's a force multiplier."Thank you Claude :)
• Menu

  root_axis
  55 business logic services? Sounds extremely overengineered. I'm sure at least half of those services should be consolidated into others.
• reactordev
  I leverage git submodules and avoid the same pitfalls of monorepo scale hell we had 20 years ago. Glad it works for you though. I feel like this is the path to ARR until you need to scale engineering beyond just you and your small team. The good news here is that the author has those domains segregated out as subfolders so in the future, he/she could just pull that out into its own repo if that time came.Still adverse to the monorepo though, but I understand why it's attractive.
• auslegung
  Well written, anticipated my questions about pain points at the end except one: have you hit a point yet where deploying is a pain because it’s happening so frequently? I understand there’s good separation of concerns so a change in marketing/ won’t cause conflicts or anything to impact frontend/ but I have to imagine eventually you’ll hit that pain point. But fwiw I’m a big fan of monorepo containing multiple services, and only breaking up the monorepo when it starts to cause problems. Sounds like author is doing that
• Menu

  conartist6
  I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!
• 7777777phil
  Interesting approach to giving LLMs full context. My only concern is the "no workspaces" approach; manual cd && npm install usually leads to dependency drift and "it works on my machine" issues once you start sharing logic between the API and the frontend. It’s a great setup for velocity now, but I'm curious if you've hit any friction with types or shared utils without a more formal monorepo tool?
• c-fe
  I like this a lot. Every time I am forced to open Notion or Slite, I just wish so much it would just be .md files in a git repository.
• Menu

  supermdguy
  How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.
• Menu

  bilbo-b-baggins
  Good Christ. Imagine having decided that your price structures should be a JSON file instead of persisted in a database and then thinking that any decision made by that person/team is a good idea.I look forward to when we see the article about breaking the monorepo nightmare.
• Menu

  codegeek
  I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?
• darepublic
  The opening blurb about updating a JSON file and seeing it reflected right away in the live web app just reminds me of a CMS.
• Menu

  graphememes
  You can still have all the context in one place, just clone the repos to one folder on your machine, problem solved.
• sandeepkd
  I envy this confidence, the less you know the more confident you are.
• anon
  undefined
• jensenbox
  Oddly enough, I wrote an article about this very topic recently: https://medium.com/@jensenbox/why-monorepos-are-winning-in-t...
• burgerone
  Had me interested up until the word "AI"
• throw-12-16
  Sounds like a pain in the ass for non developers to contribute.Also, are we just upvoting obvious AI gen marketing slop now?
• harel
  For the purpose of AI Tools, you can also have one workspace, or one directory where multiple repos are cloned to as a parent. Just saying...
• Menu

  dheera
  The thing I dislike about monorepos is that people don't ship stuff. Multiple versions of numpy and torch exist within the codebase, mitigated by bazel or some other build tool, instead of building binaries and deb packages and shipping actual products with well-documented APIs so that one team never needs to actually touch another team's code to get stuff done.The people who say polyrepos cause breakage aren't doing it right. When you depend across repos in a polyrepo setup, you should depend on specific versions of things across repos, not the git head. Also, ideally, depend on properly installed binaries, not sources.
• hrdwdmrbl
  I love the idea. It's bold. But, I hate it from an information architecture perspective.This is something that is, of course, super relevant given context management for agentic AI. So there's great appeal in doing this.And today, it might even be the best decision. But this really feels like an alpha version of something that will have much better tooling in the near-future. JSON andMarkdown are beautiful simple information containers, but they aren't friendly for humans as compared with something like Notion or Excel. Again I'll say, I'm confident that in the near-future we'll start to see solutions emerge that structure documentation that is friendly to both AIs and humans.
• stego-tech
  Honestly, from the enterprise IT perspective?Fuck yes I love this attitude to transparency and code-based organization. This is the kind of stuff that gets me going in the morning for work, the kind of organization and utility I honestly aspire to implement someday.As many commenters rightly point out, this doesn't run the human side of the company. It could, though, if the company took this approach seriously enough. My personal two cents, it could be done as a separate monorepo, provided the company and its staff remain disciplined in its execution and maintenance. It'd be far easier to have a CSV dictate employees and RBAC rather than bootstrapping Active Directory and fussing with its integrations/tentacles. Putting department processes into open documentation removes obfuscation and a significant degree of process politics, enabling more staff to engage in self-service rather than figuring out who wields the power to do a thing.I really love everything about this, and I'd like to see more of it, AI or not. Less obfuscation and more transparency is how you increase velocity in any organization.