← All case studies

Financial operations · Founder led platform build

Give each credit union role a clear daily workflow

A teller, a loan officer and a board member work from the same operation, but need different tasks and permissions. I led the product plan, delivery and verification for a credit union platform built around those differences.

Credit union operations, connecting member records, role based work and approval controls.
My role
Program owner, requirements and delivery lead
Work
Workflow design, reporting, AI assisted development and QA
Project context
Platform delivery snapshot, with open work remaining

One operation, several daily jobs.

Credit union operations connect member onboarding, savings and shares, cash at the front desk, loans and accounting. A teller needs to complete a transaction; a manager needs to see approvals waiting; the board needs a read only view of the operation.

I structured the product around these jobs before assembling the ERPNext and Frappe modules. The aim was a coherent daily workflow across records, permissions and management reporting.

Turn operational rules into a build plan.

I owned the product structure, module breakdown and delivery sequence through AI Byters. I translated the operating requirements into user roles, branch access, approval rules and written flows.

I also defined the questions each management dashboard should answer and coordinated the product, data, model and infrastructure workstreams. I worked hands on with AI assisted development and ran role based QA; this was both delivery leadership and practical build work.

A withdrawal follows the member’s daily context

  1. 01

    Member & account
    Check account state and branch access

  2. 02

    Daily amount
    Consider the cumulative withdrawal total

  3. 03

    Approval gate
    Apply the configured control

  4. 04

    Authorised action
    Approve and record the transaction

A workflow view of the delivered controls. Approval remains a human responsibility.

Put the control at the point of action.

The build connected member and account records to front desk transactions and the loan lifecycle, from application through approval, disbursement and repayment. Account holds and branch scoped access belonged in those paths, rather than being separate instructions for staff to remember.

A large withdrawal gate considered a member’s cumulative daily total. That choice matters because checking only the latest transaction can miss the total amount moved during a day. Authorised people retained approval and credit decisions.

For management reporting, I treated plausible placeholder figures as a product defect. The QA work checked that dashboards used daily snapshots and showed an empty value when a figure was unavailable.

Verify the workflow as the person using it.

I documented and walked 13 operational paths, including members, accounts, front desk, loans, reporting, scheduled work and security. Audit findings were tracked with the issue, fix and verification result.

At the delivery snapshot, 57 of 70 findings were closed and 13 remained open. This marks the state of the product at that point, not a claim that every issue was resolved.

The outcome was an integrated product build with explicit roles and controls. Customer adoption, lending performance and predictive model effectiveness are separate questions from this delivery work.

Operational paths

13

Documented flows walked during QA.

Findings closed

57 of 70

Thirteen findings remained open in the original snapshot.

Product delivery scope, not a measure of customer adoption or lending outcomes.

Open the work

Where does an approval leave the workflow?

Bring the roles, transaction rules and reporting questions. We can map the handoff before choosing modules.

Discuss an operations workflow ↗ Email me

Project experience by Mehrab Mashrafi. Updated .