Senior Full-stack Developer & AI product builder  · 

Situation

Screenchat, my real-time movie chat platform, has a React-based website frontend alongside its Node.js/MariaDB backend. The website relied on REST-style API calls that returned fixed, often bloated payloads — including nested data like room details, message history, and movie metadata the frontend frequently didn't need in full — increasing payload size and slowing page load and interaction times.

Task

I needed to let the web frontend request exactly the data it needed for a given view, cutting down on over-fetching without maintaining a growing sprawl of bespoke REST endpoints for every use case.

Action

I introduced GraphQL across both sides of the web stack:

• Built a GraphQL layer on the Node.js server, defining schemas and resolvers for core entities (rooms, messages, movies, users) so the frontend could query precisely the fields it needed in a single request.
• Integrated a GraphQL client into the React website frontend, replacing multiple fixed REST calls with targeted queries shaped to each page's actual data requirements.
• Structured resolvers to avoid the classic N+1 query problem, keeping backend performance consistent even as query flexibility increased.

Result

API responses shrank significantly by eliminating unused fields and redundant nested data, reducing payload size and improving page load times on the website. The change also reduced backend maintenance overhead, since new frontend data needs could be met by adjusting queries rather than building new REST endpoints.

Situation

In Screenchat, a real-time movie chat app I built solo, the chat interface used FlashList backed by a Zustand store to render live, high-frequency message streams across multiple rooms. Users began experiencing chat messages appearing out of order, duplicating, or failing to update in real time — undermining the core “real-time” experience the product promised.

Task

I needed to diagnose why the list wasn't reflecting the true, current state of incoming Socket.IO messages and fix it without degrading scroll performance in long-running chat sessions.

Action

I traced the issue to stale closures — callbacks and render functions inside the FlashList item renderer were capturing outdated references to the Zustand store state from the render at which they were created, rather than the latest state when a new Socket.IO event fired. I:

• Refactored the store subscriptions to pull fresh state via selectors at render time instead of relying on captured closures.
• Fixed duplicate-message issues by adding proper deduplication logic keyed on message IDs before they reached the list.
• Verified fixes using Reactotron to inspect store state changes in real time against what the UI was rendering.

Result

Chat messages now render reliably in the correct order with no duplicates, even under high message throughput across multiple concurrent rooms — restoring the real-time reliability that's central to the product's value proposition, without any regression in list scroll performance.

Situation

MixGenius, my AI cocktail recommendation app with a Laravel/PHP backend and Python AI layer, relies on third-party APIs to power its recommendation engine. As usage grew, uncontrolled API calls from both the website and mobile app risked hitting rate limits, driving up costs, and degrading response times for users.

Task

I needed to protect the third-party API budget and keep the service responsive, without restricting legitimate usage from real users across two different client types — a public website and a mobile app.

Action

I built a caching and throttling layer directly into the PHP API:

• Introduced a caching system so repeated or near-duplicate requests were served from cache instead of triggering fresh third-party calls.
• Implemented throttling scoped by IP address for website traffic, since there's no persistent client identity to key on.
• Implemented separate throttling scoped by unique device/user ID for mobile app traffic, giving more precise per-user control than IP-based limiting alone.
• Designed the two throttling strategies to run independently so each client type got limits appropriate to its traffic pattern.

Result

The system now controls third-party API spend and protects against abuse or runaway usage, while cached responses improve perceived performance for repeat queries. The dual throttling approach meant genuine users on either platform were rarely, if ever, rate-limited, while automated or excessive usage was reliably capped.

Situation

Screenchat's Node.js/MariaDB stack was deployed to a CentOS VPS, but releases were handled manually — pulling code, restarting services, and managing Docker images by hand. This made deployments slow, error-prone, and risky to run frequently, which discouraged shipping small fixes and improvements quickly.

Task

As the sole developer on the product, I needed a repeatable, automated deployment pipeline that could take a code change from commit to live production safely, without requiring manual SSH steps each time.

Action

I built a CI/CD pipeline using GitHub Actions:

• Configured workflows to automatically build Docker images on new commits and merges, ensuring the deployable artifact was always built consistently from source.
• Set up SSH-based deployment steps to securely push and deploy the built images to the CentOS VPS running Screenchat's Node.js/MariaDB backend.
• Structured the pipeline so builds and deployments ran as a single automated flow rather than a manual, multi-step process.

Result

Deployments became fast, consistent, and low-risk, removing manual steps that previously slowed down releases. This let me ship fixes and features more frequently and confidently as a solo developer, reducing the operational overhead of maintaining a production service.

Situation

Screenchat's movie database suffered from incomplete and inconsistent metadata — missing watch-provider data, no reliable way to track when a title was actually added versus just refreshed, and no clean mechanism to answer real-time questions like “what's new on Netflix” inside the chat rooms.

Task

I set out to build a standalone Python microservice with genuine agentic behaviour — not just a scheduled scraper, but a system that could extract, resolve, and reconcile data autonomously, then let the product's LLM layer query and narrate it safely without hallucinating titles or dates.

Action

I designed and built the pipeline using LangGraph to orchestrate a multi-step extraction agent:

• A resolution step that matches scraped entries against TMDB to disambiguate titles before persisting anything.
• A diff-based reconciliation stage, rather than destructive delete-and-reinsert, so I could track true “first added” timestamps separately from “last confirmed,” giving the system an accurate signal for recency.
• A nightly cron-driven refresh cycle so the data — and any “what's new” queries — stayed meaningfully current.
• A strict separation of concerns: the agent and database are the sole source of truth for facts (titles, dates, providers), while the LLM's role is limited to phrasing that data naturally in chat — never inventing or guessing it.

I also wired intent detection into Screenchat's existing socket-based AI-mention handler, so a query like “what's new on Netflix” triggers a direct, cheap database lookup through the service before falling through to general LLM handling, avoiding unnecessary model calls for structured questions.

Result

The microservice closed a persistent data-integrity gap — the database now distinguishes genuinely new titles from routine refreshes, and users can ask natural-language questions about availability and get accurate, non-hallucinated answers grounded in real data. The architecture also gave me a reusable pattern (agent resolves and persists, LLM only narrates) that I've since applied elsewhere in the platform to keep AI features fast and trustworthy.