Powerhouse Holdings

The portfolio

Ventures that hold.

Multiple operating platforms
Selected private engagements
One engineering culture

Every platform below was conceived, architected, built, and is operated inside Powerhouse Holdings. Beneath them sits the quieter half of the portfolio — the client engagements our agreements let us outline.

01 / 03

ChronoCal

Time, charged.

SectorPersonal productivity
CategoryLocal-first SaaS
StatusIn operation
PlatformWindows desktop · any device on the local network

A personal calendar that fills itself in — and takes orders in plain English. ChronoCal closes the gap between what a calendar says a day held and what the day actually held.

Most calendars are write-only: they know what was planned, never what happened. ChronoCal runs a background activity tracker that logs screen time per application with a productivity score, layering a truthful record of the day underneath the schedule. The result is a calendar with both intention and evidence on the same page.

Its interface is language. A chat bar — typed or spoken — turns "remind me every 30 days at 11am to pay the water bill" into a correctly structured recurring item, time zones and all. Connected to a Gmail account in read-only mode, it identifies genuine bills in the inbox and places "Pay X — $Y" on the exact due date. The machinery disappears; what remains is a calendar that behaves like an assistant.

Everything lives in a single SQLite file on the owner's machine. Nothing is telemetered, ever. The only network calls are the Google integrations the owner sets up with their own keys — a privacy posture that is architecture, not policy.

  • CC·01
    Natural-language scheduling

    Typed or spoken commands become events, recurring reminders, and countdowns — powered by the owner's own AI subscription, with full time-zone awareness.

  • CC·02
    Automatic activity intelligence

    A background tracker fills every day with per-app screen time and a productivity score, so the calendar records reality, not just intent.

  • CC·03
    Gmail bill detection

    Read-only mail analysis across multiple accounts identifies real bills and schedules them on their due dates, with amounts.

  • CC·04
    Google Calendar overlay

    Multi-calendar overlay with per-calendar colours and two-way sync for items pushed upstream.

  • CC·05
    Fluid day management

    Month, week, and day views with drag-to-reschedule at 15-minute snapping; typed, colour-coded, fully customisable item categories; skip-one-occurrence recurrence.

  • CC·06
    Ambient awareness

    Native Windows notifications, a 9 a.m. daily digest, live countdowns in the header, and daily weather with no API key required.

  • CC·07
    Any-device access

    One switch exposes it to every device on the home network, installable to a phone's home screen as an app.

  • CC·08
    Owned data, open exit

    Search, undo, ICS import/export, and a one-folder backup story. Back up data/ and everything is saved.

ArchitecturePython application over a single-file SQLite store; ships as a standalone Windows executable with autostart; responsive web UI served locally.
IntegrationsGoogle Calendar (two-way), Gmail (read-only bill detection), Open-Meteo weather, Claude for language understanding — each optional, each on the owner's own keys.
Privacy modelLocal-first; zero telemetry; the data directory is the complete backup surface.
DistributionOpen source under the MIT licence, with a documented path to mobile store releases.

02 / 03

Scorely

Credit, clearly.

SectorConsumer finance
CategoryAnalytics & decision support
StatusIn operation
PlatformWeb · three deployment modes

A personal credit command center: monitors scores across all three bureaus, flags every negative item with a repair playbook, and plans the path back — deadline by deadline, dollar by dollar.

Credit repair is a process industry that thrives on opacity. Scorely's answer is total clarity: a dashboard of three bureau gauges and a twelve-month trend, a ranked list of next-best actions scored by estimated points per unit of effort, and per-card utilisation with the 29% threshold marked where it matters.

Every negative item gets a severity-striped flag and a playbook grounded in the actual rules of the system — the under-$500 medical collection policy, debt validation before payment, pay-for-delete in writing, goodwill timing, DOFD fall-off dates, reinsertion rights. The dispute engine drafts five statutory letter types, merge-filled from the owner's profile, and runs them through a pipeline where nothing is sent until a human approves it — then tracks the FCRA 30+5-day response window automatically.

The strategy layer thinks in dates. Balances reported to bureaus are captured on statement dates, not due dates — so Scorely schedules pay-by reminders roughly four days before each card reports, plans paydowns across the utilisation tiers that scoring models actually use (90% → 50% → 29% → 9% → AZEO), and tracks the free weekly bureau rotation so the owner never pays for their own report.

  • SC·01
    Three-bureau monitoring

    Equifax, TransUnion, and Experian gauges with a 12-month trend line, needs-attention deadlines, and next-best actions ranked by estimated impact per effort.

  • SC·02
    Negative-item playbooks

    Severity-striped flags, each with a specific repair strategy drawn from FCRA/FDCPA practice — validation, pay-for-delete, goodwill, fall-off timing, reinsertion rights.

  • SC·03
    Statutory dispute engine

    Five letter types — FCRA §611 bureau dispute, FDCPA §809 validation, goodwill, pay-for-delete, method-of-verification escalation — drafted, approved, mailed, and countdown-tracked.

  • SC·04
    Paydown planning

    Allocates a monthly budget across utilisation threshold tiers and shows the month-by-month path, rebuilt from live data whenever anything changes.

  • SC·05
    Report-cycle calendar

    Statement and report dates, pay-by dates ~4 days before each card reports, payment dues, dispute deadlines, and free-pull availability — in one view.

  • SC·06
    Weekly pull rotation

    A one-bureau-per-week rotation strategy delivers continuous three-bureau coverage from free weekly reports, tracked and nudged automatically.

  • SC·07
    Email intelligence

    In its server deployment: a Monday-morning digest plus deadline checks that email at 7, 1, and 0 days before FCRA deadlines and 3 days before a high-utilisation card's pay-by date.

  • SC·08
    Cross-platform by design

    One codebase, three deployments — private cloud page, plain browser, or Google Apps Script — plus JSON backup/restore and a full tradeline editor.

ArchitectureSingle-page application with a portable storage layer; deploys identically to a private hosted page, a local browser, or Google Apps Script with server-side triggers.
InteroperabilityReads statement/report dates from ChronoCal over a one-endpoint JSON contract — two portfolio companies sharing an interface, not a database.
Human-in-the-loopEvery outbound dispute passes a draft → approval → mailed pipeline; the system prepares, the owner decides.
PositioningA personal decision-support tool — not a credit repair organisation and not financial advice; score impacts are estimates.

03 / 03

Cardonomics

Know the board before you buy in.

SectorLive commerce · collectibles
CategoryMarket-intelligence SaaS
StatusIn operation
PlatformWeb platform + autonomous collection fleet

Modular break intelligence for the live sports-card market — first-party capture of what actually happens in live breaks, fused into clearing prices, odds, and market structure nobody else can see.

Billions of dollars of trading cards change hands on live streams where the record of what sold, for how much, and what came out of the packs evaporates the moment the stream ends. Cardonomics keeps that record. An autonomous collection fleet watches live breaks end to end — every lot opened, every bid placed, every slot sold, every trade — and posts it to the platform as first-party observed data, reconstructing each break as a complete economic event.

Recognition is a fusion problem, and Cardonomics treats it like one. Audio transcription, serial OCR, and vision models each contribute signals whose accuracy is measured, not assumed — a 97%-precise signal earns more weight than a 68% one, within bounds that keep any single bad run from zeroing a signal out. A provisional call publishes about two seconds after a card is lifted; the settled call lands in four to six.

Then the learning loop compounds it. Corrections carry authority by standing — a breaker correcting their own stream settles it instantly; three agreeing participants equal one breaker — and every settled correction teaches the system aliases, signal weights, and confusion pairs it keeps forever. Every learned rule records its origin and can be revoked. Nothing is a black box.

Underneath is the architecture the rest of the house is known for: a pure kernel of identity, economics, and contracts; modules that share versioned interfaces rather than tables; consent gating and cohort suppression enforced at the data source, where no consumer can query around them.

  • CX·01
    Autonomous capture fleet

    Finds live sports-card breaks on its own, opens them, watches them, closes them when they end — scaling to 36 concurrent streams when the machine is idle and politely backing off when it isn't.

  • CX·02
    Break-native data model

    Understands auction and rip phases, slot formats (random, see-2-pick-1, pick-your-team), and the two-for-one trade mechanic — with a per-participant ledger that makes who-owns-what legible across a whole break.

  • CX·03
    Multi-signal fusion

    Speech, OCR, and vision fused with measured per-recogniser weights; provisional in ~2 seconds, settled in 4–6, with progressive disclosure so live feels live.

  • CX·04
    The learning loop

    Authority-weighted corrections teach aliases (with similarity gating), recalibrate signal weights, log confusion pairs, and tune acceptance thresholds toward a target precision — permanently.

  • CX·05
    Two market surfaces

    A mobile-first public board — slot pricing, odds, chases, live breaks — and a deliberately dense desktop desk for breakers: live metrics, planning, and seat management.

  • CX·06
    Contract-versioned modules

    Four read-model interfaces over a no-I/O kernel; the registry verifies every consumed interface at boot and refuses to start with a named error rather than failing hours later.

  • CX·07
    SaaS-grade identity & billing

    Org-level identity unifying humans and machines, scrypt-hashed credentials, single-view API keys, plans-as-data entitlements with metered usage — priced later without moving code.

  • CX·08
    Consent at the source

    Clearing-price visibility is consent-gated and cohort-suppressed inside the data layer itself — participants cannot bypass it by querying differently, because no other query exists.

ArchitectureZero-dependency Node platform: pure kernel (identity · economics · contracts), a collection module owning all observed data, and consumer modules for breakers, participants, and admin.
Data capturedLots, bids, sales with running holdings, trades, breaker announcements, and audience samples — a full timeline per stream, reconstructing how boards fill and what clears.
IntelligenceAuthority model (breaker-own-stream 1.0 → participant 0.34), alias learning with similarity gating, bounded signal-weight calibration, confusion-pair targeting, precision-targeted threshold tuning.
OperationsRuns 24/7 on commodity infrastructure; the collection fleet operates from a signed-in, first-party browser session — genuinely observed data, nothing spoofed.

04 Selected engagements

The quiet portfolio.

The advisory practice, in three engagements. What follows is everything our agreements allow us to say — the gaps are intentional, and contractual. Our partners' privacy is our utmost concern.

E·01

Built, then operated.

SectorWholesale logistics · regulated goods
EngagementSystem design, build & operation
StatusDelivered & operated
DisclosureLimited under NDA

For one of the nation's largest hemp wholesalers, the house designed a logistics network end to end — and then stayed to operate it.

Wholesale in a regulated commodity is an exercise in accounting for physical goods. Supply arrives in quantity and in variable condition, and from the moment it crosses the dock every lot must be identified, catalogued, and entered into a record that will be trusted later — by an auditor, a counterparty, or the operation itself. Most organisations run on partial records and institutional memory. The cost of that is invisible until a count fails to match a ledger, at which point it is the only thing visible.

The house designed that record, and the network around it: cataloguing of incoming supply, audits, packaging, reconciliation, shipping, and returns — systematised as one continuous chain of custody rather than six separate chores. Reconciliation became routine rather than crisis, the shelf and the ledger compared as a matter of course. Returns were received with the same rigour as inbound supply, so goods coming back re-entered the record instead of a corner of the warehouse. The result is a property of the design, not a metric we are free to publish: one source of truth, from intake to return.

Then the house operated the network it had built. Operating a system you designed is the honest test of the design: every assumption meets the loading dock, and whatever does not survive contact is corrected rather than defended. That arrangement is the practice. The client keeps the credit and the numbers; the work shows in their operation, not in our marketing.

  • E1·01
    Intake cataloguing

    Every arriving lot is identified and entered into the record before it moves any further into the building.

  • E1·02
    Audit trails

    The record answers who handled what, and when, without anyone reconstructing it from memory.

  • E1·03
    Packaging discipline

    Packaging is tied to the catalogued lot, so what leaves the line is traceable to what arrived at the dock.

  • E1·04
    Reconciliation

    The shelf and the ledger are compared as routine, not as crisis.

  • E1·05
    Outbound shipping

    Shipments are drawn against the same record, with documentation that travels with the goods.

  • E1·06
    Returns handling

    Goods coming back are received with the rigour of inbound supply and re-enter the record, not a pile.

The client's name, geography, volumes, and results are withheld under NDA — deliberately; in this practice the client keeps the credit, and the outcomes live in their numbers, not ours.

E·02

Every head, accounted for.

SectorAgriculture · livestock & supply
EngagementAdvisory & systems design
StatusDelivered · multiple clients
DisclosureLimited under NDA

For several farming outfits, the house designed systems that manage livestock and supplies — where placing an order is one click, and creating a sale is one more.

On a working farm, the record-keeping competes with the work itself. Livestock arrive, are moved, are sold; feed and supplies are drawn down between deliveries; and the ledger — where one exists — trails the yard. Serious intake cataloguing means each animal and each delivery is recorded once, at the moment it arrives, and that record follows it through the operation. Anything less, and counts are reconstructed from memory at exactly the moments — a sale, an order, an audit — when memory is least available.

The house consulted for these outfits, and built systems that carry livestock and supplies in one record and reduce ordering and sale creation to a single click. A click is only fast because everything behind it has been resolved in advance: the catalogue of what is held, the counts as they actually stand, the details a supplier or a buyer will need. The systems keep that resolution current, so placing an order or raising a sale is a decision, not a project — one record from intake to sale.

The systems were designed to the operations they serve; the discipline behind them is shared. That discipline is the practice: understand how work actually moves through a farm before any of it is systematised, and let the software carry the record so the people can carry the work. The engagements are delivered. As with all our clients, the outfits keep the credit — what changed for them shows in their own numbers, and nowhere else.

  • E2·01
    Livestock management

    Each animal enters the record once, and the record follows it until it leaves the operation.

  • E2·02
    Supply cataloguing

    Counts reflect what is actually on hand, not what the last stocktake assumed.

  • E2·03
    One-click ordering

    An order placed in a single action, supplier and quantities drawn from the standing record.

  • E2·04
    One-click sale creation

    A sale raised in one step, from records the system already holds.

  • E2·05
    Bespoke systems design

    Designed to the operation it serves, not adapted from a template.

  • E2·06
    Working-farm advisory

    The house consulted on how the work moves before systematising any of it.

Names, locations, herd counts, and results are withheld under NDA — the clients keep the credit, and the results show in their numbers, not in our marketing.

E·03

Winning public work, systematised.

SectorGovernment contracting · public procurement
EngagementSystems development, ongoing
StatusIn active development
DisclosureLimited under NDA

Public contracts are won on paper before they are won on performance. For an emerging government contractor, the house is building the system that gets the paper right — from opportunity to award, at every level of government.

Public procurement is a discipline before it is a market. Opportunities surface across federal, state and local sources in different formats, on different clocks, under different rules — and the organisations that win them are rarely just the most capable; they are the ones whose paperwork holds. The newcomer faces a structural disadvantage here: incumbents have qualification down to a routine, while it rebuilds each bid from a blank page. The house was engaged to give the newcomer what incumbency usually supplies: finding and qualifying for public work as a system, not a scramble.

The system under development is built around two joined disciplines. It identifies opportunities — reading solicitations as they appear across government sources and screening them for genuine fit, because knowing what not to pursue is much of the economics of bidding. And it assembles qualification documents: the capability narratives, compliance responses and required representations a solicitation demands, each answer traceable to the requirement that asked for it, each drawn from one governed account of who the client is and what it can do. The aim is simple to state and hard to earn: no requirement goes unread, and no response is built twice.

The engagement is in active development, and it is shaped for what public work actually is: ongoing. Contracts with governments are relationships — renewal dates, reporting duties, and the expectation that the next bid is stronger than the last. So the system is built to accumulate, every submission improving the record the following one draws on. Judgement stays with people throughout: the system prepares; the client decides what is pursued and what is signed. Nothing leaves the house on the machinery's word alone.

  • E3·01
    Opportunity identification

    Solicitations surfaced at every level of government and screened before pursuit — volume is not a strategy.

  • E3·02
    Bid/no-bid discipline

    A structured judgement on which opportunities merit the cost of pursuit — made before hours are spent, not after.

  • E3·03
    Qualification packages

    Every document a solicitation demands, assembled to its letter and nothing beyond it.

  • E3·04
    Compliance traceability

    Every answer in a package points back to the requirement that asked for it, so completeness can be shown, not asserted.

  • E3·05
    One governed record

    A single maintained account of what the organisation is and has done — the source every package draws from.

  • E3·06
    Deadline custody

    Public procurement runs on hard dates; packages are assembled to the clock each solicitation sets, with time left to do the work properly.

  • E3·07
    Human approval

    The system prepares; the client decides. No package is submitted without a named person's approval.

The contractor's name, its market, and the work it pursues are withheld under NDA — by design; whatever comes of it will show in the public award record, not in our marketing.

Our partners' privacy is not a constraint on the practice. It is the practice.

Disclosure policy — Powerhouse Holdings

05 Shared DNA

Three products. One set of convictions.

Interfaces over ownership

Scorely reads ChronoCal's dates over a one-endpoint contract. Cardonomics modules consume versioned read models. Nothing in the house reaches into anything else's storage.

The human signs off

Dispute letters wait for approval. Corrections carry human authority. Calendar items are drafted, then confirmed. Automation proposes; people dispose.

Data with a conscience

Local-first storage, read-only mail scopes, consent-gated market data, zero telemetry. Every platform treats data governance as architecture.

Next

Curious what we'd
build in your industry?