My freelance work spans AI agents, manufacturing analytics, workflow automation and custom CRMs. I contribute across solution design, integration and implementation.
Confidential client work. Related public examples are labelled beside each story.
01 · Task-focused AI agents
AI that can work through a task.
Built agents for defined business tasks, connecting paid model services with the tools used in the workflow.
Task design · Model APIs · Tool integration
My contribution & design decisions
I worked on the solution design and implementation: translating the task into an AI workflow and connecting the services around it. Client AI delivery used paid OpenAI and Google Gemini APIs.
The questions I work through
What does the model need to decide?
Which tools can it use?
Where should a person check the result?
Independent implementation: inspect tool calls, source records and a generated investigation draft using a local model.
Built workflow automation for smaller businesses, connecting tools around their day-to-day processes and repetitive manual work.
Process mapping · APIs · Workflow implementation
My contribution & design decisions
I helped turn an operating process into a connected software workflow, working through the business requirement, the integrations and how the result should be used.
The questions I work through
What starts the process, and what finishes it?
What information needs to move between tools?
What should happen when a step cannot complete?
A design walkthrough of how I break down a task, connect the steps and check the awkward cases.
Built focused CRM systems for organizations that wanted software shaped around their work, with reliability and everyday usability guiding the scope.
Requirements · Application logic · User experience
My contribution & design decisions
I worked on translating an organization’s requirements into a focused application, connecting the interface and workflow around what the team needed to do.
The questions I work through
Which information does each person need?
Who owns the next step or decision?
What needs to stay clear when work changes hands?
BricDesk is my separate product in development. Its inventory, ownership and approval flow demonstrates related application-design skills.
In the portfolio version, choose a property, adjust its roof and panel options, then explore the setup in 3D. Compare how it looks and how power moves through it during the day and at night.
What becomes clearer
A visible layout and a configuration summary to review together, so the choices are easier to discuss before moving further.
Client story, build details and checks
Original client work
Built an app for a solar panel company that let users explore a setup for their house: dimensions, square footage, electricity needs, panel models, visual layout, and estimated cost.
My contribution
Turned a company-specific configuration problem into an application flow, connecting property inputs to choices a customer could understand.
Logic you can explore
The portfolio rebuild connects roof layout, panel fit, inverter casing, protection enclosure, meter, and grid routing in distinct interactive house, office and apartment models. Inspect components, change day/night power scenarios, and export a configuration summary.
Implemented demo stack
Demo: Next.js · React · TypeScript · Three.js
Rebuild checks & exports
Tested roof fit, orientation, empty arrays, dimension bounds, equipment placement, route continuity, and energy balance. The scene supports orbit, zoom, roof plan, property presets, equipment inspection and reviewable JSON summaries.
Client work · Manufacturing
Make unusual machine readings easier to investigate.
I contributed to work that used machine readings to flag unusual behaviour for manufacturers of plastic bottle caps and automobile parts.
In the portfolio version, explore a machine’s readings, replay a recorded run and compare it with a reference run. Save observations, possible explanations and the checks you want someone to review.
What becomes clearer
A case that keeps the measurements and open questions together, giving a reviewer a clearer starting point for the next check.
Client story, build details and checks
Original client work
Worked on an AI system for a plastic bottle-cap manufacturer, using industrial sensor readings to identify manufacturing anomalies. Contributed to sensor calibration and detection, with similar work for automobile-parts manufacturing in Pune.
My contribution
Brought the manufacturing problem into a sensor-driven workflow, with attention to useful signals and unusual operating behaviour.
Logic you can explore
MachineScope rebuilds the investigation flow around measured hydraulic test-rig cycles. Explore a functional sensor map, replay pressure, flow, power, temperature and vibration, compare phase-aligned references, and capture observations, possible mechanisms and requested checks in a case review.
Reproducible raw-data extraction, a held-out healthy cycle, matched component conditions, aligned measurements and interpretation boundaries are covered by tests. The case export retains all five channels, source rows, reference context and review notes.
Client AI delivery and portfolio scope
Delivered AI automation and business-tool integrations using paid OpenAI and Google Gemini APIs.
Client AI delivery used paid model services. The public portfolio demonstration uses local Qwen through LangChain/Ollama to make the workflow inspectable. Clients remain anonymous. The interactive demos are fresh portfolio rebuilds using illustrative inputs and attributed public measurements; their code and stack describe these implementations, rather than the unavailable original client source.
01
Find the useful idea
Understand the people, the decisions, and the constraints before deciding what the software should do.
02
Connect the pieces
Translate requirements into product flows, interface behaviour, and integrations that support the business process.
03
Make it explainable
Work through the implementation and tradeoffs, keeping outputs understandable and actions reviewable.
The role I’m looking for
AI solutions and implementation work where I can contribute to problem discovery, prototyping, integrations and evaluation. I enjoy making a useful idea concrete, working through technical choices, and improving it with feedback.
A shared workspace for property developers to see available homes, keep track of who is handling each buyer and review reservation requests.
Available homesWho helps the buyerReservation requestApprovalProject overview
The problem
Property availability and sales decisions get spread across spreadsheets, messages and calls. A handover can lose who the buyer is, which home they want and who needs to decide next.
How someone uses it
A sales team checks available homes, records the person handling a buyer and requests a reservation. The right reviewer can then see the buyer, home and request together before approving it.
What becomes clearer
Who owns the next step, where a reservation stands and which decisions still need attention. The developer can follow the same journey across the team.
My role
I am designing and building the product, from understanding the workflow to connecting its screens and refining how people use it.
Build details and current scope
Product workflow
An operating desk for real estate builders and channel partners: inventory, lead ownership, holds, approvals and founder visibility in one accountable flow.
Inventory truth → Lead / CP ownership → Hold → Approval → Founder visibility.
Every handoff needs to keep the buyer, unit, owner and decision attached.
My contribution
Independent product development across workflow discovery, interface design, application development, access boundaries and release iteration.
Implementation
Flutter application development with a Supabase-backed data layer and a responsive public website. The workflow connects requests and decisions across roles rather than presenting disconnected screens.
Technical decisions
Explicit builder and project context, role-scoped actions and attributable decisions. Reliability and a coherent workflow guide the feature scope.
What I can demonstrate
The inventory-to-hold-to-approval journey, how ownership changes the next available action and the product tradeoffs behind keeping those steps connected.
Current delivery scope
Product in development, with continuing workflow and integration iteration. The public site provides product context; customer adoption and commercial outcomes are not claimed here.
When a machine looks unusual, make the next check clear.
An AI assistant that brings machine readings, comparisons and reference material into one reviewable brief, so a person can decide what needs checking next.
Built independently with public machine data and a local AI model.
01Ask about a run
02Gather readings
03Compare runs
04Draft a brief
05Review the next check
The problem
An unusual machine run raises several questions. What changed in the readings? How does it compare with another run? What do the references say, and what still needs checking?
How someone uses it
Ask about a recorded run. The assistant gathers relevant readings and comparisons, then drafts a brief with sources. A reviewer can inspect the evidence, question the explanation and choose the next check.
What becomes clearer
The observations, the evidence behind them and the questions still open. The brief gives the reviewer a starting point for investigation.
My implementation
Connected measured readings, a trained classifier and model-selected evidence tools. The interface keeps the source records, generated explanation and reviewer’s open checks together.
My implementation · From input to inspectable output
What the build covers.
Measured sensor processing, a fitted classifier and a tool-using AI investigation with reviewable output.
01
Structure the readings
Retain sensor units and sampling rates, align operating phases and compare pressure, flow, power, temperature and vibration.
02
Connect models and tools
Fit a sensor-feature classifier and let the local assistant request four bounded evidence tools with validated arguments.
03
Preserve the investigation
Export source-linked drafts, tool receipts, observations and open checks. Keep failed drafts and model mistakes available for review.
This is an independent implementation on public hydraulic-rig data. Generated explanations still need review; the system does not control equipment.
When a cycle looks unusual, someone has to assemble the readings, compare operating phases, consult relevant references and explain what still needs checking. This implementation keeps those steps and their source receipts together.
Generative & agentic AI
The operations assistant uses a local language model to choose evidence tools, compare measured cycles and draft a cited investigation brief for human review. Qwen runs locally through Ollama and LangChain. It chooses from four bounded tools: recorded cycles, phase comparison, reference search and fitted classifier inference. The execution record exposes arguments, receipts and citations.
Incident question → Model selects tools → Measured evidence → Cited draft → Human review.
A separate L2 logistic classifier learns from 1,653 measured UCI cycles. Its 552-cycle holdout records 231 true positives, 306 true negatives and 15 missed leakage labels. The study exposes features, coefficients and every held-out prediction.
Python · NumPy · standardized sensor features · reproducible training · TypeScript inference
Quality checks
Recorded model runs expose tool choices, source receipts, citation checks and failures. Some drafts contain factual mistakes even when citation identifiers are valid; those failures stay visible rather than being presented as reliable diagnoses.
Data sources, review and limits
Measured data. Visible limits.
The dataset is a public hydraulic test rig, separate from confidential client telemetry. The classifier uses a same-rig random holdout; adjacent cycles may be correlated. Model scores do not prove a physical cause. Generated drafts require review, and the tools cannot control equipment.
This is a new independent implementation. The paid OpenAI and Google Gemini services used in my client AI work are described separately in the client stories.
Three tools for everyday decisions: choosing a supplier, planning a shift and handing over a website issue. Each takes information a person can supply and turns it into something they can review.
These are independent builds, separate from my past client work.
Compare supplier offers
SupplyCompare
The cheapest item price can hide a larger minimum order, extra freight or a missing delivery date. A buyer needs to see the whole offer before choosing.
List the partsAdd supplier repliesCheck missing termsCompare costsReview the brief
How someone uses it
Enter the parts you need and the replies you received. Compare quantities, prices and delivery terms, then review the questions still waiting for an answer.
What becomes clearer
A comparison you can explain: what each offer includes, what it could cost and which terms still need confirmation.
Workflow, implementation and evidence limits
The workflow requirement
Prepare an RFQ. Compare the replies you received.
A purchasing operator or small equipment builder with a parts requirement and written supplier replies.
A low unit price is not enough to compare an offer. Quantity, confirmed specification, minimum order, freight and delivery have to refer to the same requirement.
What goes in and comes out
Your quantities and quote references. Prices, lead times and commercial terms come from the replies you enter.
A readable parts request, unanswered supplier questions and a reviewed comparison brief.
How I implemented it
Missing commercial values stay unknown. Numerical requirements and minimum orders run before cost/delivery preferences. The current request retains part and quote references; each calculation can be traced back to entered terms.
Catalogue specifications identify reference parts. They do not provide supplier prices, available stock, client identity or approval to build an electrical assembly.
These are new implementations around documented workflows and potential freelance deliverables. Workflow references support the design; they do not establish paid adoption or outcomes for this implementation.
Several orders can need the same machine. Before promising a finish time, a workshop needs to account for setup, earlier jobs and machine downtime.
Add ordersSet available machinesPlan the workReview delaysRead the shift brief
How someone uses it
Add orders, the steps each one needs and the machines available. Try two planning rules and review the work that fits, gets blocked or misses a deadline.
What becomes clearer
A shift plan with its assumptions visible, so a coordinator can see where a commitment needs another check.
Workflow, implementation and evidence limits
The workflow requirement
Check whether supplied orders fit a shift.
A workshop coordinator with order routes, measured or estimated processing times and known machine downtime.
Orders compete for the same machines. A route that looks quick on its own may miss a deadline after setup, previous operations and unavailable time are included.
What goes in and comes out
Your routing rows, machine groups, quantities, release/deadline times, setup/cycle times and their references.
A readable plan showing allocations, blocked routes, deadline exceptions and the assumptions behind each timing.
How I implemented it
Operations follow their route and release time, using a matching available machine. Setup plus processing fits one uninterrupted slot. Two dispatch rules expose tradeoffs; unavailable and incomplete work stays explicit.
A timing estimate needs a shop source. The worked example is invented; its rule comparison is not measured business improvement. Materials, staffing and sequence-dependent changeovers are not included.
These are new implementations around documented workflows and potential freelance deliverables. Workflow references support the design; they do not establish paid adoption or outcomes for this implementation.
Dispatch decisions and schedule revision after changing shop conditions are established scheduling concerns. This is a methods reference, not a current market survey.
When a website needs attention, the next person needs more than a link to a help article. They need the question, the relevant guidance and the checks still left to do.
Ask a support questionFind guidanceSelect passagesRecord checksReview the handover
How someone uses it
Enter a support question, find relevant passages in the documentation and select the ones that help. Add your review notes before exporting a handover.
What becomes clearer
A readable brief that keeps the source, its version and the open checks together.
Workflow, implementation and evidence limits
The workflow requirement
Prepare a cited brief for a website support question.
A freelancer maintaining a Next.js website who needs to explain a deployment issue or hand a question to another developer.
Finding a relevant sentence is not the same as resolving a support issue. The installed version, source date, hosting setup and checks on the actual deployment all matter.
What goes in and comes out
A real technical question, the bundled official Next.js 16.2.1 documentation, or your locally imported source text.
A readable handover with the question, exact selected passages, document version, review notes and open checks.
How I implemented it
BM25 retrieves exact source paragraphs from current active versions. Citations retain the source identity; missing support asks for a source. Changes to the question, library or notes require a fresh human review.
Retrieved documentation supports a check; it does not prove a diagnosis in an unseen deployment. No imaginary shop, customer policy or client ticket is needed.
These are new implementations around documented workflows and potential freelance deliverables. Workflow references support the design; they do not establish paid adoption or outcomes for this implementation.
Content maintenance includes reviewing overlapping or conflicting information. This reference does not imply that the portfolio uses Intercom or its AI.
A compact meeting-to-action workflow with reviewable action drafts: explicit action parsing, source attribution, duplicate and deadline-conflict checks, and approval transitions into a local task list.
A small lexical handbook retrieval experiment with exact excerpts, source attribution and a no-match state. EvidenceDesk expands this foundation into versioned collections, document intake, policy conflict handling and case review.
An earlier natural-language data exploration workflow concept for translating natural-language questions into structured data exploration and readable results. The current portfolio does not include a runnable QueryWhiz implementation.
Finance Copilot · Organise financial information
An earlier decision-support concept for organising fragmented financial data into reviewable summaries and trend views. No forecast accuracy, trading result, or live analysis service is claimed.
The detailed case studies above are the current showcase. These earlier experiments provide background and are separate from client deliveries.
