Lessons
What Building Tonic Taught Me
A lot of the work behind Tonic does not turn into a clean case study. Some ideas were technically interesting but hard to explain. Some worked in demos but not in real workflows. Some were good instincts wrapped in the wrong product shape. A lot of it ends up in the graveyard.
I still think that work matters. The abandoned prototypes, awkward pivots, unclear positioning, and half-right assumptions are part of how I learned what to build next. They do not always present well, but they shaped my judgment.
These notes are a place for that kind of learning: the lessons that do not fit neatly into portfolio pieces, but explain the effort it took to get to the current shape of the work.
Product before services
Building product first taught me that the wrong abstraction can harden before the workflow is understood.
Switching toward services first was not a retreat from product. It was a way to stay closer to the real shape of the work before committing too much structure to software. The product gets better when the service work reveals what people actually need repeated.
Teaching AI
TAing an AI class made the abstraction problem more obvious.
Teaching showed me that people do not only need more tools. They need better mental models for what AI is good at, where it fails, and how to reason with it responsibly. That pushed me toward explanation and inspectability as design requirements.
Research tools
A research tool can be technically promising and still get stuck if the surrounding method is unclear.
Building for academic work taught me that the tool is only one part of the system. If ownership, review habits, data practices, or the research workflow are not clear, the software has nowhere stable to land.
Interns and clarity
Ambitious people need a clearer operating system than enthusiasm.
Hiring interns before the structure was ready taught me that delegation is its own product. People need context, constraints, examples, feedback loops, and a well-shaped problem. Energy is not enough if the work has not been made legible.
Vertical focus
Going to everyone made general clarity harder; verticals made the work sharper.
Broad agentic infrastructure can be intellectually appealing, but it asks customers to do too much translation. Focusing on verticals gives the work a clearer language, clearer constraints, and a clearer definition of value.
Delayed economic consequences
Not everyone is optimizing for profit, even inside systems where profit matters.
Some people are trying to keep their job, protect a process, preserve craft, avoid risk, or maintain a way of working that gives them identity. The economic consequences of better software can be delayed, indirect, or misaligned with the person using it. Adoption depends on that human reality.
Presence and trust
Competence matters, but it is not the only thing that drives success.
I like learning in isolation because it helps me build without distraction. But building a company also requires presence. Self-trust and social trust develop differently, and both matter. People need to see not only that I can make things, but that I can stay close to them while the work is becoming clear.
Scope creep
Loving to build is useful, but building more is not always the priority.
It is easy for me to see the next capability, the better abstraction, or the cleaner version of the system. That instinct is valuable, but it can also pull energy away from the immediate question: what needs to be true for this to work for someone now? Scope has to earn its way in.