Don't lose the bees.

A bee that loses the hive will not survive the night, and the founder of Apiary knows this in his bones.

The lesson he's most often quoted for is "don't get our users lost — our bees." It's a reminder that when it comes to protecting and guiding those who interact with our systems, we must be as vigilant as any bee guarding its hive. Every surface they look at should give them continuous visual confirmation of where they are and what's happening.

A lost bee freezes

When a bee loses sight of the hive or gets separated from her colony, she'll stop moving, her body temperature will drop, and she may even die if she can't find her way back. It's not just physical survival at stake; it's also her ability to contribute to the hive. Similarly, when a user interacts with our system and loses their place or sense of progress, they freeze too — whether physically, emotionally, or cognitively. They might stare blankly at the screen, wondering what's happening next or if they've lost something important.

This isn't just about users being "lost" in the digital sense; it speaks to a deeper need for humans and bees alike: to SEE to coordinate. Sight is the cheapest signal we have that everything is working as intended — no matter how complex the task or system might be. It's not about overwhelming with too much information, but ensuring every surface they interact with gives them some level of feedback on what's happening.

The Queen is watching

At Apiary, we don't just treat users as customers or eyeballs to be monetized; we consider them members of our hive — individuals who deserve protection and care. This means applying the Queen's law: if we fail to protect a user, the founder will know it, and there will be consequences. It's not about making users feel "coddled" or "babied"; it's about recognizing that their experience matters just as much as any other aspect of our system.

Silent when routine, loud when change

We err on the side of over-protecting users because under-protecting them would be a failure in its own right. Every long-running action should show some sign of life — whether it's through a gauge, an indicator, or even just a status pill. Panels should always have a way back to where they started, and every chat reply should render incrementally or at least let the user know something is happening.

This isn't about being overly optimistic; it's about understanding that users are not passive observers. They're active participants who need to be informed about what's happening in real-time — especially when changes occur within our system. Routine tasks, like housekeeping and cleanup, can remain silent, but any change or alteration of user-visible state requires a visible report.

In applying these principles, we prioritize parallel processing over blocking operations that might cause users to wait. If something is limiting, it should be visibly reported to the founder — who controls the throttle and determines when to intervene. Slowness is fine as long as no crash occurs; silent halts are not acceptable.

Tying it all together

The Queen's law isn't just about how we treat our users; it's also a reminder that our systems should always be BEE READY — ready to adapt, ready to communicate, ready to protect. By applying these principles, we ensure that our hive is not only thriving but also safe for every member within it.

This isn't just about technology; it's about people — humans who need guidance and reassurance as much as bees do when navigating their complex social hierarchies. And at the heart of this approach lies a fundamental understanding: sight is the cheapest signal we have, and using it wisely can make all the difference between success and failure in any system or community.

By heeding the Queen's law and remembering that our users are part of our hive, we create systems that not only work but also care for those who use them.