Plutify already had the financial data. The transformation was making that data useful to the client without turning QuickBooks into the client experience. RECAST built a read-only command layer that presents the numbers in Plutify's language, keeps tenant data separated and routes unresolved questions back to the firm's team.
Evidence at publication: around 40 monthly-retainer clients in the operating context; live QuickBooks read status proven; protected routes rejected unauthenticated requests; write and send actions remained deliberately blocked.
The company
Saadi Sabah runs Plutify Bookkeeping, serving around 40 monthly-retainer e-commerce bookkeeping clients. The books were current in QuickBooks Online, but the review experience was still dominated by monthly PDF or Excel reports and the complexity of the accounting interface.
For Plutify, the product was not only accurate bookkeeping. It was the client's ability to understand the position, compare periods, ask a useful question and know when the firm's judgment was required.
The constraint
Static reports gave clients a snapshot but not an operating surface. QuickBooks held the source data, yet it was too dense and accounting-oriented to become a clear, branded review experience for every client.
The result was avoidable friction: low report engagement, repeated explanations and no consistent place for a client to move from a number to an informed question.
Why existing tools were not enough
Replacing QuickBooks would have created risk without solving the right problem. Exporting prettier files would have preserved the delay and one-way nature of the existing experience.
The missing layer had to read from the accounting source of truth, isolate each tenant, present a standardized KPI and finance view, explain setup and report context, escalate what it could not answer, and prevent the assistant from editing books or sending material without approval. The correct boundary was read access first, governed action later.
Transformation map
Before
QuickBooks -> monthly export -> PDF or Excel -> client interprets alone -> email question -> Saadi reconstructs context
After
QuickBooks live read -> tenant-isolated finance view -> period and KPI review -> CFO-style question -> answer or escalation -> Saadi decision
Any future edit, export, scheduled run or external send remains outside the live path until its credentials, probes, approval owner and QA evidence are complete.
One workflow, end to end
- Input: An authenticated client enters Plutify's portal and selects the relevant reporting period.
- Data read: The service retrieves permitted QuickBooks Online data through the live read path.
- Presentation: The portal renders the standardized finance tables, KPIs and report context for that tenant.
- Question: The client asks a CFO-style question from the same review surface.
- System action: CFO Chat explains available context, drafts a report shell or guides the next step without editing QuickBooks.
- Human gate: An unanswered or judgment-heavy question escalates to Saadi's team. Any write, file export, cron activation or send remains blocked.
- Record: Portal state and workflow drafts preserve the issue and its next action without crossing the no-write boundary.
What changed
- Built: A Plutify-branded client portal, tenant model, authentication, finance views, reports, integration surfaces, workflow drafts and CFO Chat.
- Connected: A live read path to QuickBooks Online, encrypted local credential storage and Recast's Google OAuth broker readiness.
- Tested: Application health, authentication controls, protected API behavior, QBO connection metadata, live-data status and recent error signals were audited.
- Verified live: QBO live-data status was true and the application was healthy at the retained audit point.
- Actively used: The source proves a live product foundation and live accounting reads. It does not yet evidence routine adoption across all 40 clients, so this page does not claim it.
- Provider or client dependency remaining: Some finance semantics and integration-status language required polish. QBO or Google writes, report exports, scheduled runs and sends remain blocked pending credentials, probes, approvals and QA.
- Financial result reported by client: None. The firm's client count describes operating context, not a result caused by the system.
Proof
- Operating context: Around 40 monthly-retainer e-commerce bookkeeping clients.
- Data receipt: QuickBooks connection metadata present and live-data status true.
- Access control: Protected API routes rejected unauthenticated access.
- System health: The application was healthy with no recent app error signal in the retained audit.
- Honest boundary: Read operations are live; writes, exports, schedules and sends remain approval-gated.
Technology - revealed last
The stack runs on a client-owned VPS behind nginx and HTTPS. It combines a Python dashboard service, React/Vite front-end bundles, SQLite state, tenant authentication, QuickBooks Online live read paths, encrypted credential storage, Google OAuth broker support and Claude-enriched CFO Chat routing. Protected APIs and provider readiness checks make the no-write boundary enforceable rather than rhetorical.
Client quote
No source-backed verbatim client quote is published for this case. The retained proof is product, access-control and live-data evidence; RECAST does not invent a reaction to complete a template.
Next transformation
See how LEED Agency built persistent reporting memory around account-specific rules and source material. Plutify changes the client review surface; LEED changes the internal analysis surface.
Get your AI blueprint
If the source data is sound but the client experience still depends on exports and explanation, the next useful layer may sit above the system of record rather than replace it. Book a free AI audit to map that boundary.
Source record
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 22.RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 18, documentRA-CASES-001, version 2.0.RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 10.4, 11 and 58.