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.
| | | |---|---| | 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 firm came to us with a problem that wasn't about building something new. It was about saving something that was already breaking.
They had an existing internal platform - built to manage tax workflows, submissions, approvals, and compliance tracking. In theory, it replaced the spreadsheets and manual processes the firm had been running on for years. In practice, the system was failing under real operational pressure.
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, the single most important feature for a regulated accounting firm, had gaps. Partners couldn't trust the data they were seeing.
The firm didn't need a new system. They needed someone who could look at the existing codebase, understand what was architecturally broken versus what was just poorly optimised, and stabilise it before the next filing deadline. Then rebuild the parts that couldn't be saved.
This is the pattern with internal tools: the pain isn't "we need software." The pain is "our software is supposed to work and it doesn't, and the next deadline is in 6 weeks."
Before writing a single line of new code, we did something most developers skip: we diagnosed the existing system.
The instinct - for most developers and most firms, is to propose a full rebuild. Scrap it, start fresh, build it properly. It feels clean. It sounds professional. And for a firm with active tax deadlines, compliance obligations, and staff who've already learned the existing system, it's the wrong answer.
The right answer was a two-phase approach:
Phase 1: Stabilise what exists. Find the architectural bottlenecks that are causing timeouts and failures. Fix the queries that are killing performance. Shore up the modules that crash under load. Get the system reliable enough to survive the next filing period.
Phase 2: Rebuild the parts that can't be fixed. Some problems aren't performance issues, they're architectural issues. An audit trail with gaps isn't a slow query. It's a data model that doesn't capture what it needs to capture. A workflow that allows unauthorised status changes isn't a UI bug. It's a permissions architecture that was never properly designed.
This diagnosis-first approach saved the firm months. Instead of a 6–12 month rebuild with zero platform availability during the transition, they got stability within weeks and a rolling upgrade path that never took the system offline during a filing deadline.
The first priority was performance. A system that's too slow to use is a system that doesn't exist, staff will revert to spreadsheets and manual processes, and every hour they spend on workarounds is an hour the firm is paying for twice.
50% reduction in application load time. The dashboard loads that were timing out during peak periods? Long-running queries hitting the database without proper indexing, pulling entire datasets when the UI only needed aggregated summaries. We restructured the query patterns to match what the interface actually needed.
60% improvement in API and server response times. The backend was processing requests sequentially where it should have been handling them concurrently. Endpoints that staff hit dozens of times per day, checking submission status, pulling client records, running reports, were the worst offenders. We optimised the critical path first.
Stabilised critical modules experiencing timeouts under load. During peak filing periods, multiple staff members hitting the same modules simultaneously would cause cascading failures. The architecture wasn't designed for concurrent access at the volumes a real accounting firm generates during deadline weeks.
This wasn't glamorous work. No new features. No redesigned UI. Just making the existing system do what it was supposed to do: work reliably when the firm needed it most.
But here's why it mattered strategically: every week the stabilised system performed reliably, the firm's trust in the platform grew. Partners who had stopped using certain modules started using them again. Staff who had built spreadsheet workarounds began retiring them. The system started becoming the single source of truth it was always supposed to be.
That trust was essential for Phase 2, because Phase 2 required the firm to rely on the platform for things they'd never trusted it with before.
With the system stable, we could address the structural problems that no amount of optimisation would fix.
For a chartered accounting firm, the audit trail isn't a feature. It's the foundation. If a regulator asks "can you prove this record was never improperly modified?" the answer needs to be immediate and definitive.
The existing system had gaps. Records could be modified without a clear history of who changed what and when. Deletions happened without mandatory reason capture. Multi-month audit reports were unreliable because the underlying data didn't track state changes consistently.
We implemented transaction-level audit trails - every change to every record is logged with who made it, when, and what the previous state was. Deletions require a mandatory reason capture. Historical reports can reconstruct the exact state of any record at any point in time.
This is the same architectural principle we apply to fintech builds: the audit trail is the data model, not a feature bolted on top. For regulated financial software, this is the difference between passing an audit and rebuilding 60% of your platform when the auditor arrives.
The firm operates with a clear hierarchy: Clerks prepare work. Partners review and approve. Super Partners have final authority on critical submissions. The original system implemented this loosely, roles existed but permissions were inconsistent, and the system allowed status changes that should have required approval.
We rebuilt the permissions architecture with granular approval flows: Clerk → Partner → Super Partner, with permissions varying by role and tax stage. Unauthorised status changes are prevented at the architecture level, not the UI level. "Rework required" loops are controlled, a Partner can send work back to a Clerk with specific notes, and the system tracks every round-trip.
This reduced approval ambiguity and operational risk. When a Partner approves a submission, it means something, the system enforces that the required review actually happened.
The firm had recurring monthly processes that were being done manually, creating tax entries, verifying they were created correctly, and flagging failures. Manual processes that run monthly are manual processes that fail at the worst possible time.
We automated monthly tax entry creation with scheduled jobs that run reliably without intervention. But automation alone isn't enough, you need to know when it fails. We built failure detection reports that confirm successful execution and flag any entries that weren't created correctly.
The audit-style reports show client name, tax type, entry creation status, and timestamps. Partners can verify at a glance that the automated process completed correctly. This directly addressed the trust concern: "If we automate this, how do we know it actually worked?"
The answer: the same way you'd verify it manually, except the system does it automatically and flags exceptions instead of requiring you to check every entry.
Beyond the core audit trail and workflow architecture, the platform now handles the full operational lifecycle:
Client & entity management with centralised records, history tracking, and controlled field updates based on business rules. No accidental data loss. No untracked changes.
Quality control dashboards with performance statistics, partner and super checker reports, and filters by assigned clerk and date range. Management can see who's doing what, how fast, and where bottlenecks are forming.
Correspondence and objection management with automatic linking, reducing the manual errors that come from staff manually connecting documents to cases.
Reporting with date-type aware filters for accurate monthly reporting, consolidated deadline views, and downloadable statistics. The reports match real workflow, not a generic template that "sort of" represents what the firm actually does.
Optimised notifications - reduced redundant emails, improved subject-line clarity with financial year context, and ensured notifications match real workflow actions. When staff get a notification, it means something happened that requires their attention, not that the system is generating noise.
We designed and managed a three-environment Heroku deployment: Development, QA, and Production. CI/CD pipelines for safe deployments. The ability to push live production fixes during critical deadlines without taking the system offline.
For an accounting firm, deployment discipline isn't optional. A bad deploy during filing week doesn't just create a bug, it creates a compliance risk. Every deployment goes through QA. Every production fix is tested before it touches live data.
We handled live outages and dependency conflicts with minimal disruption, including during peak operational periods when the system couldn't afford downtime.
One of the most valuable - and least visible, parts of this project was translating between accounting partners and the development process.
Accounting partners think in terms of submissions, deadlines, audit requirements, and regulatory obligations. Developers think in terms of data models, API endpoints, and deployment pipelines. The gap between these two worlds is where most internal tool projects fail.
We acted as the bridge: taking accounting-domain requirements and translating them into technical architecture that actually serves the workflow. When a partner says "I need to know that no one changed this record after I approved it," that's an audit trail architecture requirement. When a clerk says "I can't find the correspondence for this objection," that's a data relationship problem.
This translation work, understanding the domain well enough to build for it, not just code for it, is why the platform works under real operational pressure instead of just looking good in a demo.
50% faster load times - dashboards that timed out during peak periods now respond instantly.
60% faster API responses - the endpoints staff hit hundreds of times per day are optimised for their actual usage patterns.
Full audit readiness - transaction-level audit trails, mandatory reason capture for deletions, and historical reports that can reconstruct any record's state at any point in time.
Faster approvals with fewer blockers - granular RBAC means the right people approve at the right stage, with no ambiguity about who authorised what.
Automated tax workflows - monthly processes that were error-prone and manual now run reliably with automatic failure detection.
Clear visibility into errors and corrective actions - when something goes wrong, the system shows exactly what happened, when, and what needs to be fixed.
A stable platform that evolves with regulatory needs - the architecture is designed to absorb new compliance requirements without rebuilding the foundation.
Every B2B company has a process that eats 10–20 hours per week in manual work. Everyone knows it should be automated. Nobody does it because generic SaaS tools don't fit the exact workflow.
This project proves the pattern: 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 we mapped.
When I discuss past work, I share process decisions, architecture approach, and timelines. Never the product itself. Never the client.
I don't share what clients build. I don't name them. When I reference this project, I talk about the audit trail architecture, the stabilisation approach, and why diagnosis before rebuild saved months. Your idea stays yours.
I run free 30-minute Build Plan sessions for firms and founders who need a second opinion on their internal tool architecture.
You describe the process that's eating your team's time. No sensitive data needed. I map what a custom tool, or a rebuilt tool, looks like: architecture approach, realistic timeline, and cost range. 1-page scope document. Yours to keep.
DM me 'BUILD PLAN'
