BLOG

• 20/12/2025: Finding problems to solve
• 17/11/2025: Please follow a standard
• 16/09/2025: Dog food is yummy
• 25/05/2025: Its just HTML

Finding problems to solve

Finding good, original ideas for software projects is a common challenge. The following are two methodologies I use to find project concepts that are both novel and practical.

Method 1: The super-niche intersection
Many software domains have well established and high quality solutions, even in niches. Building a direct competitor is often inefficient. A better approach is to explore intersection of two niches. The point where they overlap is a "super-niche" where a dedicated solution is much less likely to exist.

Example: QMTIK

• Niche A: Libraries for quantized neural networks. This is a well-explored field, with mature solutions like TensorFlow Lite.
• Niche B: Minimalist, single-header, "stb-style" C libraries. This is also a well-established niche with a clear philosophy.
• The Super-Niche: A minimalist, single-header, stb-style library for quantized neural networks. This intersection was largely unexplored. QMTIK fills a specific gap for developers who need a simple, hackable, dependency-free tool for embedded ML.

Method 2: Solving an experienced problem
This is a more cliche approach: build a tool that solves a personal problem or improves upon a flawed existing solution. The key is to solve real problems, not to invent problems for the sake of a project.

Example: EFPIX

• The Problem: Secure, resilient communication is critical in environments without stable infrastructure (e.g., military, space, disaster zones).
• The Flaw in Existing Solutions: Flood networking is a known solution for resilience, but existing protocols often lack robust, modern security. They were not designed with a zero-trust mindset.
• The New Solution (EFPIX): A protocol designed from the ground up to combine the resilience of flood networking with a modern cryptographic stack (end-to-end encryption, perfect forward secrecy, metadata protection).

Please follow a standard

Modern software is fragile, bloated, and in a constant cycle of breaking changes. We spend more time managing dependencies and writing compatibility wrappers than we do solving actual problems. This is mainly because we dont respect standards.

The fallacy
There is a common misconception that "standards deter innovation". It is a convenient excuse that allows us to move fast and break things, leaving behind technical debt and incompatibility. But it is fundamentally false. Standards do not deter innovation. They are the platform upon which stable innovation is possible.

The reality
A standard defines the agreed upon way for things to interact but says nothing about the implementation. The C programming language is a perfect example. The ISO C standard is a formal document that defines the grammar, the keywords, and the behavior of the language. But how you implement it is where innovation thrives. We have GCC and Clang, which are compliant C compilers but are wildly different and innovative pieces of engineering.

"But ..."
"But what if my idea is so new, so revolutionary, that the existing standard can't accommodate it"? This is a valid question for which we have a clear answer. You can:

• Evolve the Standard: Standards are not meant to be static forever. You can write proposals to the publishing body and help create the next version. This is how we got C23 from C89, or Vulkan from OpenGL.
• Publish a New Standard: If your idea is a true paradigm shift, then do the hard work of formalizing it. Write a specification. Create a reference implementation. This is how Wayland came to challenge X11. This is how new technologies earn their place.

What you don't do is break the existing standard and call it "innovation".

Dog food is yummy

"Dogfooding" is the practice of using your own products. It is not just another form of testing but the only way to understand the true quality of life for your user, to feel the friction points, and to discover the missing features that no automated test can. When you design something you know you are going to use in the future, you are forced to make good decisions and improve the experience of the user because that user is you. My projects are an ecosystem, and they grow simultaneously by feeding each other.

Case: NCT
I use NCT to build and test all my C projects which creates an immediate, powerful feedback loop. Recently, while building another project, I found myself writing the same boilerplate. That frustration led me to add features to avoid this into the generated build.h. I solved my own real world annoyance, and every user of NCT benefits.

Case: QMTIK and VOCAL
I am currently building VOCAL, a locally-running voice assistant, which uses my other project QMTIK, a quantized neural network library for embedded systems. This relationship forces me to make better architectural decisions when developing QMTIK. Knowing that VOCAL will run on a microcontroller with no heap means QMTIK must be completely allocation-agnostic. When I am my own future customer, it ensures that QMTIK is a practical tool made for a specific, challenging purpose.

Case: libefpix
Sometimes, dogfooding also teaches you when not to use your own code. My initial plan for libefpix was to use my own No-Heap-RSA Zig library. But my library is an unaudited RSA implementation, and RSA itself is known to be slower and less efficient than the modern crypto stack. This led me to update the use cases of the RSA library and use the Monocypher library as the core dependency. Dogfooding gives you a fresh perspective of where to use and not to use your own product.

By being your own customer, you close the gap between developer and user.

Its just HTML

In recent years, websites have become increasingly complex, often at the cost of performance, reliability, and accessibility. Many modern development practices rely on large frameworks and intricate toolchains that can break unexpectedly and require constant maintenance. When I first learned to build websites, HTML alone was enough to create engaging, functional pages. Later, HTML5 and CSS replaced some of the simpler, built-in HTML features such as <center>, <font>, and bgcolor. For dynamic content, JavaScript was introduced, a language that is infamous for being extremely repulsive and inefficient. For this site, I chose not to use CSS (not even inline styles) or JavaScript at all. Here is why:

Simplicity:
For many websites, especially one like this, all that's needed is text, links, and images. HTML already supports these without additional layers of complexity. This makes the site easier to write, maintain, and impossible to "break" due to a framework update or dependency issue.

Speed:
A pure HTML page loads instantly, often faster than a single "Hello World" page created with a modern "groundbreaking" framework. Without unnecessary scripts and processing, visitors get the content right away.

Universality:
HTML works everywhere. In any browser, on any device, without deployment issues or compatibility concerns. Even text-based browsers such as Lynx can display the page exactly as intended.

Content Focused:
By removing decorative distractions, the focus stays on the content itself. HTML alone can still handle basic layout and presentation when needed, but the emphasis remains on what the page says, not on visual effects.

Privacy:
No cookies, no scripts, no tracking. Visitors can read without being monitored or having their data collected.

Longevity:
HTML is a universal language for the web. It has been around for decades and will continue to work for decades to come.

You don't always need a framework or complex toolchain to build an effective website. Start with HTML. Add CSS only if you truly need styling. Use JavaScript only when interactive features are essential. The simpler the foundation, the more accessible, reliable, and enduring your site will be.