Blair Hartman

I follow interesting problems until they turn into systems, software, or stories.

  1. Systems finance · analytics · enterprise data
  2. Software native apps · tooling · automation
  3. Stories film · writing

Currently

as of August 2026

  • Building Screenwriter, a native macOS screenwriting application
  • Writing Church Camp

Selected work

Exhibit A

The screenwriting software I wanted to write in.

Screenwriter is a native macOS application built in Swift and AppKit, made because the screenplay editor I wanted did not exist. It is pageless and deliberately minimal — the interface stays out of the way so the writing is the only thing on screen. The guiding idea is power without presence: the depth is there when you reach for it, invisible when you don't. I write in it daily, which is the only feature list I trust.

Filed undermacOS · Swift · AppKit

in real use · in active development

Exhibit B

The export the consultants called non‑automatable.

On an Oracle Fusion Cloud implementation, the integration consultants assessed the Enterprise Data Management extract as a permanently manual workflow. I read the API documentation differently. The result is a scheduled OAuth 2.0 client against EDM's REST interface that authenticates, extracts, and stages dimension data without a human in the loop — retiring both the labor and the keying errors that traveled with it.

The manual path was not just slow; it was unsafe. Enterprise identifiers do not survive naive handling — a spreadsheet silently sheds leading zeros or collapses a long key into scientific notation, and nobody notices until a reconciliation fails weeks later. So the automation is built to preserve types end to end, by default, on every run.

What ordinary handling does to an identifier
000471203becomes471203leading zeros, silently dropped
9847002311240017becomes9.847E+15precision, silently lost

delivered intact, every run

Filed underOracle EDM · REST · OAuth 2.0 · data integrity

Exhibit C

Film Finance OS.

Film financing runs on spreadsheets that no one fully trusts. Film Finance OS is software I am building to give that work a real spine — modeling financing scenarios, resolving investor waterfalls, and organizing the money behind a production so the numbers hold up when someone leans on them. It is one artifact where finance, software, and film turn out to be the same problem.

Filed underFilm finance · Software

in development

Exhibit D

Oddments — a drawer of small, sharp tools.

Oddments is a collection of little browser-based utilities, built local-first: the work happens in your browser, with no account, backend, or database behind it. There is an Invisible Character Inspector for the gremlins that hide in pasted text, and Slopometer, a deterministic prose-style analyzer. It lives next door to the data-quality work and is also just play — the drawer where a problem interesting enough to bother solving ends up as a working tool.

Filed underBrowser tools · Local-first · Text & data quality

About

The common thread is an instinct, not a job title: I run into a complicated system, need to know how it actually works, take it apart, and build something useful out of what I find. That has pointed me at finance, analytics, enterprise systems, governance, software, film, and writing — different surfaces, the same reflex underneath.

I came up through healthcare finance — general-ledger oversight across roughly 1,600 business units through a twenty-billion-dollar annual close — and moved deliberately toward the engineering side of the problem, because when the data layer is sound, everything built on top of it gets easier. Alongside that I spent a decade in nonprofit governance, in treasurer and director roles, drafting bylaws, financial policy, and audit-ready reporting. Governance work and data work turn out to be the same discipline at different altitudes: controls, accountability, and documentation people can rely on.

A screenwriting app, a film-finance engine, a story in progress — the same curiosity that drives the ledger work, following the problem into a different room.

The bottom line

Have something interesting to talk about — a hard data problem, a piece of software worth building, a story worth telling? That is the part I never get tired of. Reach out.