-
-
This is Axiom running by other project, Nebula, which is a local AI model, in 0.18 seconds, running frontend and backend.
-
Axiom finds Nebula AI already trusted (because initially it asks trust this project y/n, i trusted it), and runs the project.
-
This is Axiom running my other project, a sampler that pairs by a QR code MIDI connection and shows some operations he did.
-
This is Axiom finding the QR code pairing sampler in 0.12 seconds and giving me some useful info about the providers.
The Problem: Running someone else's software locally can be surprisingly difficult. You find a project, download it, and then discover that you need to install a specific programming language, runtime, package manager, compiler, framework, and a collection of dependencies before you can even see the project running. The code isn't necessarily the hard part. The setup is. I wanted to see if that experience could be simplified.
What is Axiom? Axiom is an open-source native CLI designed to make running local software dramatically simpler. Instead of manually figuring out which development tools a project needs, Axiom is designed to inspect the project, identify its technology stack, prepare what it needs, and run it.
The goal is simple:
axiom run
Point Axiom at a project and let it handle more of the environment setup automatically. Axiom can also work with existing project folders and packaged projects such as .zip files.
Why I Built It:
The idea came from a simple frustration: developer environments have become extremely powerful, but that power also creates a lot of setup complexity. If I download a project from GitHub, I shouldn't necessarily need to understand its entire development toolchain before I can run it. I wanted to build a layer between the user and that complexity.
Instead of:
What language is this? What runtime does it need? Which package manager? Which version? What command do I run? Why is this dependency missing?
The goal is:
Find project Axiom detects it Axiom prepares the environment Axiom runs it
How It Works: Axiom examines the structure of a project and looks for signals that identify its technology stack.
For example, files such as:
Cargo.toml package.json requirements.txt pyproject.toml
can provide information about what kind of project Axiom is dealing with.
From there, Axiom can determine an appropriate execution strategy. The project is designed as a native CLI so that the tool itself doesn't introduce another large development environment just to solve the problem of development environments.
What I Built: The current implementation supports running:
Existing project folders .zip projects .exe files
It also includes project detection and a simple command-line workflow intended to keep the user experience minimal.
The project is open source, so the implementation and development process are publicly available.
Challenges: The biggest challenge is that "run a project" sounds much simpler than it actually is. Different projects make different assumptions about their environment. They can use different languages, dependency systems, directory structures, build commands, and runtime requirements. That means Axiom has to deal with a large number of edge cases while still keeping its interface simple. Another challenge is deciding how much complexity should be automated. A tool like Axiom shouldn't hide everything from developers. Advanced users may want complete control over the underlying environment. The goal is therefore not to remove the existing developer toolchain. The goal is to make it optional when it doesn't need to be exposed.
What I Learned: Building Axiom taught me that developer experience is an engineering problem in its own right. A command that looks trivial from the outside can require a surprising amount of logic underneath. I also learned that good abstractions aren't necessarily about adding more features. Sometimes they're about taking a complicated process and presenting only the part the user actually needs.
For Axiom, that part is simple:
Run the project.
What's Next: Axiom is still early, and there is a lot more I want to explore. Future work includes expanding project detection, improving dependency and toolchain management, increasing cross-platform support, and making isolated environments more reliable. I also want to explore an integrated AI app builder that can help users turn an idea into a working application directly from Axiom. The goal would be more than simply generating code: the assistant would scaffold projects with sensible defaults for authentication, rate limiting, input validation, and other common security protections already built into the generated application. The long-term goal is to make Axiom a general-purpose local development and runtime layer that can help users go from idea → project → secure application → running software without forcing them to manually configure every part of the development environment first.
Links: Source code: https://github.com/the1of1matt/axiom Latest releases: https://github.com/the1of1matt/axiom/releases
