Logo Mark
img1

Project Story — glassbox

Why We Built This

This project came from a very real problem we kept running into: group projects falling apart in slow, quiet ways.

Files were scattered across drives and chats. Decisions were made in meetings and then disappeared. A week later someone would ask, “Why did we build it like this?” and the honest answer was… nobody knew anymore.

We’ve used tools like Jira before, and while they’re great at tracking tasks, they don’t capture thinking. They tell you what is done, not why it was done. That gap is what pushed us to build glassbox.

We wanted one place where all the work — ideas, execution, and results — could live together. A collage of everything the team has done, not just a checklist.

The Idea Behind glassbox

At the heart of glassbox is a simple idea: work should be inspectable.

Every task becomes a node that records:

Intent — what were we trying to do?
Execution — what did we actually build or try?
Outcome — what happened in the end?

Instead of opaque results, you get a traceable chain:

This makes it easier to understand past decisions, reuse workflows that worked, and trust the final output — especially when multiple people are involved.

How We Built It

We built glassbox the same way we wish group projects actually ran: clearly divided and accountable.

We split the system into separate responsibilities:

One person focused on the frontend, shaping how tasks and relationships are visualized
One handled the backend, APIs, and data flow
One worked on Solace, setting up event-driven communication
One integrated Sentry so errors didn’t quietly break everything

Each part was developed independently at first. Once everything existed, we connected the pieces and spent a lot of time aligning assumptions, fixing integration bugs, and reworking designs that didn’t survive real usage.

What We Learned

Building glassbox taught us that:

Organization problems scale faster than code complexity
Splitting work by ownership prevents chaos
Observability isn’t optional — if you can’t see failures, you can’t fix them
Event-driven systems only work well when the whole stack is designed around them

Challenges We Faced

Some problems were technical, others were just painful:

AWS access issues
Changing AWS user groups triggered an automated AMS notice that temporarily blocked our usage. Development stalled instantly, reminding us how fragile cloud access can be.
Solace integration friction
Connecting Solace cleanly between the frontend and backend wasn’t smooth. The mental model didn’t fully line up at first, which forced multiple redesigns.
Putting it all together
Every component worked on its own. Making them work together was the hardest and most time-consuming part.

Looking Back

glassbox is our response to messy collaboration.
It doesn’t just show progress — it shows reasoning. It keeps decisions visible, work traceable, and teams aligned even as projects grow.

We built it because we needed it, and because we were tired of losing context in our own work.