One focused product. Full delivery discipline.

Meet the product owner

Brian Kendall is the founder of CodeCaliber LLC, organized in Kansas in September 2026. For Nova Ledger, he directs product requirements, guides AI-assisted development, tests user journeys, and works through troubleshooting and release documentation. AI tools performed substantial implementation; the project is not presented as independently authored code or paid enterprise software experience.

Brian is exploring early-career opportunities in software development, QA, implementation, technical support, customer success, and AI-enabled operations. He is open to U.S.-remote work and Western U.S. roles with employer-supported relocation, subject to an agreed compensation package, moving support, and timing. His service-business background adds practical experience with customer expectations, scheduling, estimates, and billing.

Connect with Brian on LinkedIn

Architecture

1. Flutter presentationAuthentication, portfolio, and privacy-support screens
2. Domain contractsAuthentication and asset repository interfaces
3. Supabase adaptersAuthentication plus Postgres persistence
4. Database boundaryRow Level Security restricts every asset to its owner
5. Release controlsFormat, analysis, automated tests, coverage, secret checks, and signed artifacts
6. Delivery evidenceGoogle Play, TestFlight, Android acceptance, and iPhone acceptance

What users can do

• Create an account and confirm its email address.
• Sign in to an owner-specific portfolio.
• Add, edit, persist, and delete manually entered assets.
• Hide every visible balance without altering stored values.
• Reach privacy, support, and deletion information before or after sign-in.
• Request account deletion through a documented operational process.

Data-protection model

• Supabase Auth establishes the user session.
• Postgres Row Level Security restricts select, insert, update, and delete operations to the authenticated owner.
• Client code receives only public configuration; administrative credentials never ship in the app.
• Secret scanning rejects protected paths and high-confidence credential formats.
• Public policy, support, and deletion routes are checked against exact approved markers.
• Reviewer and closed-test evidence stays private and de-identified.

Release-baseline quality evidence

These figures describe the recorded release baseline, not a new test run or a claim of continuous availability. Historical store-build evidence does not establish full acceptance of later development candidates; the dated checks and remaining limits below describe that separate work.

Release verification also checks formatting, static analysis, store assets, release identity, artifact provenance, checksums, signing evidence, reviewer access, screenshot provenance, and account-deletion operations.

Release journey

• Build 7 is active on Google Play's closed Alpha track.
• Google Play reviewed the September 19 production-access request and responded September 21 that more testing was required. It instructed an additional 14 days of closed testing with real testers before applying again. Its response cited low engagement and limited feedback-driven improvement as possible reasons for denial.
• Build 7 passed the Play-installed Moto G release gate.
• Apple validated Build 7 in TestFlight, and that build passed an eleven-check iPhone acceptance pass.
• After correcting placeholder artwork, Build 8 replaced Build 7 in the September 8 submission; the earlier physical-device evidence is not presented as Build 8 testing.
• On September 11, 2026, version 1.0 (Build 8) was released on the Apple App Store. View Nova Ledger on the App Store. Android remains in closed testing; iOS publication does not establish Android production approval.

Next-release work, not yet shipped

October 22 failure-path checkpoint: Codex reproduced and repaired an account-boundary error in the AI-assisted development workflow: when an asset request failed after sign-out or an account switch, it returned the transport error instead of the session-change signal used to clear former-account content. The repository now checks account identity on successful and failed completion, while preserving the original error behavior for the same account. It does not add mutation retries or replace database access controls.

A recorded run passed 131 focused tests, including 31 new regressions, with clean targeted static analysis. Synthetic sessions and HTTP responses exercise failed reads and writes, reconciliation failures, and screen behavior before and after a timeout. Codex performed these implementation and automated checks; Brian's role remains product direction and hands-on testing, not independent authorship of every change.

Candidate boundary: the repair was packaged in development candidate Dev51, but packaging does not prove execution on hardware. Its physical-device validation and hosted two-account isolation remain open. This scoped, dated test result is not a whole-app coverage measurement, completed security audit, verified customer-data incident, or new store release.

October 15 development checkpoint: a recorded run passed all 515 Flutter tests and full static analysis. The locally installed Dev45 Android candidate then passed observed single-account asset creation, editing, deletion, and cold-restart persistence on a physical Moto G. Synthetic-data checks preserved one cent and the supported maximum amount exactly through editing and restart, and rejected a value one cent above the limit. Add and Edit accepted an 80-code-point name containing an emoji, rejected 81 code points, and preserved the valid name after restart.

Normal background-and-return checks restored the same running app process with visible content. Hidden balances stayed concealed until explicitly revealed. Privacy and support navigation and cancellation of the account-deletion prompt were also checked; no deletion request was submitted. Temporary test assets were removed. Brian provided the device and completed private sign-in; Codex operated and documented these particular checks within the AI-assisted development workflow. Their execution and underlying implementation are not attributed independently to Brian.

What this does not prove: Dev45 is a development candidate, not a new Apple or Google release. These observations do not complete two-account isolation, delayed authentication-error scenarios on hardware, comprehensive accessibility or security testing, provider erasure, independent tester engagement, or production-build acceptance. The 515-test count is a dated recorded run, not a fresh run for this page update; it implies no new coverage percentage, customer adoption, or revenue.

October 9 local checkpoint: all 423 Flutter tests passed and full static analysis found no issues. New synthetic-response regressions verify that a write returns the requested asset identity, a delete confirms exactly the requested row, and returned asset values are finite and nonnegative. Negative percentage changes remain valid. Malformed replies must not enter the displayed portfolio as confirmed results; uncertain writes still require reconciliation. These tests do not claim that the production database violated its constraints.

Codex implemented these guards and regression tests within Brian's AI-assisted product workflow. Brian's contribution remains product direction, hands-on testing, and verification, not independent authorship of these changes. The Dev35 debug package is preserved locally, not installed or distributed, and does not replace either store build. No new coverage percentage, production-uptime result, or completed physical acceptance is inferred from the test count.

Google Play status boundary: an authenticated check on October 8 showed production eligibility but an unsubmitted production-access questionnaire. Independent tester feedback and candidate-specific readiness evidence remain separate from local automated checks. Eligibility is not approval or a public Android release.

September 24 local checkpoint: draft changes improved asset-entry validation, tracked-value wording, refresh and load-error states, and readability of large saved values on narrow screens. At that checkpoint, 140 Flutter tests passed locally and the app-fix commit passed the GitHub quality check. Those automated results did not establish a changed App Store build, a new Google Play bundle, or authenticated post-restoration behavior on a physical phone. Those remain distinct forms of evidence.

October 5 local checkpoint: the Flutter suite at that checkpoint passed all 335 tests. New mutation-timeout checks cover writes that may finish after the screen reports a timeout, late failures, and safe reconciliation without blindly repeating a write. These are local automated results, not a new coverage measurement or proof of the shipped app's behavior.

One specific regression keeps the portfolio open while a delete times out and is later rejected: the original asset stays visible and no unhandled widget error occurs. Codex implemented the regression and ran the automated checks. Brian's role remains product direction and hands-on testing. Each release candidate needs its own acceptance evidence; later development-device observations are recorded above.

Engineering decisions

• Repository interfaces: presentation code can be tested without coupling widgets to Supabase.
• Database-enforced ownership: authorization remains effective even if a client path is wrong.
• Explicit failure states: rejected sign-in, network failure, and failed mutations keep predictable UI and preserve known data.
• Artifact identity: version, source revision, signature, checksum, and physical result must describe the same candidate.
• Evidence contracts: release claims fail when required proof is missing, stale, inconsistent, or includes unresolved blockers.