Senior Cloud-Native .NET / Full-Stack Engineer

Personal project · In active development

Zeka: client and case management for social organisations

I’m building Zeka with a .NET backend and an Angular frontend. The project brings together client and case management, access controls, and data isolation between organisations.

Architecture decisions

• Multi-tenancy: organisations share the product, so data access must enforce separation between them. A tenant identifier alone is insufficient.
• Authorization: each operation must check the user’s organisation membership and permissions before returning data.
• Clean Architecture: I keep business rules and use cases separate from the API and database code so changes to one have less impact on the others.
• Service boundaries: services own their data and communicate through explicit contracts. Adding a service also adds work to keep data consistent, handle failures, and operate it; that cost needs justification.
• Architecture Decision Records: I record the context, alternatives, and consequences of a decision so others can review the trade-offs and see which proposals have been accepted.

These decisions guide development. Some planned capabilities still need to be implemented and deployed.

Changes merged so far

• PostgreSQL tenant-isolation controls, including row-level security and restricted runtime roles. Backend implementation: PR #64.
• An authorized beneficiary lookup with bounded results and cancellation support. Backend implementation: PR #88.
• A frontend fix that makes keyboard and pointer client selection trigger the same navigation, covered by regression tests. The frontend source is private.

Current status

I use Zeka to test architecture decisions by writing code, running tests, and reviewing changes, including AI contributions. The work linked here has been merged. Production operation, customer adoption, and product completion remain unverified.

Explore the public backend repository. The frontend repository is private.

Engineering workflow

How I use AI in engineering

I give AI tools specific development tasks, review their code and analysis, and record checks that others can repeat. I remain responsible for the requirements, the review, and decisions to merge or publish.

I build and share practical AI engineering skills focused on code quality, reproducible verification, and reliable human-AI collaboration. Explore the Zeka UI Evidence skill.

From task to approval

1. Define the task: set the scope, acceptance criteria, and source revision before delegating the work.
2. Implement the change: keep it within scope and provide a diff with relevant regression test results.
3. Review independently: check the behaviour, question assumptions, and verify the supporting results.
4. Make checks repeatable: record the revision, commands, results, and limitations. Report existing failures separately from new regressions.
5. Approve the result: require human approval for consequential changes, merges, and publication.

Example: keyboard activation in client lookup

A Zeka fix used Angular Material’s selection event to make keyboard and pointer selection trigger the same navigation. Regression tests covered both paths using fictional data.

The test report listed existing suite failures separately and stated what the simulated interactions covered. Checks in a physical browser and with assistive technology remained outside that test scope.

This example documents one reviewed correction. It provides no measure of productivity gains or fully autonomous delivery. The frontend source and detailed test evidence remain private.