Building Great Software That Happens to Solve Legal Problems

Why Legal Hasn’t Had its “Linear Moment”

We’re a small team in Brooklyn. Most of us are engineers, but everyone ships. We have four lawyers—three of whom write code every single day.

We argue about latency, visual hierarchy, and whether something feels obvious enough. We like to spend too long on the details.

This probably sounds idealistic. Maybe it is. But I’ve watched developers get tools like Linear and Cursor—products so well designed they change how you think about work itself. Legal professionals deserve the same. And the only way that happens is if you build with the same level of craft.

At Sandstone, a lot of our product philosophy comes down to four values. Not as slogans on a wall, but as constraints we use to make decisions when things get hard.

1. Creativity lies in simplicity (make complex things simple)
2. Try sh*t quickly
3. Everyone ships
4. Build relationships with customer problems

1. Creativity Lies in Simplicity

Most legal software assumes complexity is inevitable, and then builds UIs that mirror that complexity back to the user.

We’ve learned the opposite. Complexity exists, but it doesn’t need to be visible.

On customer calls, we’ll watch a lawyer open Salesforce, then a CLM, then dig through an old email thread, then pull up a playbook, then Slack someone for context—just to answer a single question. None of that work is “legal judgment.” It’s just assembly.

Our job is to eliminate assembly.

When something is well-designed, it doesn’t announce itself. The right information is just there. The next step is obvious. You don’t think about the tool. You think about the decision.

That’s the hardest kind of creativity: taking something deeply complex and making it feel calm, lightweight, and intuitive. It’s also the bar set by the best modern tools. Legal shouldn’t accept less.

2. Try Sh*t Quickly

You can’t design your way to great software in theory. You have to feel it.

We move fast—not because speed is a virtue on its own, but because feedback is the only thing that matters. We’ll ship something rough, watch how it breaks, and fix the parts that feel wrong. Not the parts that look wrong in a mockup… the parts that feel wrong in use.

One customer asked if we could automatically analyze linked documents inside contracts. We built it in a day. Not because we had a perfect spec, but because the intent was obvious: fewer steps, less mental overhead.

Speed isn’t about recklessness. It’s about respecting reality over planning. Every extra week you spend debating is a week you don’t learn what actually matters.

3. Everyone Ships

This isn’t a spectator sport.

Our lawyers ship. Our engineers think about UX. Our GTM team builds internal tools. I still write a disgusting amount of code because it’s the fastest way to stay honest about the product. When you build it yourself, you feel the latency. You notice the awkward transition. You see where something that felt elegant on paper falls apart in practice. I almost can’t use our product without coding because of things I want to adjust.

When we hire, we don’t optimize for pedigree. We ask people to show us something they built and care about. The best candidates talk about users first. They talk about tradeoffs. They have opinions.

Legal tech has been dominated by tools designed by committee: safe, bloated, and disconnected from the people actually doing the work. We think taste matters. Ownership matters. Shipping is how you develop both.

4. Build Relationships With Customer Problems

As builders, we’re opinionated about being close to the work. We talk to customers constantly, and it's often informal and unstructured. We ask them to always screen-share. We’ll watch someone fumble through a flow we thought was obvious. And when that happens, we don’t explain the product better, we change the product. Last week we changed a perfectly fine auth flow because we saw a user struggling to understand magic links.

We also use Sandstone aggressively ourselves. Not in a demo environment, but for real decisions, real documents, real pressure. If something feels slow, awkward, or mentally taxing for us, it’s guaranteed to feel worse for a legal team juggling twenty things at once.

When you build this way, priorities become obvious. The noise falls away. You stop guessing.

And that’s the difference between building software for users and building software with them

Why This Matters

Tools like Linear didn’t win because they had more features. They won because they respected their users. They were fast, opinionated, and built for the people doing the work, not just the people buying the software.

Legal hasn’t had that moment yet. But it will.

AI makes it possible. Craft makes it inevitable.

We’re not trying to build legal software. We’re trying to build software so good that legal professionals finally get the tools they deserve.

That’s what we’re doing at Sandstone.