Sign42

The problem worth solving

Upload a document, place fields, send a link, collect a binding signature, deliver the executed file to everyone. That part is table stakes, it is built, and it is not a reason for anyone to switch.

The problem worth building for is narrower. A company paying independent contractors pays each type at different rates for different line items. The rates are not the contractor's business. The only variable the contractor supplies is how many of each thing they did.

That is usually solved with a separate web form per contractor type, a spreadsheet behind it, and a person reconciling the two at the end of the month. Sign42 turns it into one signable document that calculates itself.

What the document does

The invoicing behavior is switched on by an account attribute, so an ordinary signature user never sees it. When a user who has it reaches document preparation, the field palette gains a product system.

• Add Product opens with one blank row: a description and a price or value, both required before the row saves, and no new row while a blank one is open. That small piece of discipline is what keeps a rate table from filling with half-entered lines.
• Rows become a product list, enumerated in a Select Product dropdown on the document itself.
• Selecting a product makes three tags placeable: Quantity, Description and Total. Description and Total derive from the product. Quantity is the one thing the signer fills in, and Total calculates per line as quantity times the stored value.
• A fourth tag sums every total. It sits on the palette always and stays inert until a product is placed.
• The value behind each line is held by the sender and never rendered to the signer. Prepared documents save as reusable forms, because the same form goes to the same contractor every month and to each new contractor of that type.

How it is built

A web application with a document preparation canvas, a recipient signing surface that runs in a plain browser with nothing to install, cloud document storage, and an account model that carries feature attributes. The product and calculation layer sits between the form template and the signing session, so calculated fields are evaluated on submission rather than trusted from the client. Name, date and signature fields work as they do on any document.

State today, and what we are looking for

Finished and unlaunched. There is no customer, no reference and no case study behind this page, and we are not going to imply one. The naming is consolidating onto ESign42 across the application, and we hold both the .com and the .net domains.

What the product needs is a first customer: a company that pays contractors this way, that will run real invoices through it and say plainly where it is wrong. The consumer version comes after that, not before it.