I'm Addie, a developer and maker working across websites, maps, stories, and hands-on projects. I like practical problems, unlikely connections, and ideas worth following.
I like understanding how things work, then imagining how they could work differently.
Sometimes the result is a website. Sometimes it is an automated workflow, a restored piece of furniture, an online radio experiment, a fictional archive, or a field project involving questionable Ontario bureaucracy.
Root is research, place, structure, ecology, context, systems thinking, and the foundations that let an idea survive contact with reality.
Render is code, design, writing, fabrication, interaction, sound, and the craft of turning an idea into something another person can actually experience.
My work moves between technical systems and creative ones. I don't find the boundary between them especially useful.
I can spend part of a day thinking about databases, mapping, automation, or interface architecture and another part thinking about a story world, a piece of furniture, local history, sound, or what a field tool would feel like if it borrowed ideas from a Pokédex.
Experimenting makes me a better developer. Working with real data keeps my ideas grounded. Making things by hand changes how I think about designing for people.
I am interested in work that is useful, specific, a little alive, and made with enough care that people can feel somebody was paying attention.
Good solutions start with the actual environment, people, constraints, and behaviour around a problem—not the tool I happen to want to use.
Beauty matters, but usefulness earns trust. A thing should make somebody's work, understanding, experience, or day meaningfully better.
Nature is more interesting than “make it green.” Adaptation, layers, feedback, seasonality, resilience, variation, and interdependence are design ideas too.
Experiments are not a failure of focus. They are how the studio develops new skills, visual language, ideas, and occasionally whole new projects.
The Lab stays open because unfinished thinking, build notes, mistakes, and changes of direction are often more useful than pretending everything arrived fully formed.
Client work should not create dependency for its own sake. Clear systems, documentation, and understandable handoffs are part of the design.
Have something in mind? I'd love to hear about it.