The Scratch Builder's Manifesto

A Declaration of Independence from Premade Code

Intro

I used to think I was a programmer. I could make games in big engines, follow tutorials, and copy-paste code from Stack Overflow. But the truth? I didn’t understand a damn thing I was writing. I was just assembling parts someone else had built.

Fast forward to today, and I've rebuked libraries, frameworks and other premade solutions. Why? Because I need to understand what it is I'm writing. I still recognize the value of frameworks and game engines and am thankful for the experience they were able to provide me, but it's not enough to rely on unmaintained libraries made as a hobby that can easily be hijacked.

It's time for me to do my own thing.

The Evil of Convenience

With the advent of LLMs and generative AI, I found myself slipping into the jaws of convenience. I could have it spit out all the code I needed and all I had to do was plug it in!

One day, my senior pulled me into a huddle to discuss one of my pull requests. I thought this was odd; I hadn't ever been pulled in to discuss a pull request before. Had I done something wrong? Well, as a matter of fact, I had. We had just had a dev meeting discussing anti-patterns in our codebase and how they not only affect the devs, but the customers as well. In my complacent implementing of the code that AI had spit out, I had introduced tech debt and performance issues.

The Glory of Understanding

My senior had written much of what I was interacting with himself. He had understanding. As much as I want to blame the code the AI wrote, the actual problem was that I had stopped thinking. That moment in the huddle made me realize that I had traded understanding for speed, and I was worse off for it.

Mastery Through Creation

We all know that repetition is how we master skills. Frameworks and libraries have taken repetition away from us, and therefore our ability to master the code we write. By building from first principles, we can learn things that can easily be applied in new areas.

No Black Boxes

"If you're nothing without the suit, then you shouldn't have it" - Tony Stark

If you don't know how it works, then you cannot possibly hope to own it. The data you passed in? Not yours anymore. The data that comes out? Nope. There's a reason why the biggest companies maintain the libraries they use themselves.

Simplicity Through Control

Every library has to take every possible use case and edge case into account, including ones that you've already accounted for. The bloat can definitely get in the way of good user experience, but it can even make your job harder. If you've tried to improve the speed after the fact, you know how much more work has to be done to get anywhere near the performance you could have if you just wrote the bare minimum yourself.

Optimized for Purpose

Every line should have a reason to exist. I don't need my car to blend my smoothies, and I don't need my router to send my emails.

The lampshade

Of course, there are skeptics. These questions crop up all the time when I talk about scratch building.

Isn't this reinventing the wheel?

Yeah, you could say it is. But the wheel is easily comprehended. It doesn't hide what it's doing. Its form indicates its function. Libraries are opaque, often needing their own learning curve to be able to use. By writing it yourself, you see the form and the function.

How do you manage time constraints?

Time constraints are real. But the key isn’t to blindly rush—it’s to invest in foundational code that pays off later. Instead of treating time as a constant constraint, treat it as a long-term investment.

When should you break the rule and use a library?

As mentioned before, time is one big factor. Cost is another. As a solo dev, there is no cost but your own time, but as soon as other people work for you, their time is money.

What about security, performance, and community-tested solutions?

Some argue that libraries are more secure because they’re vetted by the community. But security through obscurity isn’t real security. When you write your own code, you know exactly what’s happening under the hood—there are no unknown exploits hiding in third-party dependencies.

WRITE IT YOURSELF!

I started a project called Bearmetal. The entire purpose is for me to write TypeScript libraries and understand how they work and interact. It all started with the very first version of Smoke 'n' Rails - a set of dots following a line. I had written a small set of HTML canvas helper functions, so I took them and abstracted them into the first version of Doodler, which now has several tools for making games. The kicker is that none of it was hard, and I learned so much about game dev basics.

So, write something yourself! Take a function you use all the time from your favorite library and write it yourself. Make your own "Bearmetal" library, maintain it yourself, find the things that work and discover what use cases you have. Find other likeminded coders writing cool things from scratch and see if you can't make a project together.

Conclusion

The internet used to be full of scratch builders sharing ideas and solutions. That sense of community has faded in recent years with calls to read the docs and "answered in deleted post 95." There can be a return to helpful culture if we stop treating scratch building as an archaic and unnecessary practice. The future of scratch building is full of smarter devs and more robust solutions.