Purchase Decision API
LiveA REST API that scores a purchase against income, savings goals, and spending history, and returns a BUY / WAIT / SKIP verdict with a score and a savings timeline. It is the one running in production. Try it above.
I build backends and ship them. One is live in production right now.
This console talks to Purchase Decision API, running in production right now. Type something you'd want to buy, set a price, and hit Send. The verdict that comes back is my rule engine deciding, not a canned response.
A call hits the gateway, clears JWT auth, runs the rules in the service, and only then touches Postgres. The rules layer sits above the service because it answers before the database is ever asked.
Every project below is built on this shape.
A REST API that scores a purchase against income, savings goals, and spending history, and returns a BUY / WAIT / SKIP verdict with a score and a savings timeline. It is the one running in production. Try it above.
This is a REST backend for book issuance, returns, and transactions. It has role-based access control (admin / librarian / member), enforced through a Spring Security filter chain.
This is a healthcare CRUD backend for records, appointments, and history. It has a layered controller-service-repository architecture, request validation, global exception handling, and JUnit tests over the service layer.
This is a full CRUD API with DTOs across POST / PUT / PATCH / DELETE. It is containerised with Docker and tested in Postman.
six sides of the stack · drag to spin
I write about the things I debug. Most of it is Java and Spring Boot, from the inside, on Medium.
I'm a Java backend developer. I build REST APIs with Spring Boot, secure them with JWT and Spring Security, back them with PostgreSQL, and deploy them with Docker and CI/CD. One of them is running in production right now.
Before this I worked inside production systems on the support side, which is where I learned how software actually fails: reading stack traces, tracing API errors, and working with backend teams on root causes.
Everything in my projects is code I wrote, deployed, and can explain line by line, including what I'd do differently. And when I figure something out the hard way, I write it down so the next person doesn't have to.