All work
04 / 09Shipped

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

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

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.

How it fits together

Clients

  • Angular portalBuilt features

    Customer-facing features for reports, subscriptions and loans.

  • Internal toolsBuilt features

    Admin screens the team uses to run the platform.

Backend (ASP.NET Core)

  • REST API endpointsBuilt

    The contract the Angular apps call.

  • Business logicBuilt

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

  • Entity FrameworkBuilt

    Data access over the SQL Server schema.

Data & services

  • SQL ServerDesigned & 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.

My contribution

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

Challenges I solved

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

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

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

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

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

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

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

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

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

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

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.
Next projectFitMind AI