TradeLedger Live / Client case study
The problems.
How we solved them.
A shared journal, clearer portfolio reviews and connected business operations—what the software supports and how it reduces repeated work.
Capabilities are drawn from the supplied document’s 15 October 2026 software review. Hidden features, manual steps and remaining validation are identified below. The graphs describe scope; customer results, revenue and time savings were not measured.
The scope, made clear.
Functional coverage and implementation status from the 15 October 2026 source review.
15 mapped business functions
Grouped responsibilities across the product and its operations
- Customer experience & research
- 6
- Business operations
- 4
- Platform & delivery
- 5
The report’s responsibility map is grouped here for readability. These counts describe software scope, not employee numbers, adoption or measured savings.
7 named broker entries
Connection code and placeholders are shown separately.
Connection code: Zerodha, Upstox, FYERS, Angel One and Groww.
Placeholders: Dhan and 5Paisa.
All five implemented connection paths sit behind a customer broker screen that is hidden at launch. Live connectivity was not tested. Read the broker scope
The work, function by function.
Fifteen business responsibilities with the problem, documented solution and practical benefit together.
Product & Customer Experience
Documented application supportThe problem
New users need a clear route from registration to their first useful journal review, with preferences that remain consistent when they return.
How we solved it
- We built registration, sign-in, password recovery, profile setup and feature tours.
- Saved appearance and default-view preferences support a more consistent customer workspace.
Theme support varies across customer, marketing and admin screens. Native sign-in behaviour still needs separate validation.
How this helps the team
Users can follow a guided starting path and keep their preferred setup, reducing repeated configuration and basic onboarding questions.
Trading Journal Operations
Documented application supportThe problem
Manual trades, imported history and open positions need consistent records, with a practical way to correct mistakes without losing unrelated data.
How we solved it
- We built manual trade entry, spreadsheet and CSV import, column mapping and preview, with source and import-batch labels.
- Lot-aware position handling supports partial closes, while batch removal and realised-trade CSV export support review and correction.
This records trading activity; it does not place broker orders. The CSV export covers realised history rather than every account record.
- Choose a history file
- Map columns and preview
- Save with a batch label
- Review or reverse that batch
How this helps the team
Users can bring records into one journal and isolate a bad import, reducing repeated re-entry and the work of rebuilding a clean history.
Portfolio Analytics & Research
Documented application supportThe problem
Booked results, open positions and trading capital need to stay distinct so users can understand what their journal is actually showing.
How we solved it
- We connected the dashboard, portfolio, capital-flow records and analysis views, with date and asset filters.
- Charts, lot details, concentration and holding-age checks, watchlists and rule-based review prompts connect summaries to the underlying records.
Results depend on entered records, stored prices and capital assumptions. They are not independently verified investment performance or brokerage balances.
How this helps the team
Users can review closed trades and open exposure together, then inspect the relevant records, reducing manual spreadsheet assembly for a routine review.
Customer Success & Support
Documented application supportThe problem
Support needs customer messages and account context together before deciding whether a payment, credit or product issue needs action.
How we solved it
- We added customer contact intake, help content and admin message and request handling.
- Authorised operators can inspect relevant account context, update status and make permitted credit or plan corrections with an audit record.
Response times, customer satisfaction and reductions in support volume were not measured in the report.
How this helps the team
The team can investigate from a shared record instead of repeatedly collecting the same account details across separate conversations.
Billing & Finance Operations
Top-ups enabled · subscriptions hiddenThe problem
Payment confirmations need to grant the correct report credits once, while customers and support staff need a traceable purchase and balance history.
How we solved it
- We built hosted checkout, server payment verification, purchase records, invoices, credit ledgers and duplicate-processing controls.
- Customer billing views and authorised admin adjustments support balance review and entitlement corrections.
The reviewed launch configuration enables credit top-ups and hides subscription purchase screens. Bank settlement reconciliation and full company accounting are outside the demonstrated scope.
- Start credit checkout
- Verify provider payment
- Grant the entitlement once
- Update history and balance
How this helps the team
Payment and credit records stay connected, reducing the manual work needed to explain a balance or investigate a missing entitlement.
Marketing & Growth
Publishing remains manualThe problem
The team needs a repeatable route from a content brief to approved copy, an approved asset and a record of what was published.
How we solved it
- We built content drafting, copy and asset review, approval states, scheduling fields and manual performance feedback.
- Public blog and search metadata tools support discovery, while referral and coupon workflows manage eligible non-cash credit rewards.
Automatic social publishing is disabled in the reviewed code. Referral rewards and content tools do not establish customer acquisition or campaign results.
- Prepare a content draft
- Review copy and supplied asset
- Publish manually
- Record feedback for the next draft
How this helps the team
Reviewers can see the next content action and reuse the previous feedback, reducing scattered approvals and repeated draft preparation.
Sales & Business API Partnerships
Documented application supportThe problem
Integration customers need a clear way to evaluate the service, obtain scoped access and review their usage.
How we solved it
- We built the BusinessCopilot proposition and a separate developer workspace with projects, API-key management, documentation and usage views.
- Keys can be scoped, rotated or revoked, with quota and ownership checks on supported routes.
Enterprise contracts, API revenue and customer adoption were not verified. A named API scope does not establish a working endpoint for every advertised capability.
How this helps the team
Teams have a structured integration starting point and access lifecycle, reducing ad hoc credential coordination and manual usage checks.
Broker Integration Operations
Implemented · hidden at launchThe problem
Broker records can overlap with manual entries, arrive in different formats or omit details needed to explain a portfolio change.
How we solved it
- Connection and synchronisation code covers Zerodha, Upstox, FYERS, Angel One and Groww, with normalisation, source labels and conflict review.
- Snapshots and saved reconciliation decisions support later comparisons instead of treating a missing holding as an assumed sale.
The customer broker screen is hidden by the launch configuration. Live connections were not tested. Dhan and 5Paisa remain disabled placeholders.
- Connect and check the session
- Fetch and normalise records
- Review overlaps and differences
- Save the accepted journal merge
How this helps the team
Once enabled and validated, this workflow can reduce repeated copying and help users review overlaps before merging broker records.
Engineering & Data Platform
Documented application supportThe problem
Journal edits, portfolio lots and shared screens need a consistent data path, including a way to recover the interface when a save fails.
How we solved it
- We connected shared journal state to granular records for realised trades, open positions, cash flows and watchlists.
- Source identifiers, migration helpers and failed-save rollback support record consistency across the workspace.
Concurrent edits, migrations and recovery still require operational testing; source review alone does not establish reliability in production.
How this helps the team
Shared records reduce repeated data preparation across screens and give engineering a clearer basis for investigating record changes.
AI Reports & Market Intelligence
Documented application supportThe problem
Users need readable reviews of their own journal and a separate view of external market context, without confusing the two sources.
How we solved it
- We built journal-review reports using the selected trading records, with saved history and PDF export.
- Market Insights has separate asset and mode selection, credit handling, cached reports and source or freshness information.
The host and Copilot long-term stock requests need alignment. Report generation, credit charging and failure refunds also need end-to-end validation; analytical scores are not verified success rates.
How this helps the team
Users can prepare and revisit a scoped review without manually assembling the same figures and narrative each time.
Security & Access Administration
Documented application supportThe problem
Customer records, support actions, billing adjustments and integration keys need clear access boundaries and accountable changes.
How we solved it
- We built identity checks, a separate admin flow and four named operator roles with permission-controlled actions.
- Server-managed broker sessions, scoped API keys and admin audit records support sensitive workflows.
Direct data access, field permissions and recovery require further testing. No independent security certification is established by the report.
How this helps the team
Operators can work through defined actions and investigate recorded changes, reducing reliance on informal access and untracked adjustments.
Infrastructure & Release Operations
Documented application supportThe problem
The customer app, market-intelligence service and broker service need coordinated releases and visibility of recurring background work.
How we solved it
- We added build and deployment automation, scheduled entitlement reconciliation and market-data refresh paths.
- Separate service configuration supports the customer app, Copilot and broker connectivity.
The report did not verify deployed schedules or service health. Coordinated version checks, regression gates and recovery exercises remain next steps.
How this helps the team
Repeatable release and scheduled-work definitions reduce the need to reconstruct the deployment process for every change.
Quality Assurance & Research Validation
Research & simulationThe problem
Market-analysis changes need a way to inspect historical behaviour and simulated sessions before stronger product claims can be assessed.
How we solved it
- We built historical comparison and stock backtest interfaces, plus a Testing Lab for simulated index sessions.
- Fixtures, data replay and research records support repeatable investigation of analysis behaviour.
These tools do not execute broker trades or prove predictive performance. Independent validation, realistic costs and holdout evaluation remain necessary.
How this helps the team
Researchers can inspect stored scenarios and simulated activity in a common workspace, reducing manual reconstruction of each experiment.
Business Intelligence
Documented application supportThe problem
Product and support teams need to find usage, report errors and entitlement activity without gathering separate records for every investigation.
How we solved it
- We added admin overview, per-user usage, report and credit activity, request records and analysis diagnostics.
- Authorised views connect summaries with the relevant user or operation details.
Actual usage, revenue, costs and retention were not exported. Interface counters are not verified cloud bills or measured business outcomes.
How this helps the team
The team has a more consistent starting point for investigating product activity and deciding which issue needs attention.
Policy & Account Data Administration
Documented application supportThe problem
Customers need accessible policies and account controls, while the business needs a clear record-retention and removal process.
How we solved it
- We added public policy pages, account and data settings, reauthentication for sensitive actions and a staged account-removal path.
The existing removal path does not establish erasure of every server-owned or downstream record. A complete retention and deletion review remains proposed.
How this helps the team
Customers can find the relevant controls in one place, while staged removal gives the team a clearer sequence to investigate if an operation fails.