Trace before changing
Follow legacy actions through UI, application and database layers, identify observable outcomes and preserve the operator flow before considering structural improvement.
← Back to homepage work
Current role · Senior Software Engineer
Jonas FinTech.
Modernising established financial software by understanding the behaviour that already exists, moving it incrementally into maintainable .NET applications, and validating that the new system still does what the business needs.
- When
- Jul 2026 – Present
- Focus
- Legacy modernisation · backend engineering · behavioural parity
- Stack
- C# · .NET · ASP.NET Core MVC · EF6 · SQL Server · NUnit
- Workflow
- Claude Code CLI · MCP · source-led planning and validation
Context
Modernisation without losing the system in the rewrite.
I work on established financial software where the challenge is understanding years of existing behaviour and moving it forward without breaking the processes that depend on it.
My work at Jonas FinTech centres on modernising established financial software. The interesting part is not translating old syntax into newer syntax. It is discovering what the existing application actually does across its user interface, application logic and database behaviour, then moving that behaviour safely into the newer architecture.
That means treating the legacy system as evidence rather than assuming a generated implementation is correct because it compiles or has high test coverage. Changes are broken into smaller, reviewable steps and compared against the behaviour they are replacing.
The goal is not a prettier rewrite. The goal is a replacement that preserves required business outcomes while becoming easier to understand, test and change.
Selected engineering work
Where the work gets technical.
The work repeatedly comes back to three things: understanding existing behaviour, moving it into clearer C# boundaries, and proving the replacement works beyond a green build.
Move database behaviour into C#
Work with EF6, SQL Server, generated POCO models and existing stored-procedure behaviour, moving focused capabilities into application Services with tests around the required outcome.
Validate beyond a green unit test
Investigate parity defects, query-translation failures and generated assumptions that can pass LINQ-to-Objects tests while still failing against the real EF6 provider.
AI-assisted engineering
AI-assisted engineering, with judgement still in the loop.
Coding agents help me navigate large systems, structure migration work and reduce repetitive implementation effort. Source behaviour, tests and engineering judgement still decide what is correct.
Understand
Use source, project context and connected tooling to navigate unfamiliar code, workflows and dependencies.
Plan
Turn an outcome into explicit implementation items, blockers, validation and acceptance criteria before broad code changes begin.
Implement
Use Claude Code CLI, MCP and reusable repository workflows to accelerate well-defined implementation and test work.
Validate
Review generated diffs, run focused tests and compare against current source, provider behaviour and human domain evidence.
Engineering approach
Incremental by design.
01
Correctness first
Understand the current behaviour and preserve required outcomes before attempting architectural cleanup.
02
Clear boundaries
Keep application entry points thin, workflow coordination explicit and focused data/business capabilities in the appropriate Service layer.
03
Realistic validation
Use tests as evidence, not proof in isolation. Provider behaviour, database state and old-versus-new outputs matter where the technology can behave differently at runtime.
04
Change what earns its keep
Prefer simple changes that improve readability, remove demonstrated duplication or support a realistic extension, rather than restructuring code for pattern purity.
C#.NETASP.NET Core MVCEntity Framework 6LINQ to EntitiesSQL ServerNUnitGitClaude Code CLIMCP