ResolveOS

The job ran on exports. Account data arrived as spreadsheets with column names that changed depending on which system produced them. Follow-up priority lived in memory, payment dates were tracked by hand, recurring plans were expanded on paper or not at all, and month-end meant copy-pasting totals between files and re-checking them. Settlement opportunities were hard to compare because nothing sat side by side.

The workflow depended on the operator remembering what software should have remembered. I was doing this work, not observing it, and I got tired of being the database.

ResolveOS answers the operator's actual daily questions. The dashboard shows portfolio health and expected cash for the month. The accounts view is a prioritized working queue rather than a flat list: who gets worked today, who is at risk, who has gone quiet. The opportunity pipeline holds settlements in stages so offers can be compared and forecast with confidence weights. The payments view tracks plans and expected receipts, so a missed payment is visible the day it happens instead of at month-end.

Each view exists to make a decision: what to work next, what to offer, what to chase, and what actually cleared.

Dashboard overview

Accounts overview

Opportunity pipeline

Payments overview

I was embedded in this operating environment in the most literal sense: I do the collections work, and the software was built from inside it. The business rules were unwritten. Which accounts get touched today, when a settlement offer is worth comparing, what counts as at risk, none of it existed as a spec. Discovering the rules meant doing the job, and encoding them meant translating how the work actually happens into a data model and priority logic.

I owned product definition from doing the work, interface and workflow design, import normalization, the data model, priority logic, payment scheduling, settlement forecasting, reconciliation, deployment, and maintenance. Because I am also the primary user, weak assumptions show up immediately in the next working day.

The shape is simple on purpose: a Next.js application on Supabase, with the complexity concentrated at the import boundary.

The first import pipeline trusted the exports too much, and real files broke it: duplicate rows inside one file, re-imports creating copies, amounts arriving as text. Deduplication now runs on a composite key against both existing accounts and rows within the same file, and replace-mode teardown happens in dependency order with error short-circuits.

Other corrections came from daily use: renames like Touched to Worked and Status to Collection Day taught the software the operator's language, and a fix to preserve manually set worked dates came from the field, not a spec.

None of this was a dramatic outage. It was daily-use feedback finding weak assumptions fast, which is exactly what an internal tool with its builder as primary user is good at.

ResolveOS replaced the spreadsheet and memory workflow it was built inside. It is the primary user's daily workspace: one view of accounts, opportunities, schedules, and expected payments, with month-end reconciliation reduced to checking differences instead of rebuilding totals.

Part of this rebuild is already underway: a 2026 refactor split the original oversized page into extracted views, hooks, and contexts, and scaffolded an organization model (creditors, debtors, cases) with schema-as-code migrations, the groundwork for use beyond one operator. Still on the list: automated tests, money in integer cents instead of parsed text, deduplication enforced by database constraints rather than client-side checks, and import validation with real error reporting plus a synthetic dataset for safe testing. ResolveOS is where those lessons were learned first; the Velocity platform is where they were applied, down to its schema-first migrations and integer-cent money.