Selected Work

The Challenge

The client needed a reliable POS system that could continue billing without an internet connection, automatically sync data once online, manage inventory across multiple outlets, and remain simple enough for staff with little technical experience. For the Chain's point of sale (pos) team specifically, the main issue was technical difficulity & unable to use POS when network disconnects.

The Solution

Developed an offline-first POS system that stores transactions locally during internet outages and syncs them automatically when connectivity is restored. The software also includes inventory management, real-time outlet synchronization, and a centralized admin dashboard for monitoring sales, stock, and business performance. The approach leaned on the Chain's existing data rather than requiring a separate data-collection effort, which kept the timeline realistic.

• •Started with a short discovery phase to map out exactly what exactly is the issue, and what a can be done.
• •Development for them centered on Python, MongoDB, with an early working version ready well before the full feature set was finished.
• •Rolled out to a smaller pilot group within Multi-Location Restaurant Chain first, then expanded for complete usage.
• •Left Multi-Location Restaurant Chain with a working system .

The Challenge

The marketing team relied on manual spot-checks of social mentions, often missing sentiment shifts until they'd already become a bigger issue. There'd been a couple of internal attempts to address it by them already.

The Solution

Built a monitoring pipeline that scores sentiment across mentions in near real time and alerts the team when sentiment shifts sharply.

• •Kicked off with a series of short conversations with their team to understand the workflow the new system would actually need to fit into.
• •The first working version for Consumer Brand came together quickly using Python, which left more time for testing edge cases in their data.
• •Ran the first version alongside Consumer Brand's existing process for a few weeks rather than replacing it outright, to build confidence before full cutover.
• •Set up basic monitoring so Consumer Brand's team would know quickly if performance started drifting, rather than finding out from a downstream complaint.

The Challenge

A small volunteer moderation team was overwhelmed by the volume of flagged posts and comments as the community grew.

The Solution

Built a toxicity classification model that auto-actions clear-cut cases and routes ambiguous ones to human moderators. Keeping the interface simple enough for Community Platform's non-technical staff to use directly was as much a design constraint as the underlying model itself.

• •Began by auditing what Community Platform already had in place, thier platform had video , image & text based data that needed moderation, text moderation was kind of easy compared to others
• •Built and validated an initial version for Community Platform using Python, testing it against real historical data before anything went near production.
• •Once the core system was working, the focus shifted to integration — making sure it fit into how Community Platform's team already worked, not the other way around.
• •Closed out the engagement with Community Platform with a handover session covering how the system worked and what to watch for as usage scaled.

The Challenge

Stock counts were done manually with clipboards and barcode scanners that struggled with damaged or poorly-placed labels.

The Solution

Built a mobile app that uses OCR ( Optical Character Recognition) and barcode detection that lets staff scan entire shelves quickly, cross-checking against expected inventory. The build prioritized something Warehouse Operator's team could actually run and maintain day to day.

• •Spent the first stretch getting access to Warehouse Operator's data and systems , and worth doing properly upfront.
• •Built Warehouse Operator's core system in stages, validating each piece against real data .
• •Integration took longer than the model itself for Warehouse Operator, mostly around getting the output into a format their existing tools could use.
• •Handed off to Warehouse Operator with documentation and a short walkthrough so their internal team could maintain and use it without needing ongoing support.

The Challenge

A large share of inbound inquiries came in after business hours and went unanswered until the next morning, by which many leads were lost . It was a problem that looked small from the outside, but was quietly costing Real Estate Brokerage real time every single day.

The Solution

Built a chatbot grounded in current listing data that answers common questions and qualifies leads immediately, handing off to an agent for anything it can't answer. The build prioritized something Real Estate Brokerage's team could actually run and maintain day to day, not just a one-off proof of concept.

• •Spent the first stretch getting access to Real Estate Brokerage's data and systems — usually the slowest part of an engagement like this, and worth doing properly upfront.
• •Built Real Estate Brokerage's core system in stages, validating each piece against real data before moving on to the next rather than building the whole thing end-to-end blind.
• •Integration took longer than the model itself for Real Estate Brokerage, mostly around getting the output into a format their existing tools could use.
• •Working with the Real Estate Brokerage firm to extend it so system works without needing ongoing support. To give the site Whats App automation feautre is under discussion

The Challenge

The platform's existing plagiarism checker only matched against a small internal database and missed content copied from the wider web or generated by AI tools. For Online Learning Platform's education team specifically.

The Solution

Built a more thorough detection pipeline combining web-similarity search with stylistic pattern analysis, flagging submissions for instructor review. The approach leaned on Online Learning Platform's existing data rather than requiring a separate data-collection effort, which kept the timeline realistic.

• •Started with a short discovery phase to map out exactly what Online Learning Platform needed, and what a realistic could be done within 7 weeks.
• •Development for Online Learning Platform centered on Python, HuggingFace, with an early working version ready well before the full feature set was finished.
• •Rolled out to a smaller pilot group within Online Learning Platform first, then expanded once the early numbers held up under real usage ( The beta phase).
• •Completed the work with Online Learning Platform with a working system.

The Challenge

Strategists were manually researching keywords, competitor content, and structure for every brief, which didn't scale as client volume grew ( even with traditional LLM chatbots ). For Content Marketing Agency's marketing team specifically, it wasn't a new problem — it had just never been anyone's clear responsibility to fix, so it kept getting worked around instead of solved.

The Solution

Built a tool that pulls competitor and keyword data automatically and drafts a structured brief for a strategist to review and refine ( via data scaping). The approach leaned on Content Marketing Agency's existing data rather than requiring a separate data-collection effort, which kept the timeline realistic.

• •Started with a short discovery phase to map out exactly where Content Marketing Agency was losing time, and what a realistic win would look like within 5 weeks ( result took around 3 months to show clearly).
• •Development for Content Marketing Agency centered on Python, LangChain, with an early working version ready well before the full feature set was finished.
• •Rolled out to a smaller pilot group within Content Marketing Agency first, then expanded once the early numbers held up under real usage.
• •Left Content Marketing Agency with a working system plus a short list of natural next steps, in case they wanted to extend it later.

The Challenge

Shipment ETAs were calculated from a flat distance-and-speed formula that ignored real-world variables like traffic and weather delays.

The Solution

Built a prediction model incorporating route history, weather, and customs data to generate dynamic, continuously-updating ETAs. Rather than a full platform rebuild, the fix was scoped tightly around Freight & Logistics's actual bottleneck, which kept both timeline and cost down.

• •Kicked off with a series of short conversations with the Freight & Logistics team to understand the workflow the new system would actually need to fit into.
• •The first working version for Freight & Logistics came together quickly using Python, which left more time for testing edge cases in their data.
• •Ran the first version alongside Freight & Logistics's existing process for a few weeks rather than replacing it outright, to build confidence before full cutover.
• •Set up basic monitoring so Freight & Logistics's team would know quickly if performance started drifting, rather than finding out from a downstream complaint.