Skip to content
SpaceParrots logo
Open Source

Developer tools that came out of real client work

Both tools on this page are by-products of client projects. Something was missing in day-to-day work, I built it, and because it held up, it now sits in the open on npm and GitHub. No product business, no licence model: code you can read, fork and keep running without me.

The tools

The two tools at a glance

nit and vex solve different problems. Both are open source and available on npm and GitHub.

nit

Point-and-click website annotation that hands small UI fixes straight to a coding agent.

You click the element, type the nit, done. Every annotation stores a stable reference to that element plus the route, viewport and a screenshot, so a coding agent can find the source without you describing it in prose.

vex

CLI and MCP server for the Vendure Admin GraphQL API.

vex manages multiple Vendure instances, builds queries interactively, knows your schema including custom plugins and saves operations for replay. Wired up as an MCP server, the same commands become available to an AI agent instead of being typed by hand in a terminal.

Approach

Why we build in the open

Open source is not a stance we put on a page. It is a way of working that keeps us honest during a project and leaves the client independent afterwards. Three reasons, in the order they actually matter.

Tools come out of real project work, not product ideas

Neither nit nor vex started on a whiteboard. nit came from the frustration of explaining to an agent, in prose, which tile on which route looks wrong; vex came from needing to inspect Vendure instances without opening the admin UI every time. A tool that grows out of real friction solves a real problem and does not die on its second feature.

Open source forces clean interfaces

The moment code is public, you can no longer keep assumptions in your head. Configuration has to be documented, dependencies explicit, error messages readable by someone who has never spoken to you. That discipline flows straight back into client projects, where tomorrow's stranger is your own team.

Handover instead of dependency

A client using one of our tools keeps it when the engagement ends. The licence does not expire, the code lives on npm and GitHub, and another team can read it and carry it on. We want to be hired again because the work was good, not because leaving is expensive.

FAQ

Frequently asked questions about nit and vex

Yes. nit is licensed under AGPL-3.0 and vex under MIT, and both are published as npm packages you can install right away. There is no licence fee, no account and no feature hidden behind a paywall.

Only for vex, which talks to the Vendure Admin GraphQL API and requires Vendure 3.6 or newer. nit is stack-agnostic and works on any website you can open in a browser.

Both tools are built so an agent can drive them directly. nit exports its annotations as an agent-readable folder or serves them over MCP; vex exposes its commands and saved operations over MCP as well. The agent gets precise references instead of vague descriptions.

I look at GitHub issues, but there are no guaranteed response times. If you run the tools in production and need dependable support or a change made, that is a conversation we have as part of an engagement.

Need a tool that does not exist yet?

If the same friction keeps showing up in your team, it can usually be built away. Tell me where it hurts.