A financial operating system for a solo private practice.
A web dashboard and native iOS companion app that turn billing, deposits, expenses, taxes, and closeout into one calm, trustworthy operating system.
Practice OS gives a solo practice owner one trustworthy place to understand what is scheduled, what has been billed, what has been deposited, what still needs a receipt, and what should be reserved for taxes. It was built as a custom product rather than assembled from a template or extended spreadsheet.
Identifying details, project information, and user data have been modified to protect client privacy.
ProjectPractice OS: A Financial Operating System for a Solo Private Practice
CategoryProduct Design · Financial Systems & Automation · Web Application · Mobile Application · Business Operations
ClientPrivate Client Project
My roleProduct strategy, UX and workflow design, UX writing, visual design, front-end development across web and native surfaces, database architecture, native iOS integration, responsive and regression testing, deployment, and ongoing product iteration.
TechnologyVanilla JavaScript · HTML · CSS · Expo · React Native · Supabase · PostgreSQL · Row Level Security · Swift · WidgetKit · Vercel · EAS Build
The mobile app's Today screen — the default landing view, showing the day's sessions, quick workflow shortcuts, and one-tap status updates.The dashboard Overview screen, with the Practice Assistant's plain-English weekly brief and the Financial Autopilot cadence.
Overview
Two surfaces share one backend and one definition of the business.
The browser dashboard is where deeper financial work happens: bank reconciliation, expense management, receivables, delegated bookkeeper access, and weekly or month-end closeout. The mobile companion is where the owner lives day to day: checking sessions between clients, logging a payout when it lands, reviewing reports, or glancing at a home-screen widget before the day starts.
The two surfaces remain coordinated through a non-destructive sync model. Dashboard-managed records remain authoritative, local changes are merged carefully, and neither surface silently overwrites the other.
The Challenge
The back office was fragmented across tools that understood only part of the work.
Solo practice ownership combines service delivery with an entire financial and operational business. Scheduling tools do not usually model tax reserves. Spreadsheets do not reconcile a bank deposit to the service week it covers. Generic budgeting products do not distinguish an owner contribution from a deductible expense or grant a bookkeeper meaningful access without exposing information outside the financial workflow.
The challenge was to replace that patchwork with a system rigorous enough for reconciliation and delegated access, yet fast enough to use between sessions on a phone.
The Solution
A coordinated system built around the full financial lifecycle.
The dashboard manages allocation, bank reconciliation, expenses, recurring costs, subscriptions, vendors, assets, mileage, review queues, weekly closeout, and team access. The mobile app organizes the owner’s daily work into Today, Week, Finance, Reports, and Settings.
A deterministic Practice Assistant translates authenticated operational data into plain-language priorities. It can identify and explain what needs attention, but it does not call an external AI service or silently match, categorize, allocate, delete, deploy, or move money.
Surface One · Web Dashboard
Designed for reconciliation, review, delegation, and closeout.
The Financial Operations Center — expense transactions, receipts, and subscriptions in one review surface.Deposits & Bank Reconciliation — Smart Auto Match proposes matches with a confidence score; nothing is applied without explicit approval.The Weekly Closeout & Automation Center — an operating-readiness checklist and a planning-only tax reserve estimate.Team Access — delegated Owner, Bookkeeper, and Financial Viewer roles enforced by Row Level Security, not just hidden buttons.
My Role
I led the product across strategy, design, architecture, implementation, and release.
01
Product strategy
Defined the financial and operational model, the delegated bookkeeper workflow, and the deliberate boundary excluding clinical data and unsupervised financial automation.
02
UX and workflow design
Designed the dashboard information architecture and the mobile Today, Week, Finance, Reports, and Settings structure around real operating questions.
03
Visual design and UX writing
Created the shared lavender-and-ink design language and the calm, plain-language microcopy used for priorities, safeguards, review states, and financial planning.
04
Development and architecture
Built the modular dashboard, native mobile shell, shared data relationships, authentication boundaries, secure sync, and native iOS integrations.
05
Testing and release
Managed responsive testing, regression suites, Vercel deployment, EAS builds, TestFlight preparation, isolated demo data, and ongoing point releases across both surfaces.
Product and Workflow Strategy
The most important design decisions were structural.
01
Model canonical financial events
A real bank deposit remains one authoritative record. Service-week allocations live beneath it rather than becoming duplicate payout events.
02
Separate operational states
Scheduled, completed, documented, billed, paid, deposited, allocated, and reconciled each describe a different condition and therefore a different next action.
03
Detect and prepare, never silently act
Automation may calculate, forecast, prioritize, and prepare a match or export. Sensitive financial changes always require explicit review.
04
Design each surface for its context
Desktop supports comparison, tables, and deep review. Mobile supports quick status updates and financial actions. The widget supports a calm glance.
05
Keep clinical content outside
No progress notes, diagnoses, treatment plans, assessments, intake forms, or therapeutic messages are stored on either surface.
Surface Two · Native Mobile Companion
Built for the decisions that happen between sessions rather than behind a desk.
The read-only Practice Assistant on the mobile Today screen — four plain-language business questions, answered from the same authoritative finance logic as the dashboard, each deep-linking into the exact existing workflow.
Mobile 2.3.4 · Practice Assistant
Decision support without invisible decision-making.
The Assistant answers four focused business questions: what needs attention, which deposit needs review, which receipt is missing, and what should be closed out. Each response is generated from the same authoritative bank-match and allocation relationships used by the product’s canonical finance history.
It is deliberately read-only. It may explain and deep-link into the correct workflow, but it cannot approve, edit, delete, allocate, submit, sync, or access clinical content—and it makes no external AI service call.
The mobile Week screen — Sunday-through-Saturday session planning with one-tap status updates and week-level stats.The mobile Finance screen — payouts matched to the service week they cover, with a monthly net-cash summary and money snapshot.The mobile Reports screen — year-to-date totals, revenue source breakdown, and a one-tap monthly export for the bookkeeper or CPA.The mobile Settings screen — account, the isolated demo workspace controls, cloud sync, and privacy tools.
Operational Journey
The system follows the work from the first daily glance through weekly closeout.
01Orient
Review today’s schedule, weekly progress, and the Practice Assistant’s plain-language brief.
02Advance
Update session, documentation, billing, and payment states without collapsing them into one status.
03Reconcile
Review Smart Auto Match suggestions and connect real bank activity to canonical deposit records.
04Resolve
Address missing receipts, ambiguous expenses, receivables, or allocation gaps through exact review queues.
05Close
Review readiness, reserve planning, recurring costs, and a downloadable closeout package.
Privacy, Security, and Financial Safety
The permission model was designed around what each person must never see.
Neither surface stores clinical information. Every record is scoped to its owning account through Supabase Row Level Security. A restricted database function gives a bookkeeper only the business-financial session fields needed for billing and reporting, while consultations, the full roster, clinical scheduling, and therapeutic content remain outside that role.
Sensitive corrections require owner approval. Mobile access supports Face ID and an always-available local passcode. Configuration values and database credentials remain outside both clients and do not appear in source, logs, screenshots, or release notes.
An isolated demo workspace provides fictional seeded data for testing and App Store review, with a protected reset action that cannot run against production.
The mobile sign-in screen, showing account-isolated authentication and the optional Face ID / passcode security model.
Visual and Interaction Design
A financial system can be rigorous without looking punitive or clinical.
Calm visual hierarchy
Lavender establishes continuity, white cards organize density, and deep purple anchors action without turning every exception into an alarm.
Plain-language operations
The interface answers questions such as what needs a receipt or whether billing is ready rather than displaying raw records and expecting the owner to infer the conclusion.
Visible safeguards
Review queues, confidence scores, owner approval, tax-estimate labels, and demo-workspace status make the product’s boundaries part of the interface.
Responsive and Cross-Platform Design
The widget was designed in three compositions, not scaled into three sizes.
The small, medium, and large iOS widgets share the same hierarchy but allocate information differently. Each focuses on today’s session count and projected value while intentionally excluding attention-needed counts from the more public home-screen surface.
Tapping the widget deep-links into Today, where the owner can move from a glance to the full operational context.
The iOS home-screen widget in its three supported sizes — small, medium, and large — each redesigned for its own layout rather than a scaled copy of the others.
Technical Approach
A shared backend supports distinct web, mobile, and native iOS experiences.
The dashboard uses modular vanilla JavaScript, HTML, and CSS deployed through Vercel. The mobile companion uses an Expo and React Native shell with a purpose-built single-page application rendered inside a native WebView.
Native iOS capabilities provide secure storage, Face ID, notifications, shared app-group data, and a Swift/WidgetKit target. Supabase provides PostgreSQL, authentication, and Row Level Security, connected through a non-destructive dirty-record merge rather than whole-database replacement.
Edge cases revealed which parts of the product needed stronger structure rather than more decoration.
01
Canonical deposit reporting
Service-week allocations were nested beneath the bank deposit they belong to so one deposit could no longer appear as several independent payouts.
02
Review-first automation
Matching, categorization, allocation, record removal, deployment, and money movement remained explicit human actions even when the product prepared a recommendation.
03
Role boundaries at the database layer
Bookkeeper and Financial Viewer access was designed through Row Level Security and restricted functions rather than interface visibility alone.
04
Secure mobile interruptions
App-lock behavior was refined to protect the interface during short interruptions without forcing unnecessary sign-in loops.
05
Isolated demonstration data
The demo workspace became a first-class product environment for testing and review rather than an improvised copy of production.
Outcome
A fragmented back office became one coordinated financial operating system.
Practice OS now provides one source of operational truth across sessions, deposits, allocations, expenses, delegated financial work, reporting, reserve planning, and closeout. The dashboard supports the work that requires depth, while the mobile app and widget support the decisions that occur throughout the day.
The project’s most important outcome is structural rather than numerical: it models the financial relationships correctly, makes review and permission boundaries visible, and gives the owner a calmer way to understand what requires action next.
Key Takeaways
What the product reinforced.
Operational clarity depends on modeling the relationship between records, not simply placing them in one interface.
Financial automation earns trust when it prepares and explains before it acts.
Cross-platform consistency comes from shared hierarchy, language, and data rather than identical layouts.
Permission boundaries should be enforced where the data lives.
A precise next action is more useful than a large collection of undifferentiated alerts.
Demo environments, regression tests, release checklists, and approval gates are part of product quality.
Does your workflow need more than another spreadsheet?
I design custom digital products that respect both the complexity of the work and the people responsible for carrying it.
