Lessons from building in legal tech

Legal tech is easy to underestimate from the outside.

People imagine document workflows, approvals, and enterprise software complexity. That is all true, and it still misses the real constraint: legal work has a low tolerance for ambiguity and a high cost of unforced error.

I have spent most of my product-engineering career in this space at SpotDraft, first as a software engineer, then as a senior engineer, and now as Engineering Manager for Integrations and Platform. The work taught me to treat precision as a product feature, workflow as architecture, and integrations as something that should become a platform rather than a pile of customer-specific jobs.

Details are not edge cases for long

In legal workflows, the unusual path is often the real path. A clause exception, a third-party paper flow, a customer-specific approval, an audit question — these are not polish. They are the product.

That changes how you should design.

When I built the self-serve questionnaire experience for template workflows, the temptation was to optimize only for the happy template path. The more durable move was to extend the same foundation to third-party paper without a destructive rewrite, then grow Workflow Manager on top of that broader workflow foundation.

You pay for that generality once. You pay for the narrow design every time the next “exception” arrives.

The same instinct showed up later in integrations. Reverse sync could have been a Salesforce-shaped shortcut. A reusable automation model — triggers, conditions, object mappings — is slower at the start and cheaper every time the next enterprise surface appears.

Configuration needs guardrails

Legal users need flexibility. They also need the system to stop them from creating a state nobody can explain six months later.

That is an engineering problem disguised as a product preference. Unbounded configuration becomes untestable. Over-constrained configuration becomes shelfware. The useful design sits in the middle: enough structure that the workflow is inspectable, enough flexibility that real legal work can happen.

Auditability belongs in that same middle. If a contract, questionnaire answer, or integration mapping changed, someone will need to know what happened. Cleverness that cannot be reconstructed is a liability.

Clarity beats cleverness in high-stakes workflows. I would rather ship a boring, explainable path than an elegant one that only the original implementer trusts.

Execution is part of the product

Legal Intake started as a 2024 hackathon idea and became a shipped product. The product lesson was obvious: there was demand. The engineering-leadership lesson was sharper: high-context legal products fail when execution lives in people’s heads.

I introduced spec-first planning, phased milestones, explicit ownership, visible risk tracking, and reusable planning templates. Those mechanisms sound like process. In this domain they are safety equipment. You cannot improvise a workflow product the way you might improvise a internal tool.

Hackathons still matter. For the last two years I have helped organize SpotDraft’s company hackathons, which is how Legal Intake began. Good legal-tech organizations need space to try ideas that do not start on the quarterly roadmap. They also need a delivery system that can take a prototype seriously without pretending the prototype was already a product.

Enterprise integrations are trust work

Legal buyers do not live only in your app. They live in Salesforce, HubSpot, procurement tools, Slack, and a long list of systems of record.

Native integrations are not a side quest. They are how trust moves between systems. If the integration is a one-off, the customer’s operating reality becomes your on-call reality.

Platform thinking here is practical, not ideological: public APIs, documentation, developer portal, reusable sync and automation primitives. Reduce the amount of context that has to travel through Support, TPMs, or a single engineer who remembers how the last customer was wired.

What transfers outside legal tech

The domain is specific. The lessons are not:

• treat repeated exceptions as a signal to change the model, not to add another if-statement
• make workflows inspectable
• prefer reusable primitives over customer-specific heroics
• engineer the delivery system, not only the feature
• remember that user trust compounds slowly and breaks quickly

Teams building in this space learn to respect process without worshipping it. The best software helps professionals move faster while remaining confident in the result.