Features solve requirements. Experience solves problems.

Design Note

Design around a shared moment, not a video call.

The problem was never communication. Video calling already exists.

The challenge was helping grandparents and young children stay engaged together across distance.

Reading gives both sides a shared activity, keeps children present, and creates more meaningful interaction than trying to sustain a conversation with a three- or five-year-old over a video call.

Every product decision was made to protect that experience.

Parents can manage the account and content, while grandparents join through simple email magic links. During the call, participants shouldn't have to think about the technology at all. A parent familiar with the platform can handle setup, while grandparents can simply show up knowing the experience will work. In many cases, the only interaction required is clicking an arrow to turn the page.

That simplicity came from a personal frustration. When my family tried reading together remotely, small technical issues constantly interrupted the experience. A blurred camera filter, the wrong camera selected, FaceTime refusing to connect, or a book that wasn't visible would quickly turn into troubleshooting sessions. Every minute spent fixing technology was a minute children became distracted, lost interest, and disconnected from the experience.

The goal wasn't just to make the software easier to use. It was to remove technology as a source of stress for both grandparents and parents so everyone could focus on spending time together.

The goal wasn't to build a better video call. The goal was to make grandparents feel like they were sitting next to their grandchildren while reading a book.

Design Note

One conversation. Multiple outcomes.

Every sales call creates a predictable set of follow-up work:

• Send the client follow-up
• Share relevant collateral
• Update the CRM
• Create action items
• Capture commitments and next steps
• Provide visibility to leadership

The challenge isn't that this work is difficult. It's that salespeople end up repeating the same information across multiple systems.

The conversation already contains everything needed to complete those tasks.

Summa was designed around a simple idea: capture the information once, then let users decide where it should go.

Need a follow-up email? Review the draft and click Send.

Need CRM updates? Review and click Update.

Need personal tasks? Push them to Google Tasks with a click.

Instead of asking users to recreate the same information over and over, Summa turns a single conversation into the outputs they already need.

One call. One transcription. One click for everything else.

Design Note

Make radio programming feel approachable, not technical.

Most radio software assumes users want to understand tones, offsets, duplex settings, memory layouts, and radio terminology.

The reality is that many people program a radio a few times per year and forget most of those concepts in between.

Every time they return, they're forced to relearn information that isn't actually important to their goal.

TxR was built around the idea that users should think about where they want to communicate, not how radios store configuration.

Guided setup flows, RepeaterBook integration, and sensible defaults remove unnecessary decisions and reduce the amount of radio-specific knowledge users need to carry.

The browser-first architecture follows the same philosophy. Programming a radio shouldn't require installing, updating, and maintaining another application for a task you may only perform occasionally.

Just as importantly, radio software doesn't have to feel like a spreadsheet. Powerful tools can still be intuitive, visually appealing, and enjoyable to use.

The goal wasn't to expose every radio setting. The goal was to help people confidently program a radio without feeling like they needed to become radio experts first.

Design Note

Design security around enablement, not gatekeeping.

Too much of the industry treats governance, risk, and compliance as a function that slows the business down. Controls become checklists. Engineers receive requirements without context. Security teams become known for saying "no."

I wanted to challenge that mindset.

A good GRC practitioner shouldn't be translating control language into tickets and throwing them over a wall. They should understand the intent behind the control, work with engineers to design practical implementations, and help make the secure path the easiest path.

The best controls are often the ones users barely notice.

The same philosophy applied to the podcast itself.

Many GRC conversations sound insightful in the moment but remain entirely theoretical. Listeners walk away understanding a concept without knowing how to apply it.

The goal was to focus on implementation instead:

• What was the original manual process?
• What made it painful?
• What was automated first?
• How did the process evolve over time?
• How were engineering relationships improved?
• What specific actions could someone take tomorrow?

Every episode aimed to leave listeners with something practical they could implement immediately, not just another framework to memorize.

The goal wasn't to teach people how compliance works. The goal was to show how good GRC can remove burden from both the business and the engineers building it.

Design Note

Design around consistency, not perfection.

Many people want a deeper prayer life, but daily life has a way of getting in the way.

I found myself wanting to pray the full five-decade Rosary, but often struggled to dedicate twenty uninterrupted minutes. Some days I became distracted. Other days I felt too restless to sit still. Over time, it became easy to fall into an all-or-nothing mindset: if I couldn't complete the entire Rosary, I would skip prayer altogether.

Everyday Chaplet was designed to remove that burden.

The single-decade bracelet serves as a reminder that prayer does not need to happen in perfect conditions. While it can be used to pray a full decade, there is no expectation that every prayer session be completed. Some days may be a full Rosary. Some days may be a decade. Some days may be a single Our Father or a few Hail Marys between meetings, errands, or responsibilities.

The goal is to make prayer feel accessible rather than intimidating.

The physical design was intentional as well. I noticed many free rosaries were functional but easily forgotten in a drawer or left behind. Everyday Chaplet uses natural stones and thoughtful color combinations to create something people genuinely enjoy wearing, increasing the likelihood that it stays visible throughout the day and continues serving as a reminder.

Each bracelet includes a QR code that guides users through the prayers and provides simple instruction for those who may be new to the Rosary or unsure whether they are "doing it correctly." Rather than expecting someone to research prayers, structure, or traditions on their own, the guidance is available exactly when they need it.

Every design decision was aimed at reducing barriers to prayer: making it visible, making it approachable, making it beautiful enough to wear, and removing the pressure to do everything perfectly.

The physical rosary—the product—was not the goal. The goal was to remind people that every moment spent in prayer has value, and that a small step toward God is better than waiting for a perfect moment that never comes.