About Artisan
An engineering lab structured for the way good tools actually get made.
Artisan Technologies is the R&D division of Wavelet Solutions LLC. It exists because the engineering tools that pay back over years aren't the ones a single client engagement can fund. This page explains how the lab is structured to do that work, what comes out of it, and where it sits in the larger company.
The design
What this division is for.
Most useful engineering tools share a profile: they take longer to build than a single project can justify, but they pay back across many. The kind of tool that takes a month of focused work and saves an hour every week for years.
A typical consultancy can't build them. There's no client whose budget covers a tool that lives across all clients, and no week with enough open time to do the work patiently. The tool either gets shipped half-built — embedded in one project's codebase, never extracted — or it never gets built at all.
Artisan is the structural answer. A separate division, with its own time and its own ledger, where that work happens at the cadence the work actually needs. The output flows in two directions: into Pulse Engineering's client engagements as proven IP and patterns, and outward as public tools anyone can use.
The lifecycle
How a tool moves through the lab.
Three stages. Most projects spend the longest time in the middle stage, where the work is patient and unhurried. The first and last stages are short, but they're where the boundary conditions of the tool get set.
Observed need.
A tool earns a slot in the lab when an engineer notices, on real work, that the tool that would have made today's job an hour instead of a week does not yet exist. That observation is the entry point. Without it, no project starts.
Patient development.
The tool gets built without a deadline. The first version is rarely the shipped version — most projects go through three or four passes before the design clarifies. There is no pressure to ship early. The pressure is to get it right.
Released and in use.
A tool ships when an engineer can use it for real work without being ambushed by what it doesn't yet do. The form varies — a public Git repo, a library, a CLI, sometimes a dedicated domain when the project warrants the cost. Limitations are written down and visible. The tool gets a real home; what shape that home takes depends on the tool.
The bridge
How the work crosses over.
R&D operates outside the regulatory and process frameworks that govern client work. No DO-178C. No ISO 9001. No compliance reviews holding up an experiment. That's deliberate. The "figure-it-out in the garage" mode is what makes the lab productive in the first place. A tool that has to satisfy a customer quality system before it can exist takes ten times as long to build, and most of them never get built.
But the freedom comes with a constraint: a tool that ships under Artisan is not automatically usable on a Pulse client engagement. The lab's freedom is exactly what means the tool needs hardening before it can cross over.
The transition work is its own discipline. Documenting against the customer's quality system. Adding traceability and test coverage at the level the regulation requires. Proving behavior under the operating envelope the client actually cares about. Sometimes adapting the tool for a constrained environment the lab didn't have to think about.
This work happens on the Pulse side of the line, with its own time and budget, separate from the R&D effort that produced the tool. Treating it as just-as-important as the R&D itself is what keeps the two divisions connected. Without that bridge, the lab's output piles up in a corner that client engagement work can't reach — and Pulse ends up rebuilding what Artisan already made. The two divisions drift into two companies in one. The bridge is what prevents that.
Principles
What shapes the work.
Four principles, in the order they show up. Each is specific enough to be falsifiable — you can point at a project and check whether it's been honored.
Build the tool you wish existed.
Most Artisan projects start the same way: a frustration during real work, followed by the realization that the missing tool is buildable. The lab gives that engineer the time to build it — on the principle that if it would have helped them, it will help others. No market research. No persona work. The starting point is the engineer's own observed pain.
Ship when it's honest about its limits.
"Done" is asymptotic; tools are never done. The shipping criterion is different: a tool ships when someone using it for real work won't be ambushed by what it doesn't yet do. Limitations are written down and visible. Polish continues after release.
Don't oversell.
If a tool is in development, it's marked in development. If it has limitations, they're named. If it's a pattern we've solved twice but never extracted into a tool, that's how it's described — not promoted to "product." The catalog tells the truth about state. Trust costs nothing to maintain when nothing is overstated.
Plain formats. Long-lived choices.
TOML and Markdown over proprietary serialization. Git over custom version control. Boring battle-tested languages over the framework of the month. The tools made here should still open in a useful editor in a decade — and the decisions about how they store data shouldn't be the thing that breaks them.
Where it sits
The structure, plainly.
Artisan does not exist on its own. It's a division of a larger thing. Here is how the parts fit together:
Artisan and Pulse are tightly coupled by design. Artisan's R&D output flows into Pulse's client engagements as proven IP. Pulse's client work surfaces problems that become Artisan's next research direction. Both feed into Nexus when there's curriculum or student-facing work to be made from what got built.
Who runs it
A small team. Mostly one person, for now.
Artisan is currently a vehicle for the technical leadership of Wavelet Solutions to do focused engineering work. The structure is built to scale; the current scale is intentionally small. As the practice grows, more engineers will contribute to Artisan's projects directly.
For inquiries about the work shown here — collaboration, licensing, technical questions — the right path is through Wavelet Solutions: waveletsolutions.com. Artisan does not maintain a separate inbox.
Lab notes
The work, in writing.
Short-form writing about the work in progress — design rationale, the failures before each project converged, technical asides that don't fit on a project page. Updated when there's something worth saying.
Read the notes →