For years I was told (and told others) not to reinvent the wheel. Fair enough, up to a point: nobody needs to rediscover that a circle spinning on an axle helps you move. The problem is that the saying assumes that when you build a new tool, you're arguing with that geometry. You almost never are. What you're building isn't the idea of a wheel. It's a wheel for a specific place.
And there was never just one wheel. A train wheel, a bike wheel and a shopping cart wheel all start from the same principle, but they solve very different problems. "Don't reinvent the wheel" hid an assumption: that the standard wheel, the one someone else designed, works for everybody.
For a long time it was good advice, simply because custom work was expensive. It took time, people and money. Software is no different. A tool built for a huge Silicon Valley company rarely understands how a small, local or personal project works. Instead of adapting to you, it makes you adapt to its view of the world.
Buy versus build used to come down to who could afford it. But with AI and open source, building costs a lot less, and the question shifts. It's no longer "does this exist?" but "does it exist for me, for what I do, the way I do it?" Seen that way, reinventing the wheel stops being a waste of time. It's a way to adjust, to learn and, along the way, to say who you are.
For a few reasons, I ended up building from scratch. Less for the result than for what happens along the way: that feeling that something is yours because you put it together. Psychology in the Global North has a name for this: the IKEA effect, our tendency to overvalue things we assemble ourselves.
But explaining the act of building your own tools with the name of a Swedish furniture store falls short. Making things with your own hands has a history everywhere. In the North it runs from the garage inventor to the maker movement, sometimes for fun and sometimes out of need. In the South, it was almost an instinct. Materials were scarce, imported spare parts cost a fortune, and whatever planned obsolescence declared dead still had to keep running. That's where you get Indian jugaad, Cuban technological disobedience, Brazilian gambiarra, or the classic Río de la Plata atado con alambre ("held together with wire"). They all share the same idea: treat the industrial object as raw material. Take it apart, stretch its life and make it work in a reality nobody designed it for.
Taking things apart to understand them
Partly out of curiosity and partly out of that old habit of opening up toys to see what's inside, I started building tools in my free time. Looking back, it fits nicely with what Ivan Illich called "convivial tools". Sounds academic, but the idea is simple: human-scale technology that leaves you in control, adapts to you and lets you learn, instead of locking you into a rigid system. I just wanted a quiet corner where I could be the architect of my own problems.
At first I wasn't trying to sell anything, or even show it. It was for me, to learn, and for the fun of it. I liked the freedom of building software without mastering every language, and seeing an idea working before I'd finished writing it down on paper. Over time they stopped being just mine, and now I'm opening them up as open source projects. What started as a personal whim now wants to grow and be shared.
That's how Adapta was born: a small RAG app for local use that connects to an OpenAI-compatible API endpoint. It's pretty simple. You pick a model and upload your documents. The app splits them into chunks, generates the embeddings and stores them in ChromaDB. It helped me understand the basics: what an embedding is, how semantic search works, and where the LLM fits into all of it. Transformers, to be honest, stayed pretty much a black box.
Then came Docket, a CLI for setting up agents inside a project folder. It started as a bash script, and after a lot of trial and error I moved it to Python. I wanted to understand, in plain terms, what an agent is and how you orchestrate one. For quite a while that path confused me more than it cleared things up. But I ended up with my own system for putting together teams of agents with different roles, and it's easy to adapt.
When building gets too easy
The third project came out of an old frustration. I tried a ton of project management apps, and none of them fit my projects, which aren't just software or websites. I wanted something versatile, and I didn't want to pay for yet another subscription.
So I started building a project management app in Rust Tack, local-only. I was aiming for the level of detail of the big platforms, but with my rules and my vocabulary. And it was surprisingly easy. A few prompts and it was done.
It left me with a weird feeling, like something was missing precisely because it hadn't cost me anything. And that's where the irony showed up. I write code every day; my thing is supposed to be understanding architecture and digging into the guts of systems. But with vibe coding (building working software by describing it in natural language), I found myself doing the same thing as anyone else: iterating, asking the chat to fix errors, and seeing what came out. I started out defending learning from scratch and ended up like someone building their first program. And it's fascinating how, on the surface, the act of creating got leveled out for everyone.
Of course, the magic doesn't last long. Vibe coding gets you started incredibly fast, but then you have to review the code, undo bad architecture decisions and secure the system. That takes a lot of rigor. Making a wheel that spins is easy. Making one that holds up a loaded train for years, without anyone ever thinking about it, is another story. Blindly iterating with the chat can quietly pile up vulnerabilities and structural problems you can't see. That's where craft matters. To build at the speed of imagination, you have to let go of fine control at the start, and make up for it with a ruthless architecture review at the end.
Since getting started cost nothing, I went looking for a bigger problem: what if I connected these boards so an agent could work with them? That's how I ended up with a small ecosystem of tools that talk to each other. They orchestrate specialized agents that read requirements, review code and check progress, without me having to hover over them all the time.
The wheel, again, but networked
Obviously there are already alternatives built by experts, with whole teams behind them and quite a few more zeros in the bank. Technically, I reinvented the wheel several times in a row.
If the privilege used to be being able to pay, now that building is almost free, the privilege has become curiosity, and the time to take apart what we use. But this isn't just a romantic win for open source.
The interesting part is that companies are also moving away from buying the closed package. More and more of them build their own tools and their own agent orchestration, tailored to their business and their rules. They do it for the same reason I did: a generic tool ends up imposing its way of working on you.
Reinventing the wheel isn't an isolated whim anymore. From someone alone in their free time to an entire company, a lot of people are redesigning it for the same reason. There's no single way to work, or to organize a project, or to do business, just as there was never a single wheel. Every team, every trade and every place has its own rhythms, its own vocabulary and its own ways of solving things. For a long time, tools asked us to leave all that at the door so we'd fit a standard. Now that building costs less, we have a chance to do the opposite: let the tool adapt to that diversity instead of erasing it.
A small confession, since it fits the theme: I wrote this in Spanish and used AI to help translate and polish it. A piece about building your own tools, assembled partly with someone else's. Sit with that.
Top comments (0)