Stefan Hansen ← All work

The Offering Archive Real-estate development — capital raising 2026

Copy it in, and it files itself — or says plainly that it can't.

An archive that files offering documents straight from email. Copy it on a send and it reads the document, files it as that project's next version, and records what changed since the last one.

Opening a project and scrolling its version history: figures, timeline, changes.

Role

Product direction · Strategy · Interface design · Information architecture · Build direction

Client

Nelson Construction & Development

The problem

An offering document is never finished. A raise fills up, a close date moves, a rate is renegotiated, and each new document lands in some inboxes and not others. Which version is current? What changed since the last one? Who has been sent which? All three were answered by searching email.

The tool explaining itself: email a PDF and it is read, filed and archived to Dropbox.
The tool explaining itself: email a PDF and it is read, filed and archived to Dropbox.

The interface is an email you were already sending

Copy the archive in when you send a document to an investor. That is the entire input.

It works out which project the document belongs to, files it as that project's next version, records what changed, archives the file where the team already keeps files, and notes who sent it and who received it.

Every project with its offerings and how many versions each has.
Every project with its offerings and how many versions each has.

It declines to guess, and says so

Matching a document to a project is a judgement: the name inside it rarely matches the name as filed. A confident match files straight in; an unconfident one goes to a review queue with the tool's best guess attached, flagged on the index and sent to a person, and waits. A wrong auto-file puts a document somewhere nobody will look, and does so silently.

The full stack for one offering: every version filed, newest first, with what changed.
The full stack for one offering: every version filed, newest first, with what changed.

Every version is kept, and what changed is written down

Each new version is compared field by field against the one before it, and the differences are written onto it in plain language — projected close date moved from December to March, rather than a diff a person has to interpret.

The full stack for one offering: every version filed, newest first, with what changed.
The full stack for one offering: every version filed, newest first, with what changed.

The rest of it

  • It reads the document — the raise, what remains, the rate, the term and the close date come out as structured fields.
  • Two raises on one building stay two offerings — a note and an equity raise keep independent version stacks.
  • It notices when an offering has gone quiet — whoever holds the last version is reminded it is old.
  • A correction reaches whoever produces the document — flag a wrong figure on a version and it goes to them.
  • The format changed and it kept mattering — the firm now sends live offering pages instead of documents, a companion project on this site, and every document ever sent is still filed and versioned.
The queue: two PDFs the matcher was not confident about, held for a human.
The queue: two PDFs the matcher was not confident about, held for a human.

What changed

  • "Which version is current?" became a page instead of a search. Every offering has a stack, newest first.
  • "What changed?" became answerable. Differences between versions are recorded in plain language.
  • "Who was sent which?" is on the record. Sender and recipients are noted against every version.
  • Filing stopped costing anybody anything. The email was being sent regardless.
  • Nothing has been filed into the wrong project. When the tool is unsure it says so and waits.