Contracts. Herded. — why an attorney built Pishik

Pishik exists because of a specific, unglamorous kind of pain. Not the negotiation — negotiation is the interesting part. The routing. A contract that has finished being drafted and is now just… circulating. Forwarded attachments. "Is this the current version?" A reviewer on vacation nobody knew about. An approval given in a hallway that never got written down anywhere.

Pishik was built by an attorney who lived inside that loop for years — built by an attorney, for every team that touches contracts. And the lesson from those years wasn't that legal teams lack software. It's that contract tools keep failing for the same reason: they ask the wrong people to change.

The people who won't adopt your tool

The team that runs contracts will adopt a tool. They feel the pain daily; they'll learn a board, a workflow builder, a settings page. But most of the people whose approval a contract actually needs — the finance lead, the department head, the outside adviser — touch a contract a few times a quarter. They will not create an account for that. They will not install anything. They will not remember a password. And the more senior the reviewer, the more true this gets.

Every portal-shaped review tool quietly assumes those people will log in anyway. They don't. The contract goes back to email, the tool becomes a place where reality is retyped after the fact, and eventually someone stops retyping.

Two stubborn facts

So Pishik started from two facts that no amount of product ambition was going to move:

• Reviewers live in email. It's the one tool every reviewer already checks, already trusts, and already knows how to use.
• Documents already live somewhere good. Your contracts sit in SharePoint, OneDrive, or Google Drive — with permissions, version history, and the commenting and redlining your team already knows.

A review tool that fights either fact loses. Pishik fights neither. What was actually missing was never a place to put documents or a way to edit them — it was the herding: who has it now, who's next, who's slow, and what got decided.

What staged review by email looks like

You build the flow once: stages that run in order — Legal, then Finance, then final sign-off — with one or more reviewers in each stage working in parallel. Multi-part contracts can route each document to the person who owns it, so Legal reads the main agreement while Finance reads the pricing exhibit.

When a stage becomes active, Pishik emails each reviewer a personal link. They open the document where it already lives, comment and redline in the editor they already use — with the rights your share link grants — and approve or reject from the email. Nothing is recorded until the reviewer confirms. When the last reviewer in a stage approves, the next stage is emailed automatically. Nobody chases, nobody retypes, and the record writes itself: a board that moves its own cards, a flow map, a log of every email sent, an audit trail of every decision.

That's the whole idea. The product tour walks through it moment by moment, and if you're a reviewer who just received one of our emails and is wondering what this thing is, this page is for you.

Why "herded"

We say Contracts. Herded. because that's the actual job — not drafting, not signing, but keeping a group of independent-minded things moving in the same direction without losing any of them. And yes, our mascot is a cat. We're aware of what herding cats means. That's rather the point.

Why the beta is invite-only

Pishik is in private beta, and access is by invitation on purpose. We're a small team building a product that sits next to confidential legal work, and we'd rather onboard a modest number of teams carefully than a large number badly. There's no automated waitlist: we review requests and email you a single-use invite code. The beta is free while it runs, and the same care applies to how we handle your data — the security page explains that architecture in plain terms, starting with the part we're proudest of: your documents never touch our servers.

If contract routing is a pain you recognize, we'd like to hear what your flow looks like.