Almost every agreement I see in Kuwait is made across three tools that do not talk to each other. The draft arrives as an email attachment. The negotiation happens in WhatsApp. The signature is a printed page, signed, photographed and sent back. Each step works. The sequence does not, because nothing in it remembers what was agreed.
The problem
Ask two parties three months later which version they signed and you will often get two different answers, both sincere. The file was called Final. Then Final-2. A clause was changed in a message that nobody carried back into the document. The scanned signature page proves somebody signed something, and not which something.
This is not a legal problem. It is a version-control problem wearing a suit, and it is the reason small disputes here are expensive out of all proportion to the amounts involved.
What it is
TOTHIQ is an agreement workflow: choose a template, discuss it, approve one version, sign it, and keep the record. Four steps, one place, in Arabic or English. It is built for individuals and businesses across the GCC and is launching in Kuwait, Saudi Arabia, the United Arab Emirates, Qatar, Bahrain and Oman.
The product is not the signature. Plenty of tools will collect a signature. The product is that the thing signed is unambiguous, and stays unambiguous.
Why the template has to be reviewed locally
Generic contract templates circulate freely and most of them were written for a different legal system. They carry assumptions about notice periods, termination, jurisdiction and payment that do not match how business is actually done here.
Starting from a locally reviewed template is the least glamorous decision in the whole product and the one that removes the most risk. It means the first draft is already close, so the negotiation is about the two or three terms that genuinely differ rather than about repairing boilerplate nobody read.
The hard part is one version, not many
The engineering problem worth solving is that everyone must be looking at the same document while still being able to change it.
Comments are anchored to the clause they concern, not floating in a thread. A proposed change is an exact change, visible in place, accepted or rejected. When the parties approve, the version locks. From that point there is one document, one state, and a record of how it got there.
Discussion belongs on the clause
The reason agreements drift is that the conversation and the document live apart. A question about the delivery date in a schedule is asked in a chat message, answered in another, and the schedule itself is never touched.
Putting the discussion against the clause changes the default. The question is attached to what it is about, and resolving it means editing the thing rather than remembering the answer. It sounds like a small interface decision and it is most of the value.
Signing is the easy part. The record is not.
A drawn signature on its own is decoration. What gives it weight is everything attached to it: which account signed, which verified email that account holds, which exact version of the document was in front of them, and when.
Those four things are bound together at the moment of signing and kept together afterwards, along with the consent and the transaction history. That bundle is what you actually need eighteen months later, and it is the part most electronic signature workflows treat as a side effect.
What it demonstrates
Three things I care about in any system I build. That the trustworthy version of a process usually costs about the same as the untrustworthy one, and the difference is design rather than budget. That Arabic and English have to be equal at the data level, not a translation layer over an English product. And that the useful unit in a workflow is not the document but the evidence around it.
Where it is now
The platform is in build and launching across the GCC. The public site describes the process, the signing model and the record it keeps.