Unity systems · editor tooling · integration
I build and repair the connective tissue inside existing Unity projects: Odin inspectors, custom editor tools, package integrations, system architecture, procedural systems, and difficult bugs. The goal is not to rewrite your game. It is to make the part you hate working in understandable, maintainable, and useful.
Services
Most Unity work does not need another generalist promising to “help with the game.” It needs a specific part of the project understood well enough to improve it without creating three new problems. These are the kinds of bounded jobs I take on.
Turn dense components and ScriptableObjects into an editor experience that matches how the system is actually used.
Replace repetitive project work with tooling designed around the actual production workflow.
Make a third-party tool behave like part of your project instead of a foreign system bolted onto the side.
Clean up the seam between systems when the individual parts work but the project around them has become fragile.
For bugs that survived the obvious fixes, regressions with unclear causes, and project states you no longer trust.
Build or extend systems where generated content has to remain deterministic, persistent, measurable, and connected to gameplay.
Concrete examples
The useful question is not whether I know a technology name. It is whether I can see the workflow around it, identify the correct seam in the project, and build the missing piece without making the rest of the codebase pay for it.
A complex system should not require memorizing which six fields across three components matter.
Installation is not integration. The work is deciding what the package owns, what your project owns, and how they communicate.
A visible bug is often only where a deeper ownership or representation problem becomes noticeable.
Sometimes the right deliverable is not another feature. It is the adapter, validator, editor, state layer, or debug view that makes the feature operable.
Sprucebound tool · Unity Editor
SBCheckpoint is a local safety instrument for Unity Version Control. It watches the shape of pending work, explains when protection debt is building, and helps you checkpoint before a useful experiment becomes a recovery job.
How I work
The fastest implementation is often the one that avoids creating cleanup work later. I start by finding the ownership boundary, the workflow, and the smallest intervention that can actually hold up.
Identify the owning scripts, data, packages, dependencies, current workflow, and what the finished behavior needs to feel like.
Decide where the change belongs, what should stay untouched, and whether an existing tool solves the job better than custom code.
Implement the inspector, editor, adapter, system change, prototype, or fix without quietly expanding the scope into the rest of the project.
Test against explicit acceptance criteria and leave source, setup notes, limitations, and the maintenance boundary clear.
About Sprucebound
My name is Matthew. I’m a first-principles thinker, outdoors enthusiast, optimizer, designer, and systems builder. I tend to get interested when the obvious solution is inefficient, overcomplicated, or built on assumptions nobody has revisited.
I genuinely enjoy efficiency: finding wasted motion and unnecessary complexity, then rebuilding the problem around clear ownership, useful constraints, and how people actually use the system. In Unity that turns into editor UX, integrations, architecture, procedural systems, debugging, and tooling.
Sprucebound is where I apply that mindset professionally. SBCheckpoint is the first Sprucebound tool moving through the Unity Asset Store, while service work lets me apply the same thinking inside existing projects.
FAQ
Yes. A single ugly Inspector, a custom editor window, one package integration, a validation tool, or a focused debugging problem can be a complete engagement. Small, well-bounded jobs are often the best fit.
That is the point of most of this work. I first map the relevant ownership and dependencies, then choose the smallest stable seam for the change. If the existing architecture makes a targeted implementation unsafe, I will explain that before expanding scope.
Yes. I can design and wire Odin-based authoring workflows into projects that already have the appropriate Odin package/license, including validation, groups, conditional UI, actions, previews, and project-specific controls. I do not redistribute Odin itself.
Not for the first conversation. Screenshots, short videos, package information, selected scripts, logs, and a description of the current workflow are often enough to define the scope. Repository access is discussed only when the work actually requires it.
Open-ended “build my whole game” contracts, emergency on-call support, art/audio production, guaranteed launch outcomes, and jobs where the requested result cannot be defined well enough to verify.
Have a Unity task?
You do not need to write a formal specification. Show me what you are working with, what feels wrong or slow, and what you wish the finished workflow or system did instead.
