Led the design and API build for the Financial Goals feature at Assiniboine Credit Union, replacing free-text review notes with structured goals and review history so any advisor can pick up where the last one left off.

A financial review is a structured conversation between an advisor and a member. Together they pick one to three key financial goals the member commits to acting on, and the advisor follows up on each one afterward. There was no dedicated web tool to capture those goals, track their details, or manage the follow-up. Advisors used notes.

Notes are searchable, but advisors write them for all kinds of reasons, and they're often thin: sometimes just "review done". That tells the next advisor nothing when they're sitting in front of the member.

What a bad day looked like: scrolling through every note to find the last financial review (if one even exists), then starting the conversation from scratch because there's no context on the member's goals or plan from last time.

The executive advice team and the service delivery team raised the problem. They wanted two things: a more detailed record of what was discussed in a review, and insight into how many advisors were completing financial reviews with members.

My manager raised this alongside other work. I took it because it sits squarely on why I build software: tools that help advisors give members confidence and clarity in their financial plans, with business value for leadership on top.

I was assigned the whole feature and asked to propose the solution. I wrote the Azure DevOps feature and user stories, then built the .NET REST API service while another software developer built the UI screens. Our Product Owner approved every piece of UI wording, a senior software developer signed off on each design decision I made, and I demoed incrementally to advisors and stakeholders.

At sprint planning, with the product manager, my manager, the senior software developer, and teammates, we went through the requirements and the limits of the current system. The first recommendation from some teammates was to build another service for this feature to live in, which is how the team had built every feature so far.

I pushed back, because of where the team already stood: five of us were running and maintaining close to 30 services, and the maintenance burden was already being felt. I raised the nanoservices anti-pattern and wrote a decision document laying out two options and a recommendation. A financial goal on its own wasn't big enough to justify a standalone service, and it's easier to start with a well-scoped service and split it later than to justify a new one up front. That follows Sam Newman's warning about premature decomposition in Building Microservices.

The option I recommended: add the goals to the existing net worth statement service, and rename it the Financial Planning Service, since net worth and financial review goals belong to the same business domain. The goals shipped in that service; the rename is planned but not done yet. Extending it also gave us deployment, and a financial review starts with the member's net worth statement, which the advisor may want to update.

The risk I named: this breaks an established pattern the team had agreed on, and a pattern break shouldn't be one person's call. The document said so directly and asked the team to decide together, and the team agreed. It also covered the other outcome: if the team kept the pattern, we'd open a separate story to investigate how service-per-entity scales for a team our size.

A third idea also came up: let advisors tick a box on the services tab and write a note on the service they performed (here, a financial review), so all the notes live in one place. It would have cost very little development time, but advisors could still write anything in that box, including "review done". Free text was the original problem.

I demoed the work to the wider software team, including DBAs, QA, the software development manager, the Product Owner, and other developers.