FinTech / RegTech • Audit-Ready • Chartered Accounting Firm (South Africa)
Confidentiality Notice: This case study discusses process decisions, architecture approach, and timelines only. No product features, user flows, or client-identifying details are disclosed. The client's intellectual property remains fully protected.
Project Snapshot
Industry- Financial Services / Chartered Accounting
Regulatory Environment- South African Tax & Audit Compliance
Platform Type- Internal Operations & Workflow Automation
Project Scope- Legacy Stabilisation → Production-Grade Rebuild
Tech Stack- React (Frontend) · Node.js (Backend)
Infrastructure- Heroku (Dev / QA / Production) · CI/CD Pipelines
Key Architecture- Audit Trail · RBAC · Multi-Role Approval Workflows
Key Results- 50% faster load times · 60% faster API response · Full audit readiness
The Problem
The firm had an existing internal platform built to manage tax workflows, submissions, approvals, and compliance tracking. In theory it replaced spreadsheets. In practice it was failing.
- Dashboards timed out during peak filing periods
- Critical modules crashed under load
- API responses were slow enough that staff reverted to manual workarounds
- The audit trail had gaps, partners could not trust the data they were seeing
The pain was not "we need software." The pain was "our software is supposed to work and it does not, and the next deadline is 6 weeks away."
The Approach
Before writing a line of new code, the existing system was diagnosed. The instinct for most developers is to propose a full rebuild scrap it, start fresh. For a firm with active tax deadlines, compliance obligations, and staff who had learned the existing system, that was the wrong answer.
The right answer was a two-phase approach:
Phase 1: Stabilise what exists. Find the architectural bottlenecks causing timeouts and failures. Get the system reliable enough to survive the next filing period.
Phase 2: Rebuild the parts that cannot be fixed. An audit trail with gaps is not a slow query, it is a data model that does not capture what it needs to capture. A workflow allowing unauthorised status changes is not a UI bug, it is a permissions architecture that was never properly designed.
This approach saved the firm months and never took the system offline during a filing deadline.
What Was Built
Phase 1 — Legacy Stabilisation
Dashboards that timed out during peak periods were pulling entire datasets when the UI only needed aggregated summaries. Query patterns were restructured to match what the interface actually needed.
Backend endpoints were processing requests sequentially where concurrent handling was needed. The critical-path endpoints checking submission status, pulling client records, running reports were optimised first.
Result: 50% faster load times, 60% faster API responses, zero module crashes under filing-period load.
Phase 2 — Architecture Rebuild
Audit Trail Architecture
Every change to every record is now logged with who made it, when, and what the previous state was. Deletions require mandatory reason capture. Historical reports can reconstruct the exact state of any record at any point in time. This is the difference between passing an audit and rebuilding 60% of the platform when the auditor arrives.
Role-Based Access Control and Approval Workflows
Rebuilt the permissions architecture with granular approval flows: Clerk to Partner to Super Partner, with permissions varying by role and tax stage. Unauthorised status changes are prevented at the architecture level, not the UI level. Every approval round-trip is tracked.
Tax Automation Engine
Monthly tax entry creation is now handled by scheduled jobs that run reliably without intervention, with failure detection reports confirming successful execution and flagging any entries not created correctly.
Supporting Systems
Client and entity management with controlled field updates. Quality control dashboards with performance statistics filtered by clerk and date range. Correspondence and objection management with automatic document linking. Reporting with date-type aware filters and consolidated deadline views.
Results
| Area | Impact |
|---|---|
| Application load times | 50% faster |
| API response times | 60% faster |
| Audit readiness | Full transaction-level audit trail, reconstruction of any record state at any point |
| Approval process | Granular RBAC with no ambiguity on who authorised what |
| Tax workflows | Automated with automatic failure detection |
| Platform reliability | Stable through filing deadlines with live fix capability |
The Principle
Internal tools succeed when the architecture matches the actual workflow, not when the workflow is forced to match the tool.
The platform does specific things tax workflows, approvals, audit trails, compliance tracking. But it does those things precisely right for how this firm actually operates. Not a generic approximation. Not a template adapted from another industry. A system built for the real process, including the exceptions, edge cases, and regulatory requirements that generic tools handle poorly or not at all.
The scoping conversation understanding exactly how the team works, what inputs come from where, what exceptions happen, what the reporting needs to look like — is where the real value lives. The code is just implementing what was mapped.