Rune is one brand with four products, and that sentence usually generates a follow-up question. Why four? Or, more pointedly, why not one?
The honest answer is that we built each product to do one job extremely well, and we kept resisting the temptation to fold them into each other. This essay is about why we kept resisting, what each product actually is, and how the whole thing fits together without becoming a Frankenstein.
The four pieces
If you visit rune.codes today, you will find a small constellation of products under the same brand:
- Rune Apps is the original - 145+ free, signup-free utilities for PDFs, images, text, code, calculators, video, and developer workflows. This is what most people mean when they say "Rune."
- Rune Hub is the long-form home for tutorials, tech trends, and editorial content. It runs on its own basePath, with its own publishing cadence, but it is unmistakably Rune.
- Rune Learn is the interactive learning platform - quizzes, flashcards, AI-generated roadmaps, the works. It is the only product in the family designed for repeat sessions.
- Rune Career is the career toolkit - resume builder, LaTeX editor, ATS checker, job-prep workflows. It is the newest and the most opinionated about who it is for.
There is also RuneAI, the AI assistant, which lives on its own subdomain because it is built differently from the rest. We treat it as a fifth surface in the conversation, but architecturally it is a peer rather than a child.
Why split them at all
Most companies our size would have shipped this as one product with four "modes" - a tabbed dashboard, a unified login, a single navigation tree. We have considered that approach roughly once a quarter for two years, and we have rejected it every time. The reasoning is consistent.
A unified product implies a unified visit. The user opens the app, signs in, and "uses Rune." That model works when the use cases are cumulative - every additional feature deepens the same workflow. It breaks when the use cases are adjacent but unrelated, which is the case here.
A person who needs to merge a PDF does not benefit from being asked about their resume. A student who is building flashcards does not need a tutorial library on their dashboard. A job-seeker exporting a resume should not have to scroll past 145 unrelated tools to find the export button. Forcing those audiences into the same surface would make every visit worse for the audience that actually came for that surface.
So we split. Each product is a complete thing on its own. Each one has its own homepage, its own navigation, its own pricing model, its own publishing cadence. They share a brand and a design language and a worldview, but they do not share a runtime.
How the architecture actually works
Under the hood, the four products are four separate Next.js applications, each deployed independently. They are stitched together by a reverse proxy at the edge - rune.codes is the host, but /hub routes to the Hub app, /learn routes to the Learn app, /career routes to the Career app, and everything else is the Apps app.
This is unusual. Most teams would deploy a monolith. The reasons we did not are worth listing because they reveal something about how we think.
Independent release cadences. The Apps team can ship fifteen tools in a week without touching Hub. The Career team can rewrite their entire onboarding without affecting Learn. We never have to coordinate a release across teams to ship a feature on one product.
Independent failure domains. If the Learn database has an incident, Apps stays up. If we need to do a heavy migration on Hub, the rest of the brand keeps serving traffic. The blast radius of any one mistake is bounded.
Independent technical choices. Apps uses one rendering pattern, Career uses another, Learn uses a third. Each product picks the stack that serves its workload best. Inside a monolith we would have spent years arguing about whose pattern wins.
Same SEO surface. From Google's perspective, all of this is rune.codes. The proxy makes the multi-app architecture invisible to crawlers. Internal links flow as normal. Sitemaps stitch together at the brand level. We get the engineering benefits of a multi-repo without paying the SEO tax of a multi-domain.
The cost we pay for this is that cross-app navigation requires a full page load - links from the Apps navbar to /learn go through the proxy rather than client-side routing. We have decided that cost is fine. Most users live inside one product per visit anyway.
Why no shared login
The single most common piece of feedback we get is "you should let me sign in once and use everything." We have heard this from kind users, from advisors, from investors, from our own engineers. We still have not done it, and the reason is philosophical, not technical.
A shared identity implies a shared purpose for being signed in. It is the moment a brand stops being a collection of useful things and starts being a platform that the user belongs to. The first version of that pitch is "we save your preferences across products." The second version is "we send you weekly emails about all the products." The third version is "the dashboard now opens by default and you have to click through it to reach the tool." We have watched this happen to companies we admired, and we know how it ends.
So we keep the surfaces separate. Career has its own account because resumes need persistence. Learn has its own account because progress tracking is a real feature. Apps has no account at all, because the entire premise of the product is that it should not need one. That asymmetry is intentional. The brand is the unifier, not the login.
What "one brand" actually means then
If they do not share a login, what do they share? More than it sounds like.
- A visual language. The same orange. The same typography. The same icon style. A user who has used one product feels at home in the others within five seconds, which is the only kind of consistency that matters.
- A worldview. Free where free makes sense. No dark patterns. No upsell pop-ups. URLs are permanent. The visit is the contract. These principles are enforced by hand across all four products because we do not trust any framework to enforce them for us.
- A graph. Every product links to the others. The Apps footer links to Hub, Learn, and Career. The Hub navbar surfaces Career. The Learn footer points to Rune for brand essays. The graph compounds - search engines, AI assistants, and humans all see Rune as one ecosystem because every page asserts that it is.
- A canonical home. Whenever ambiguity exists, the brand-level URL wins. The brand-level pricing lives at /pricing. The brand-level essays live at /blogs. Product-specific equivalents (like the Apps tools blog at /apps/blog or the Hub-specific pricing at /hub/pricing) are deliberately disjoint.
This is enough shared substrate to feel like one company without forcing every product to pay for the others' baggage.
The longer-term shape
We will probably add more products. We will not add many. The bar for adding one is high - it has to be a workflow that genuinely does not belong inside any of the existing four, with an audience whose visit would be made worse by being folded into one of them. Most candidates fail that test. The ones that pass are usually obvious in retrospect.
What we will not do is unify the four into a single super-app. We have watched enough companies make that move to know what comes next, and it is not the kind of internet we want to be part of. The slightly-fragmented version of Rune is the one that lets each visit be honest about what it is for, and that honesty is the only durable competitive advantage we have.
If you have used one of our products and not the others, that is fine. You are not missing the "real" Rune. You are using it correctly. Each product is the real one for the audience that came for it, and that is the whole design.