Behind the Build
Why 'Free' Online Tools Are Not Actually FreeBehind the Build
Building Codes of Hex: What Two Years of Self-Taught Development Taught Me
I am not a formally trained developer. I have five years of experience working in tech, but my real education has always happened after hours — reading, building, breaking things, and figuring out how to fix them. Codes of Hex is the most sustained thing I have built, and the two years of developing it have taught me more than I expected, both about software and about how to build something that people actually find useful.
It started with gaming, not with code #
My alias — Hex — is my in-game name from years of competitive gaming. Friends picked it up and it stuck, and eventually it became the name behind this project. Gaming sounds like an unusual foundation for a developer, but it taught me the most important skill I use every day: how to be resourceful when you are stuck. In a game, you cannot just wait for someone to tell you the answer. You figure out the system, test what happens when you push its edges, and adapt fast when your first approach fails.
That instinct transferred directly to learning how to build software. When I did not understand how Flask routing worked, I did not stop — I tested it, read the error messages carefully, and kept going. When I needed to process PDF files in Python, I found the libraries, read the documentation, built something small first, and extended it from there. The process is exactly the same as figuring out a game mechanic: observe, hypothesize, test, iterate.
What gaming did not teach me — and what took me longer to learn — is that shipping something imperfect but working is almost always better than waiting until it is perfect. My first tools were rough. The UIs were functional but not polished. The code behind some of them makes me wince slightly when I look back at it. But they worked, people used them, and the feedback from real usage is what made every subsequent version better.
I share this because I think the path of 'started from gaming, self-taught, built something real' is more common than people admit, and more legitimate than the formal credentials narrative sometimes suggests. The internet is full of people who learned to build things because they needed to build something specific. That is a perfectly valid way to become someone who builds things.
What the AI-first approach actually means #
I started using AI tools in my development workflow early, and I use them throughout every new tool I build. I want to be specific about what this means, because 'AI-first development' gets used to mean different things and some of those meanings are more honest than others.
For me it means using AI as a pair programmer and a research accelerator. When I need to understand how a Python library handles edge cases, I can get a working explanation in seconds instead of reading through three pages of documentation to find the relevant section. When I have a rough idea of what I want to build, I can iterate on the architecture in conversation before writing a line of code. When something is not working, I can describe the behavior I am seeing and get targeted debugging suggestions. This makes me significantly faster than I would be working alone.
What it does not mean is that AI writes the code and I copy it. Every tool on Codes of Hex went through real debugging sessions, real user testing, and real decisions about what to include and what to cut. The AI suggestions are starting points, not final answers. Understanding what the code does and why it is structured a certain way is non-negotiable — a tool that breaks in ways I cannot diagnose is not a tool I can maintain or improve.
The honest version of AI-first development is that it raises your effective ceiling. A self-taught developer with strong problem-solving instincts and good AI tooling can build things that would have taken a larger team a few years ago. That is a genuinely new situation, and I think it is one of the reasons the current moment is a particularly good time to be a resourceful person who wants to build things.
What building in public as a solo developer actually looks like #
Codes of Hex is a one-person project, and keeping it that way has been a deliberate choice. Staying solo means every decision about what to build next, how to prioritize, and what quality bar to hold reflects one set of values — mine. There is no committee deciding that a feature should be monetized, no product manager optimizing for engagement metrics that do not align with what users actually need. The tools exist because they are useful, not because they hit a quarterly target.
The tradeoff is that everything takes longer. When a tool has a bug, it is my bug to fix. When a new tool is added, I research it, design it, build it, test it, and write the documentation for it. This is slower than a team could move, but it is also more sustainable than I expected — because each tool is something I genuinely needed myself, I care about getting it right in a way that is harder to manufacture.
User feedback has shaped the site more than anything else. Early versions of some tools had limitations I was not aware of until someone encountered them and wrote in. The batch PDF compression came from a user who needed to process multiple files at once. The subtitle converter format support expanded because someone needed to handle SCC files from a broadcast workflow. Building in response to real needs rather than assumed needs produces better tools than building in isolation.
Running the site also involves more non-code work than I expected when I started. Performance, infrastructure, SEO, writing clear documentation for each tool, responding to feedback — these take real time and are as important as the code itself. The lesson is that building something is about 40 percent of shipping something useful. The rest is everything else.
What is coming next #
The site is still growing. There are tools I want to build that I have not had time to ship yet — more document utilities, some audio tools, a few workflow-specific utilities that keep coming up in feedback. The backlog is longer than the shipped list, which is a good problem to have.
The core commitments will not change as the site grows. Every tool will stay genuinely free with no conversion caps. No account system will be added. Privacy will continue to be treated as a default rather than a feature. These are not marketing promises — they are the reason I built this in the first place, and changing them would make Codes of Hex exactly the kind of site I was frustrated by when I started.
If you use any of the tools and they solve a real problem for you, the best thing you can do is share the tool with someone else who would find it useful. That is how the site grows, and it is a much cleaner feedback loop than ad impressions or email subscriber counts. Word-of-mouth from someone who genuinely found value is the signal that matters.
And if something is broken, or a tool does not support a format you need, or you have an idea for a tool that would fit the site's philosophy — reach out. Every piece of feedback goes directly to me, and most of the best ideas on the site came from someone who needed something and took thirty seconds to say so.
FAQ
Quick answers for common edge cases.
Are you a professional developer?
Not in the formal sense — I am a tech professional who taught myself development after hours. Five years of working in tech gave me a foundation, but the actual building skills came from reading, experimenting, and shipping things that needed to exist. Codes of Hex is the most sustained project I have built, and it has taught me more than any course or certification could have.
What tech stack does Codes of Hex use?
The backend is Flask (Python). The frontend is plain HTML, CSS, and minimal JavaScript — no framework overhead, just functional, fast interfaces. The tooling behind each feature varies: PDF processing, image handling, and subtitle parsing each use purpose-built Python libraries. The site is deliberately lean so it stays fast and easy to maintain.
How do you decide what to build next?
Mostly from personal need and user feedback. Every tool on the site started as something I needed that I could not find a clean free version of. The expansion into new formats and features usually comes from someone writing in to say a specific thing does not work, or a format is not supported. The backlog is long and prioritized by a mix of how often something comes up in feedback and how much I personally want to build it.
Can I request a tool or feature?
Yes — there is a request form on the home page and a contact page. Even a one-line description of what you need helps. Most of the tools on the site exist because someone needed something specific and said so. The more concrete the use case, the more useful the request is for prioritization.
Related guides
Continue with adjacent workflows.
