What Three Days in Seattle Taught Me About Building Software

I flew to Seattle alone.

Grand Charter was still early. We were building DearLegal, our case management platform, in close partnership with a workers' compensation firm headquartered in Philadelphia. The platform was taking shape -- intake flows, case tracking, the usual scaffolding of legal tech. Then came the Washington branch.

Same firm, different state. Same practice area, entirely different universe.

The three-body problem

There were three parties at the table: the Philly headquarters, the Washington branch office, and us. Each had a different mental model of what the platform should be, and those models were quietly diverging. Philly wanted features that mirrored their workflows. Washington needed something that fit a system Philly had never touched. And we were in the middle, trying to build one product that served both -- without fully understanding that "both" might be irreconcilable as a single workflow.

The tension wasn't hostile. It was the kind that builds slowly when people feel like their context isn't being accounted for. The Washington attorneys had been raising concerns, and those concerns kept getting filtered through Philly's lens before reaching us. By the time I booked the flight, what we needed wasn't a feature spec. It was a conversation.

A different kind of workers' comp

Here's something I didn't appreciate until I was sitting across the table from Washington attorneys: workers' compensation in Washington state is fundamentally different from Pennsylvania's. It's not just different forms or different deadlines. Washington runs a state-administered system -- the Department of Labor & Industries manages everything. There are no private insurers in the loop. The entire procedural framework, from how claims are filed to how they move through the system, operates on a different set of rails.

In Philadelphia, the workflow we'd built around was adversarial in the traditional sense -- carriers, claimants, attorneys negotiating. In Washington, the process is more procedural and state-driven. The filings, the board submissions, the checkpoints -- all of it follows a rhythm dictated by L&I rather than by negotiation between private parties.

Building one rigid workflow and expecting it to serve both was like writing a function that only works for one input type and wondering why it throws errors everywhere else.

Listening as engineering

I was in Seattle for three days. There was no single breakthrough meeting, no dramatic whiteboard moment. What happened was quieter than that.

I sat with the attorneys and listened. Not in the way you listen during a requirements gathering call, where you're mentally mapping what they say to Jira tickets. I mean actually listened -- to their frustrations, to the specific ways the platform was making their day harder, to the small indignities of using software that clearly wasn't built with their reality in mind.

What struck me most wasn't the technical gaps. It was how much it meant to them to feel heard. These were professionals who'd been flagging problems for months, watching their feedback get absorbed into a pipeline that didn't prioritize their context. Having someone fly out, sit down, and say tell me everything -- that mattered. I could see it in real time. The defensiveness softened. The conversations got more specific, more generative. They started telling me not just what was broken, but what they wished was possible.

That's where the real insights live. Not in bug reports, but in the space between frustration and imagination.

The modular turn

The trip crystallized something I'd been circling for a while. The problem wasn't that we'd built the wrong features. The problem was architectural -- we'd built a platform that assumed one workflow, one set of procedural assumptions, one way of doing things.

Every new firm we'd onboard, every new state we'd expand into, would bring its own procedural reality. Washington's state-administered WC system was just the first proof point. If we kept bolting on one-off customizations, we'd end up with a codebase that was really just a collection of ad hoc engineering solutions wearing a trenchcoat.

The answer was modularization. Not as a technical refactor for its own sake, but as a business model shift. The platform needed to be configurable at the firm level -- different workflows, different automation triggers, different procedural checkpoints -- so that onboarding a new firm felt less like a custom engineering project and more like a consulting engagement. Solutions architecture instead of ad hoc development.

This is still in progress. We're restructuring the platform and rethinking how we work with firms. But the direction is clear, and it started in Seattle.

Self-service as empathy

One of the tangible outcomes was identifying where self-service automations could absorb the most pain. The Washington attorneys were spending hours on tasks that followed rigid, predictable patterns -- L&I board filings, procedural submissions, report generation against known templates. These weren't tasks that required legal judgment. They were tasks that required a human to follow a checklist perfectly, every time, on deadline.

That's exactly where software should step in. Not to replace the attorney's thinking, but to handle the procedural machinery so they can focus on the parts of their work that actually require expertise and judgment.

Designing those automations well required understanding the Washington process deeply enough to know which steps are truly mechanical and which ones aren't. That understanding didn't come from reading documentation. It came from three days of conversations.

Empathy is an engineering skill

The conventional framing of "soft skills" in engineering has always felt backwards to me. Listening to a frustrated attorney in Seattle and translating their reality into a platform architecture decision -- that's not soft. That's load-bearing. It's the work that determines whether what you build actually serves people or just passes a code review.

The best engineering I've done hasn't come from clever abstractions or elegant algorithms. It's come from sitting with the people who use what I build and caring enough to understand their world before I start typing.

I flew to Seattle alone. I came back with a clearer picture of what Grand Charter needs to become.