$ cd ../projects

CreditGenius

Backend and frontend work on a credit platform: reports, subscriptions, billing and micro-loans.

Role
Full-Stack Developer · remote
Year
2025–2026
Type
Full-stack
Status
Shipped

$ cat brief.md# In short

The problem
A credit platform has to keep money moving: reports and subscriptions get billed, and micro-loan repayments still have to be collected when a payment fails.
My contribution
Remote work, mostly on the backend: ASP.NET Core services, database schemas and queries, REST endpoints, and payment and subscription flows, including the automatic re-collection of failed micro-loan repayments. I also built Angular features and internal tools on top of those services.
Result
The work went into a production platform, alongside senior engineers who reviewed the database design and the deployments.
Platform
In production. A client system, so there are no screenshots here

$ cat README.md# System overview

CreditGenius is a credit platform: credit reports and scores, subscriptions, billing and micro-loans, built on ASP.NET Core with SQL Server and AWS.

I worked on it remotely, mostly on the backend: services, database schemas and queries, REST endpoints and the payment and subscription flows, including the automatic retry of failed micro-loan repayments. When a scheduled repayment doesn't go through, the loan can't be left unpaid, so the system tries again on a schedule instead of waiting for someone to notice. I also built Angular features and internal tools on top of those services.

$ tree architecture/# How it fits together

Clients

  • Angular portal

    Built features

    Customer-facing features for reports, subscriptions and loans.

  • Internal tools

    Built features

    Admin screens the team uses to run the platform.

Backend (ASP.NET Core)

  • REST API endpoints

    Built

    The contract the Angular apps call.

  • Business logic

    Built

    Payment and subscription workflows, including micro-loan repayment retries.

  • Entity Framework

    Built

    Data access over the SQL Server schema.

Data & services

  • SQL Server

    Designed & optimised

    Schemas, queries and stored procedures.

  • AWS S3

    Storage and retrieval of user-generated files.

  • PDF generation

    Production reports and documents.

  • Amazon SES

    Transactional email and notifications.

$ git log --author=amar# My contribution

  • Built and maintained backend services with ASP.NET Core on AWS Lambda, Entity Framework and SQL Server.
  • Designed and optimised database schemas, queries and stored procedures.
  • Implemented business logic, REST API endpoints and payment and subscription workflows in production.
  • Built the automatic re-collection of failed micro-loan repayments: a failed payment is picked up and retried on a schedule instead of being dropped.
  • Built Angular frontend features and internal tools on top of those backend services.
  • Implemented file storage and retrieval with AWS S3 for user-generated content.
  • Built PDF generation for production reports and documents.
  • Integrated transactional email and notifications with Amazon SES.
  • Worked with senior engineers on database design, architecture decisions and production deployments.

$ cat fixed-bugs.md# Challenges I solved

  1. A failed repayment can't just be forgotten, but it also can't be retried carelessly against someone's account.

    Failed payments are re-collected on a schedule, so the loan keeps moving toward repayment without anyone chasing it by hand.

  2. Money and subscription flows fail in ways a normal CRUD app never sees: declined cards, partial payments, repeated webhooks.

    The business logic treats failure as an expected path, with the state kept in SQL Server so a payment is never half-applied.

  3. Reports and documents had to leave the system as files people can keep, not as web pages.

    A PDF generation workflow turns production data into documents, and Amazon SES delivers them and the related notifications.

  4. User-generated files don't belong in a relational database.

    Uploads and downloads go through AWS S3, with the database holding only the references.

  5. Queries written for a small dataset get slower as real data arrives.

    Schemas, queries and stored procedures were reworked for the access patterns the platform actually uses.

$ cat learned.txt# What I learned

  • Working in a large existing codebase written by other people, and matching its conventions instead of my own.
  • C#, ASP.NET Core and Entity Framework on SQL Server, coming from Dart, TypeScript and Python.
  • Reviewing database design and architecture decisions with senior engineers, and shipping to production with them.
  • That money flows need to handle failure as a normal case, not an exception.
  • Using managed AWS services (S3 for files, SES for email) instead of building those parts myself.

$ cat package.json# Stack

C# · ASP.NET Core · AWS Lambda · Entity Framework · SQL Server · Angular · AWS S3 · Amazon SES

# Next project in the logGiBud