Bringing contracts into Wintertrace — a module in the works

So far, most of what I’ve written about Wintertrace is about the work itself: a driver clears a site, the phone records where and when, the weather is pulled from an independent source, and the whole thing comes out as a service proof you can hand to a property manager or an insurer. That part is solved. It does what it set out to do.

But documenting the work is only half of running a winter service. Before any of it happens, you need customers. And customers, sooner or later, mean paperwork.

The other half of the job

Some jobs get done on a handshake. Plenty don’t. A property manager wants terms in writing; a larger site wants a proper agreement with a defined scope; a one-off wants something simple. Sometimes you need a signature, sometimes you don’t. And when you do need one, that signature is its own small project — print it, drive it over, wait, chase it up, file the copy somewhere.

So you end up with two worlds. The proof of work lives in Wintertrace. The contracts live in a drawer, an email thread, or some signing tool you pay for separately. When a question comes up months later — what did we actually agree?, is that included? — the answer is in a different place from the records that show what you did.

I kept running into the same thought: why two places? The work and the agreement behind the work belong to the same customer. They might as well sit together.

That’s the module I’m building now. It’s in development — not something you can install today — but it’s far enough along that it’s worth describing honestly, including the parts I’m still hardening.

Part one: contracts in one place

The first half is the unglamorous, useful one.

If you already have contracts — signed PDFs, agreements drawn up by your own lawyer, whatever you use — you upload them and assign each one to a customer. That’s it. The contract now sits next to that customer’s operations and service proofs.

The customer sees the same documents in their customer portal. Both sides are looking at the same agreements, not two copies that drifted apart. The “what did we agree?” phone call and the “is that in scope?” email get shorter, because the document is one click away for everyone who’s party to it.

No signing service involved here, no third parties — just a place to keep the agreement where it belongs.

Part two: signing, built in

The second half is for when you need a signature and don’t want to leave Wintertrace to get one.

You draft a contract inside Wintertrace, either from a template or by typing your own text. Then you say who needs to sign: just the customer, or the customer and you, or a third party as well — a building manager or a facility manager, say. For each signer you give a name, an email address, and a position. That’s the whole setup.

From there, the document travels — and where it travels is the part I want to be precise about, because it’s also where the data-protection design lives.

How a signature actually travels

When a contract goes out for signing, it follows a fixed path:

1. You install the module and confirm the terms of use, the privacy notice, and a data processing agreement (DPA), then register for the service — free of charge.
2. The module fetches an API key from the NoSchmarrn.dev API. (NoSchmarrn.dev is the developer behind Wintertrace.)
3. You draft the contract and choose the signers.
4. The contract is handed to the API, which passes it to a dedicated signing service built for exactly this job.
5. The signing service prepares the PDF for signature and returns a signing link, back through the API to your Wintertrace installation.
6. Your installation emails the parties and invites them to sign.
7. A signer opens the link and confirms their email address.
8. They sign, and confirm three things: that they’ve read and understood the contract, that they agree this is an electronic signature, and that the process is recorded in an audit log.
9. The signing service invites the next signer, and so on until everyone has signed.
10. The signing service sends the fully signed contract back to the API.
11. The API generates an audit.pdf, then deletes the whole transaction from the signing service.
12. The signed contract and its audit record go back to your installation, and the API deletes its copy of the transaction too.
13. You’re notified by email that the contract is signed.

After all that, the signed contract sits in your Wintertrace installation — in the admin area and in the customer portal — visible to everyone who’s party to it. The same place as the work.

It’s a lot of steps. They’re deliberate, and several of them are still being worked out, particularly on the data-protection side. But the shape is the point.

What gets kept, and what doesn’t

This is the part I care about most, so let me be plain about it.

The NoSchmarrn.dev API stores nothing of substance. No PDFs, no signed contracts, no customer data. It routes the document and, at the end, assembles the audit record and triggers deletion. It is a pipe, not a filing cabinet.

The signing service holds the PDF only as long as it’s needed — that is, until every requested party has signed. The moment the last signature is in, the signed document is sent back through the API to your installation, and the transaction is deleted from the signing service. It isn’t kept “just in case”.

Alongside the signed contract, the API produces an audit.pdf. It records the things that are easy to argue about later: when the contract was handed over for signing, when it was signed and by whom, when it came back, and when it was fully deleted from the signing service. It’s a timeline of the process, attached to the document the process produced.

The whole thing runs on a dedicated root server in Germany — not a US provider. Traffic is HTTPS throughout, and every step is written to an audit log. These are part of the same data-protection tooling that already covers anonymisation and retention elsewhere in Wintertrace.

What the audit record is — and isn’t

I’ll borrow the same honesty I try to apply to the service proof, because it matters even more here.

An audit record makes “I never agreed to that” harder to sustain. It shows that a specific person, at a specific email address, confirmed they had read the document and signed it at a specific time, and it keeps that record next to the contract itself. That’s useful. It’s the kind of thing that settles a disagreement before it becomes a dispute.

What it is not is a legal verdict. It’s documentation, framed the way I frame all of it — a record that’s harder to wave away, not a guarantee about how any signature will be treated in any particular jurisdiction. Electronic signing rules differ from country to country, and a piece of software doesn’t change that. If a contract carries real weight for your business, that’s a conversation for someone qualified in your jurisdiction, not for a blog post.

What this is, and isn’t, yet

A few honest boundaries while this is still being built:

• It’s in active development. The module, the API, and the signing service are all being worked on right now, with proper testing under real conditions and further data-protection hardening still ahead.
• There’s no premium tier and no subscription. That’s consistent with the rest of Wintertrace, which stays free and without a subscription. A paid tier might happen one day; it isn’t on my mind today.
• There will be a rate limit at the start — around 20 contracts per month. It can be raised, but I want to see how the service behaves in live use before I open that up. Starting cautious is easier than walking something back.
• The first release uses the in-house API and signing service. Later updates are meant to make the signer pluggable, so you could use DocuSign or a self-hosted alternative such as Documenso or DocuSeal instead. The goal is choice, not lock-in — the same reasoning behind keeping Wintertrace open source.

You can follow where this sits among everything else on the roadmap.

A note from the person running it

One last thing, because it’s the reason the architecture looks the way it does.

I have no interest in seeing your contracts. None. I don’t want to read them, and I don’t want to store them. The design — an API that keeps nothing, a signing service that deletes the document the moment it’s signed, an audit record that travels back to your own installation — is built around that. The most reassuring data-protection story is the one where the operator simply doesn’t hold the data in the first place, and that’s the one I’m trying to build.

When it’s ready for real use, I’ll write about it again — with the parts that survived testing, and the parts that changed.

Note: Wintertrace provides documentation support. It is not a substitute for legal advice. Specific compliance assessments — including questions about electronic signatures and their treatment — should be made in consultation with qualified counsel in your jurisdiction.