Solution Architect & AI/ML Engineer

Iranga Basnayake

Twenty years designing and shipping the systems a global apparel manufacturer runs on — on-premises AI, process automation, and enterprise platforms.

Kandy, Sri Lanka · UTC+5:30

Automation, mobile, and on-premises AI — delivered end to end for one of the world's largest apparel manufacturers.

My current focus is a fully on-premises LLM assistant that protects company IP without depending on third-party cloud AI. I also own infrastructure strategy and translate plant-floor requirements into systems that scale.

Based
Kandy, Sri Lanka · UTC+5:30 · remote-first
Focus
On-premises AI · process automation · enterprise systems
Experience
20+ years across IT, infrastructure and software
Education
MSc Computer Science, Cardiff Metropolitan University

Full background

01 Selected work
01

On-Premises LLM Assistant

2025 — present · Live in production

A fully self-hosted AI assistant running inside a global apparel manufacturer. Staff get a capable assistant; company data never reaches a third-party cloud model.

Zero company data leaves the corporate perimeter.

OllamaOpen WebUI Llama / MistralLinux DockerGPU / NPU
internal · ai-assistant On-prem
Production lead

Summarise yesterday's QC failures by line and propose causes.

Assistant · Llama 3.1

Across three lines, failures cluster on Line 2 (Yarn module). Leading causes: humidity drift and spool load variance.

Production lead

Group by shift.

Assistant

Night shift carries the majority.

No data leaves the perimeter No cloud calls
Representative interface · illustrative content
  1. Deployed on Ollama with an Open WebUI front-end, running open-source models on dedicated on-premises hardware.
  2. Led hardware sizing, model selection, and performance tuning within tight GPU and NPU constraints.
  3. Defined the roadmap for GPU upgrades and expansion to further internal use cases.
  4. Built to satisfy internal IP and confidentiality policy end to end.
02

MWash

2026 · Live in production

Chemical inventory and recipe management for industrial garment-washing plants. Spreadsheets and printed recipe cards replaced by a live register, automatically scaled recipes, batch tracking, and low-stock alerts.

Built and shipped to production in a single quarter.

React 18TypeScript Django 5DRF PostgreSQL 16Redis
mwash · dashboard Live
Chemical register TodayWeekMonth
Chemicals184in register
Recipes62versioned
Low stock3alerts
06:00Batches logged18:00
Representative interface · illustrative content
  1. Chemical register with safety data, supplier lots, and unit-of-measure normalisation across deliveries.
  2. Recipe creation, versioning, and automatic scaling to any batch weight or garment count.
  3. Batch tracking with consumption logs, low-stock alerts, and printable shop-floor tickets.
  4. Role-based access for admins, batch operators, and report users, with a full audit trail.
03

ILAB — Matrix Digital Lab

2025 — present · In production

A plant-wide textile quality-control system. Clipboard checklists replaced by a digital lab where Yarn, Accessory, Inspection, and Essentials teams record results — routed through a permission-based approvals inbox to the right approver, every time.

Quality control digitised across the plant.

DjangoPython PostgreSQLBootstrap Role-based ACL
ilab · approvals Routed by ACL
System approvals inbox Approver-scoped
  • Yarn tension — Line 2YRN-1184Approve
  • Label colourfastnessLBL-0472Pending
  • Button pull testBTN-0231Pending
  • Carton drop testCTN-0918Queued
  • Poly bag thicknessPLY-0655Queued
Yarn · Accessory · Inspection · Essentials
Representative interface · illustrative content
  1. Modules for Yarn, Accessory, Inspection, and Essentials — each with structured test forms and pass/fail logic.
  2. Approvals inbox routes Yarn, Label, Button, Carton, Poly Bag, and Accessory reports to the correct approver.
  3. Permission-based access control so testers, leads, and approvers see only what they should.
  4. Production reports and KPIs feeding plant management dashboards.
02 How I work

Architecture first, then software that survives day two.

Most plant-floor systems fail after go-live, not before it. I design for the years after the launch — ownership, permissions, reporting, and the people who have to run it.

  1. 01

    Discovery on the floor

    Requirements gathered where the work happens, with the operators and leads who will use the system daily — not from a specification document alone.

  2. 02

    Architecture & data design

    Data model, integration points, and permission structure decided before a line of feature code. This is where most of the cost is either saved or created.

  3. 03

    Build and roll out

    Shipped end to end — backend, interface, deployment, and the training that decides whether people actually adopt it.

  4. 04

    Day-two operation

    Reporting, audit trails, access reviews, and iteration. The system stays mine after launch, which is why it keeps working.

03 Contact

Get in touch.

For project enquiries, consulting, or a conversation about a role — email is the fastest route. I reply within a day.

Based in
Kandy, Sri Lanka · UTC+5:30