Live cross-device beta
The mobile and desktop application surfaces are live and use a shared account state.
PecuIQ is a live privacy-first wealth-tracking beta built around manual net-worth records, conversational onboarding and observational insights. The work combines product strategy, responsive app engineering, mobile and desktop parity, import and synchronisation safeguards, brand design and careful non-advisory language. The intended operating context is Mobile web, desktop web, PWA, backend sync and design system. Thomas's role was Founder, product director and application builder. The case follows the product from its main operating problem through Live cross-device beta, Conversational first use, Mobile insight parity, then connects each interface to a working feature and control. The evidence comes from live releases, application tests, browser qa and design prototypes. It also records what failed, what changed and how privacy, evidence or approval boundaries are handled. The limit is explicit: tracking evidence only, with no financial-advice or user-growth claim.
A direct account of the operating constraint, the product decision and the limits of the evidence.
Net worth is a simple equation, but a trustworthy product has to handle edits, histories, deletions, imports, offline use, account switches and two devices changing the same state. A beautiful total is useless if an old cloud snapshot can silently overwrite a recent local record.
The product also needed a careful role for AI. Conversational onboarding can make first use easier, and Insights can reflect patterns in a person's own numbers. That does not justify investment recommendations, return projections or language that implies a financial outcome.
PecuIQ was therefore designed as a tracking product with a visible data-health model. Mobile and desktop share core behaviours, imports explain uncertainty, synchronisation fails visibly, and observations stay descriptive. The longer financial-OS roadmap is separated from what the current beta can prove.
| Primary job | Give a person one clear, current view of assets, liabilities and net worth. |
|---|---|
| Product premise | Manual entry first, AI-led onboarding, privacy and understandable records. |
| Working surfaces | Mobile and desktop app, PWA install, Insights, imports, history and account controls. |
| Language boundary | Observations about the user's own data, never product recommendations or promised returns. |
| Public evidence | Synthetic holdings and values in every screen. |
These are observed properties of the working system. They are not claimed percentages, revenue attribution or a guarantee of future performance.
The mobile and desktop application surfaces are live and use a shared account state.
A staged AI-led onboarding flow turns rough asset and liability answers into an understandable starting dashboard.
Observational Insights are available on mobile rather than existing only on the desktop surface.
Reload, deletion, account-switch, offline and import failures were found, fixed and converted into checks.
PWA caching, self-hosted type and valid platform icons support an intentional installed experience.
The interface reflects the user's own records and avoids recommendations, forecasts or guaranteed milestones.
Every image preserves the interface purpose and control logic while replacing live people, projects, records and values with staged data.







Each entry links to the exact view it describes. Product captures and explanatory diagrams retain their own evidence labels.
The live product preview uses synthetic holdings and adapts to a purpose-built mobile app view.
A guided conversation turns best estimates into a draft financial picture that can be checked before it is saved.
Source health, missing records and import uncertainty stay visible before the product accepts a total as current.
Assets and liabilities keep editable records and history so a change can be explained rather than hidden inside one total.
Insights describe patterns in the user's own staged records without recommending products or forecasting returns.
A visual summary connects the main product capabilities to the decisions, controls and user outcomes they support.
The complete working sequence shows how information moves from the first input to a checked and reviewable outcome.
The visible dashboard is only the decision surface. Context, data, permissions, review and learning determine whether it can be trusted.
Assets, liabilities, values and history preserve the records needed to explain the total.
AI onboarding, Home, Assets, Liabilities, History and Insights form a direct product journey.
Cloud state, pending writes, deletion and account changes use explicit safeguards and recovery paths.
Reconciliation, debt-free cases, locale-aware numbers and uncertainty remain visible before data is accepted.
A dark-first gradient identity, tabular numbers, motion rules and reusable components keep product states consistent.
A useful workflow names the input, owner, check, approval boundary and proof that closes the loop.
Pecu asks short questions and accepts best estimates without implying false precision.
The person adds or imports assets and liabilities with source and edit context.
The product flags ambiguity, locale or missing-debt conditions before accepting the total.
Dashboard, history and Insights describe changes and concentration in the person's own data.
Synchronisation, wipe, sign-out and offline paths preserve clear account and device boundaries.
Each feature exists because it changes a decision, reduces unsafe ambiguity or makes a failure easier to see.
A seven-scene conversation captures currency, property, investments and liabilities before revealing the dashboard.
Total, assets, liabilities, allocation and recent change stay readable without dashboard overload.
Assets and liabilities can be edited with value history, charts and safe delete behaviour.
Trend, cash, concentration, liability and milestone cards reflect the user's own data without advice.
Locale-aware numbers, ambiguous totals and debt-free cases are reviewed before merge.
Account switching, offline use, pending writes, wipe recovery and service-worker rules are verified.
The strongest evidence in an operating system is often the failure behaviour. These issues became design constraints and regression checks.
Per-item value history could disappear after a reload.
Persist and reconstruct history through the shared data layer, then verify it across mobile and desktop.
A desktop wipe could clear the device while cloud records returned on reload.
Use an explicit pending wipe and durable remote deletion path before confirming success.
A quick close or account event could happen before a delayed write completed.
Track pending state, serialize pushes and recover unsent work before the next cloud load.
A user with no debt could be prevented from importing a valid record.
Show an acknowledgement and preserve the unusual but valid case instead of hard-blocking it.
Important safety fixes could land on one surface only.
Add parity markers and consistency checks that fail the build when required behaviour diverges.
A public case study should make it easy to see what is working, what remains internal and what has not been proven.
The visuals use public route captures and real public app screens with synthetic values. The product tracks information; it does not provide financial advice or prove a user outcome.
Strategy, interface, governance and implementation are treated as one operating problem rather than separate deliverables.
Each link adds a different layer of first-hand evidence rather than repeating the same page under another keyword.
Practical answers about the build, its use and its limits.
Yes. A mobile and desktop beta is live.
No. The current product tracks records and presents observations about the user's own data.
No. All holdings, history and net-worth values are synthetic.
No. The case separates current beta evidence from later cashflow and education ideas.
A product diagnostic, critical-flow prototype and evidence-backed build plan. Handover: the findings, a prioritised plan and the evidence needed to decide the next step. Scope and schedule are agreed after the fit conversation.
Thomas can shape the product, interface, evidence model and recovery behaviour around the decisions your users actually make.