A built vertical inventory platform for printer consumables — native mobile applications, a row-level-secured Postgres backend, a from-scratch IPP printer client, statistical forecasting and subscription billing already in place. Pre-revenue, and honest about it.
Measured from the repository and the live database, not estimated.
Stated before anything else, because diligence will establish it anyway and a surprise later costs more than a plain sentence now.
Android
Live on Google Play
iOS & iPadOS
Built and submitted — in App Store review
Web
Marketing site. No web application for the product yet
Each item below is a named module in the repository, not a roadmap entry.
A binary IPP 2.0 client written from scratch — no native module. It builds the attribute request by hand, walks the tag stream, and normalises marker levels to a percentage. Works with AirPrint, Mopria and IPP-Everywhere printers on the local network.
lib/ipp.ts
Least-squares regression over stored level readings with fill-cycle detection, so a refill is not mistaken for usage. Under three samples it reports “not enough history” rather than producing a number it cannot support. Statistics, not AI.
lib/tonerpal.ts
A scan resolves against the account’s own history first, then a curated catalogue. An unrecognised barcode is bound to whatever the user enters, so the next scan of that box resolves automatically. The dataset improves with use.
lib/scan · lib/catalog.ts
Cost per page from cost and stated yield, a twelve-month spend series, an annualised projection from a rolling 90-day window, and RFC-4180 CSV export of inventory and spend history.
lib/tonerpal.ts
On-device notifications when a cartridge crosses its reorder point, deduplicated per fill cycle, plus a daily digest at an hour the user chooses.
lib/alerts.ts
Forecasting, costing, catalogue matching, the IPP wire parser and the alert dedupe rule are pure, dependency-free functions with 46 tests behind them — covering refill-cycle detection, rescaled printer levels and a truncated response. Reusable by a web client or API without the mobile stack.
lib/domain.ts · lib/__tests__
Row-level security on every table, chunked keychain session storage, optional biometric app lock, and a security-definer routine that deletes the account and every record attached to it on request.
supabase/001 · lib/app-lock.tsx
Domain logic sits in one data layer, separate from the interface — which is what makes a public API or a second client a extension rather than a rewrite.
Layer 1
React Native app (iOS, iPadOS, Android) with an adaptive layout system and shared design tokens.
Layer 2
Inventory, forecasting, cost and export logic isolated from the UI in a single typed module.
Layer 3
IPP client reading marker levels directly from printers on the local network.
Layer 4
Postgres with row-level security on all 5 tables, migrations under version control.
Layer 5
RevenueCat entitlements over App Store and Google Play billing, identified per account.
Assets owned outright and transferable, subject to definitive agreements and diligence.
Roughly 6,100 lines across 48 application files — mobile app, marketing site and database migrations, in TypeScript throughout.
A 13-screen React Native app, live on Google Play and submitted to the App Store, with signing, build pipeline and store listings.
A 5-table, 52-column Postgres schema with row-level security on every table, migrations, and a security-definer account-deletion routine.
A binary IPP 2.0 request encoder and response parser built from scratch, reading toner levels directly off networked printers with no native module.
47 curated cartridges across 6 manufacturers with part numbers, yields and compatibility, plus the scan-learning mechanism that extends it.
RevenueCat integration with a configured entitlement, monthly and yearly products live in App Store Connect, and customer identity tied to the account.
The TonerPal name, tonerpal.com, the design system shared by app and site, store listings and all marketing assets.
A written platform audit covering architecture, verified metrics and — explicitly — what is not built.
You could. The work below is what it would take — and most of it is domain work rather than framework work, which is the part that resists estimation.
We publish no build-cost estimate, because we have no basis for one that would survive scrutiny. The list is simply the scope.
None of this is built. It is listed because the existing schema and data layer make it an extension rather than a restart.
TonerPal already holds burn rate, threshold, part number, cost and yield per cartridge — the inputs a replenishment engine needs. Today the reorder step hands off to a supplier search. Supplier integration or a distributor relationship would close it.
Data is currently scoped to a single owner. Teams, roles, per-site inventory, approval workflows and centralised billing are a schema extension on top of the existing owner scoping.
The domain logic is already isolated from the UI in a single data layer. Exposing it would let procurement suites, MSP tooling and office-management platforms read fleet supply state.
The model is “a consumable, in a device, at a location, with a burn rate.” Nothing in the schema is toner-specific beyond naming — paper, ink, batteries and filters fit the same structure.
No partnership exists or is implied. These are the channels where the product would sit naturally inside an existing customer relationship.
Printer & imaging manufacturers
A software layer over installed hardware, and a supplies demand signal.
Office-supply distributors
A reason for a buyer to open an app between purchases, with the part number already known.
Managed print providers
Digitises supply tracking for accounts too small for a full managed-print contract.
Procurement & spend platforms
A consumable category most horizontal tools model poorly.
Office-management software
Facilities and IT suites that already own the customer relationship.
The following are available to qualified parties under a signed non-disclosure agreement. Nothing sensitive is published on this site.
Tell us who you are and what you would need to see. We reply to every serious enquiry.