I have never sold the same software twice, because every application I have built has been tailor-made for a specific problem, a specific organization, a specific set of constraints that made off-the-shelf solutions either too expensive, too generic, or simply absent, and this is not a business model I planned so much as what happens when you keep saying yes to the problems nobody else wants.
The problems nobody else wants are often the most interesting ones. They are the ones that require something unusual - an architecture that doesn't follow the template, a technology that isn't proven yet, an approach that looks wrong until it works. I have found, over a long career, that new technology is frequently that approach. Not because new is better by definition, but because the right new tool sometimes makes possible what the established ones make awkward or impossible.
Before It Had a Name
In 2000, just after the industry had spent two years convincing itself the calendar rollover would end civilization and then quietly moved on, I was building an application that could not do full page reloads. The data changed too frequently, the interaction was too tight, the user experience of reloading the entire page for every update was simply not acceptable for what the application needed to do. So I built something that used XMLHttpRequest to send requests in the background and updated only the part of the page that needed to change - encoding and decoding the payloads by hand, running in Internet Explorer because that was the browser.
A few years later the industry named this pattern AJAX and treated it as a revelation.
I am not telling that story to claim credit for anything, but because it illustrates the thing I have come to believe about early adoption: the technology existed. The need existed. The name and the community and the blessed pattern came later. The application didn't care about any of that. It needed to work, and the unconventional approach was the one that made it work.
The Dismissal Is Part of the Pattern
Every technology I have adopted early has been dismissed by someone whose opinion I respected at the time. JavaScript on the server. Asynchronous patterns before they were standardized. Vue when the community was still debating whether it was a serious alternative. Tailwind when the reaction was mostly horror at utility classes in HTML. Svelte before it had the audience it has now. Vite the day it was announced, before most people had finished reading what it was. Code generation over manual scaffolding. Bun before the community decided it was serious. The dismissal is consistent enough that I have come to treat it as a mild signal in the other direction - not a guarantee, but a data point worth noting.
The people doing the dismissing are not wrong to be cautious. Caution is a reasonable response to instability, to missing documentation, to APIs that change between versions, to a community small enough that your question might not have an answer yet. Those are real costs. The question is whether the benefit outweighs them for the specific problem in front of you - and that question has to be answered honestly, not defaulted to no because the consensus hasn't arrived yet.
The consensus is a lagging indicator. It tells you what was worth learning, after the learning window has mostly closed.
Code Is What Compounds
Writing about a technology and writing code with it are not the same thing, and reading about Bun and building an application server with Bun are not the same thing either. The understanding that comes from actually shipping something with a new tool - hitting the edges, finding the gaps, working around the missing pieces, discovering what it does better than you expected - is an understanding that cannot be acquired any other way and cannot be caught up to quickly once someone has it.
This is why early adoption is an advantage that compounds. The developer who shipped something on a platform before the mainstream arrived has a year or two of real experience when the mainstream does arrive. They know which patterns hold, which the documentation gets wrong, which things that sound like limitations are actually features once you understand them. That knowledge is not theoretical. It is in the code they wrote, the problems they solved, the instincts they built while everyone else was still skeptical.
When Bun stabilizes to the point where the majority of the industry considers it the default - and I believe it will - the developers who built on it early will have an advantage that a blog post cannot give you.
This Is Not About Playing With Toys
Early adoption gets misread as enthusiasm for novelty, as if it were the developer who chases every new release, installs everything, and moves on before anything ships, and that is not what I am describing. The technologies I adopted early were adopted because they solved a real problem I had, or opened a possibility I was looking for, or offered a fundamentally cleaner approach to something I was already doing the hard way. Some of them dissolved, and I moved on, sometimes back to what I was using before, without regret, because the exploration had value regardless of whether the technology survived.
What it gives you, beyond the technical fluency, is the one thing no amount of reading can replace: you are not surprised. When a client or a partner brings up a technology in a meeting - something they read about, something their team is evaluating, something they are excited or worried about - the answer is already there. Not because I prepared for that meeting, but because I was already there six months ago, writing code with it, finding its edges, and forming an actual opinion that means the conversation is already over before it becomes a gap.
The answer is usually just "Yes, Sir."
The Bun Controversy Is the Argument, Not Against It
As this is being written, Bun is in the middle of exactly the kind of turbulence that comes with early adoption. Jarred Sumner, who built Bun, is now at Anthropic following the acquisition of Oven in late 2025 - which puts him, in the loosest possible sense, on the same team as the AI writing this post. In May 2026, nearly a million lines of Zig were rewritten in Rust in six days - not by developers, but by AI. Six thousand commits. No human wrote a line. The result shipped with over thirteen thousand unsafe blocks in a language where the main reason you'd choose it is memory safety. Zig's no-AI-contributions policy, formalized just before the rewrite, was part of what forced the switch. The community reaction has been pointed, and some of the criticism is technically fair.
I am watching it, and I have not abandoned the bet.
The bet on Bun was never on Zig. It was on the API surface - the native HTTP server, the SQL client, the file I/O, the philosophy of a runtime that ships what an application needs without reaching for packages. Those things have not changed. The tests mostly pass. The unsafe blocks are being audited - Bun's own analysis shows the majority are addressable. The direction of the platform, the reason it was the right foundation for Reepolee, is intact.
This is what early adoption actually looks like from the inside. Not a smooth ride from promising to proven. A platform you believe in, turbulence you didn't anticipate, and a decision about whether the turbulence changes the fundamental case - and in this instance it doesn't, because the implementation language is not the product, and the product is what the runtime lets you build without ceremony, and that is still there.
Early adoption means staying when it gets uncomfortable, not just arriving before everyone else.
What Reepolee Is a Bet On
Reepolee is built on Bun. Not because Bun is fashionable - it is not yet, particularly - but because the native API surface, the performance, the philosophy of a wide standard library over a fragmented ecosystem, and the clean model of developing for the platform rather than against it, are the right foundation for the kind of applications Reepolee is designed to produce, and that is the genuine frontier bet.
The rest - code generation, server-side rendering, SQL as a first-class skill - are not bets on new technology. They are bets on old technology that never stopped being correct. SSR has been around for decades. Codegen has been around for decades. SQL has been around for longer than most developers reading this have been alive. The industry spent a few years convinced it had outgrown all of them, reached for client-side rendering and ORMs and manual scaffolding, and is now slowly, quietly, arriving back at the same conclusions that were already settled, and Reepolee did not wait for that return because it just never left.
Simplicity is a feature.
It is not a compromise made by teams too small to do it properly, but a deliberate choice made by developers who understand that every layer of complexity added is a layer that can fail, a layer someone has to maintain, a layer between you and the running code when something goes wrong.
Some of these bets will look obvious in five years, and one or two of them might not pan out, which has always been the shape of this kind of work. The alternative - waiting for consensus before building, reaching for what everyone else has already validated, staying inside the boundary of the well-documented and the safe - produces software that is fine and forgettable in equal measure.
I would rather be early and occasionally wrong than always late and never interesting.