Technical depth across backend, frontend, and product delivery

I architect REST APIs in Python — FastAPI and Flask — and design the MySQL schemas underneath them. At RE:SOLVR I own end-to-end feature development on Zimplicit, a business process management platform: schema, endpoint, validation, and failure behaviour, delivered alongside the rest of the platform team.

I work comfortably in both modes. Inside an existing team I pick up its conventions and review process and work to the sprint — I have worked in Scrum with sprint planning and daily standups since my first engineering role. On smaller builds I am often the only engineer, carrying a project from data model through API and UI to deployment on my own.

Either way the first step is the same: agree the API contract before any UI is built. It sounds procedural, but it is the single thing that stops a frontend and a backend drifting into two incompatible ideas of the same feature — and it means the UI can be built against something stable instead of a moving target.

On Crop Element the backend was a Flask REST API serving two separate ML models — a Naive Bayes crop recommender and an Inception v3 disease detector — behind one interface a React frontend could consume without knowing either model existed.

I build responsive application UIs in React with Redux Toolkit for state, in Next.js when a project wants server rendering and routing out of the box, and in Angular on the platforms built around it. Most of my frontend work is dashboards and internal tools rather than marketing pages — dense, stateful screens where performance problems come from re-renders and payload size, not from images.

The work I would point to first is the Angular modernization at Oizom. Envizom was a real-time air quality monitoring system on a legacy Angular codebase. I upgraded it to the current version, refactored it to type-safe TypeScript patterns, and added code splitting and lazy loading — while shipping 12+ features and resolving several bugs against the same codebase.

That combination is the part I care about: migrating a legacy frontend is straightforward if you can freeze feature work, and much harder when you cannot.

I build retrieval-augmented generation systems end to end: ingestion, chunking, embeddings, vector search, and grounded generation with citations. At RE:SOLVR I engineered a RAG chatbot on the Zimplicit platform using the OpenAI API for generation and Qdrant for retrieval, so answers come from the business's own documents rather than the model's training data.

The engineering effort in these systems is not the model call. It is getting the right passages back before the LLM is involved, and deciding what the system does when retrieval returns nothing useful — abstaining is usually better than answering confidently from nothing.

EigenTalk applies the same pattern to a different surface: a Next.js and TypeScript research assistant that turns uploaded documents into a searchable, conversational knowledge base.

I write to SOLID principles with a clear service layer, and reach for event-based design where components genuinely need to be decoupled rather than as a default. The goal is narrow: a codebase where adding the fifth feature costs about what the second one did.

On the delivery side I ship containerized services through CI/CD pipelines, so releasing is a routine step rather than an event. I use AI coding agents daily as part of the workflow — for the mechanical parts of refactoring and test scaffolding, with the design decisions staying mine.