Software and AI engineer at Greene IS. Founder of YenkoDev. I build automation platforms and applied LLM systems.

github

Luis Daniel Pambid • Peerlist

A creator content platform built for a client of my studio, delivered across mobile, web and backend over 21 months. I ran the delivery: 411 of the 437 issues and 402 of the 403 board items were written by me, work was assigned across the team, and I took a share of it directly.How it ran. A six-lane Kanban flow with client acceptance testing named as its own step before review, weekly grooming, effort estimated in weeks on 261 items, and 71 marked as user-demanded. Priority and user impact were kept as independent judgements and they agreed on only 274 of 403 items, which is the whole reason for keeping them apart. The build decisions went into the tickets before the developers built them: the chat service move, two CDN moves, a backend availability plan, a storage constraint on offline downloads and a tester-gated release channel.The client wrote in Taglish over chat. Turning that into typed, prioritised issues with device details and attachments, and relaying decisions back in the client's own language, was a real part of the job. So was verification: tested item by item against the client's own eight-point list with a video attached, with production gated on simulator testing after merge.One operational save worth recording. A shared client account was lost. The repository, hosting and credentials were migrated to a company-controlled identity with full git history preserved and the old access revoked.Honest limits: board authorship measures who wrote the tickets, not who did the work inside them. Who designed the board cannot be proven from the record, so the claim is running and populating it. The cadence was Kanban with weekly grooming and estimates in weeks, with no sprints and no velocity. The client is not named and the code is not published.

Creator Content Platform, Three Surfaces

A software studio I founded and run in the Philippines, registered with the Bureau of Internal Revenue in June 2024 and trading under the name since December 2023. AI-assisted custom builds and project rescue for small businesses, run seasonally alongside my full-time engineering role.What I do here is the whole of it. One person carries an engagement from the enquiry to the invoice: the discovery conversation that works the business problem rather than taking a spec, the quotation and scope of work, the technical decisions handed to the developers as a design and a set of standards, the Kanban board I author, estimate in weeks, prioritise and move through acceptance, and the invoicing and payment reminders at the other end. I am the only person who speaks to the client, so requirements come in through me and reach the developers as work.About ten developers have been paid across the years, five to eight at a time, spanning software, web, mobile, embedded and AI or machine learning. Hiring, ending an engagement, setting a rate, raising it and refusing a raise are my decisions alone. The workspace is a Discord server I built out into core, project, service and dev teams, with contract and money conversations kept in their own channels away from delivery, a set of channels per project, learning channels, and a reference library so the developers work to a standard.One engagement worth naming: a fixed-price AI build closed end to end in 21 days, from first artefact to a signed follow-on agreement. Model trained, application built, and source, weights and training artefacts handed over under a contract clause requiring source-code transfer on completion.Honest limits: the headcount and the engagement model are my own account rather than a documented record. The delivery process is evidenced in depth on one engagement of the eight recorded, the only one that ran a multi-developer board. Client code from this studio is not published anywhere, so what I can show is the process and the outcomes rather than the source.

YenkoDev, a Philippine Software Studio

Two enterprise Atlassian consolidations delivered at a US managed service provider, a year apart.2025, an acquisition. The acquired company's Jira Cloud instance moved into the parent organisation's 2,000-seat enterprise tenant. 83,722 issues landed in one production cutover window, recorded as SUCCESS and confirmed by the vendor's own post-migration reports rather than by a progress note alone. The runbook was designed and proved across four sandbox rehearsals before production, covering migration plan configuration, project-key remapping, permission, notification and role scheme teardown, and identity remapping with review of every account flagged as needing attention. It was then executed unchanged at cutover. The client called the execution smooth and the delivery on time.2024, a consolidation of two estates into one cloud organisation over 3.5 months as sole delivery engineer, 224.66 of the project's 260.16 hours delivered personally. The Jira half could not use the vendor's supported tool, which proved unusable against the source instance, so the path was engineered by hand: 133,331 issues moved off an unsupported on-premises Jira Server, 126,150 in the larger project across 24 chunks and 7,181 in the smaller one, with Python CSV preprocessing, attachments extracted in bulk and staged in S3 and their URLs rewritten inside the import files. Each of the 24 chunks needed its own field mapping and every one was tracked to closure across three reimport passes for issue links, parent issue ID and example links. The Confluence half moved 25,790 objects across 132 spaces with no partial loss in the vendor's report.Honest limits, and on a migration they matter more than anywhere. Neither of these is called clean, complete, flawless or lossless. The 2025 vendor reports record 2,100 in-scope issues not migrated in one project with no reason given, and 66,393 of 1,683,860 entities not migrated in production against 23 in the final rehearsal, mostly change history, parent links, comments and watchers. 133,331 is a count of issue keys prepared and loaded, not a destination-side reconciliation, so it is written as migrated and never as verified in the destination. Zero reported loss on Confluence measures the vendor's copy operation and not what the estate was like to use afterwards: the same record carries three weeks of post-migration remediation for broken links, duplicate personal spaces, page ownership and permissions, and the two belong in the same sentence. 98 of those 132 spaces are personal spaces, so 132 spaces is not 132 team wikis. Decommissioning of the old instances was still pending at the close of the 2024 engagement. On the 2025 cutover a second engineer was resourced on the export and relink work, so the claim there is led, never sole.

Enterprise Atlassian Cloud Migrations

A recovery job, and then the hardening that followed it. I was handed an unfamiliar production payout system belonging to a client of a US managed service provider. Five days after first seeing it, two stuck batches of patient refunds were moving again.The two batches had been stranded for 21 and 19 days. One had been sent to the bank three times and rejected at load each time, the last time with every state code corrected. The other was uploaded once and never registered at all. The working theory was the state codes. It was wrong. Comparing the rejected files record by record against three files the bank had accepted disproved that theory and isolated four defective records instead: two nine-digit phone numbers, one accented city name and one six-digit ZIP.Corrected values came from the client the same afternoon. Two refunds already paid another way and one deleted on the client side came out of scope. Corrected files for 113 and 171 refunds were validated clean against the batch rows, six source rows were fixed, both files were uploaded and content hash-verified, the batch rows and attachments were updated, and the three old failed orders were cancelled at the bank. Both files reached Processed and the patients received their refunds. 284 refunds in total. The runbook for the whole procedure was written the same day the procedure was first run.Then the part that matters more than the fix. Failures that used to be silent now report themselves: a monitor polls the bank portal every ten minutes and alerts Teams on a failed or stuck file, raising a ticket per failure. And the four defect classes that stranded these refunds are now refused at intake, so the request app rejects short phone numbers, non-ASCII characters and wrong-length ZIP codes before a request can be sent for approval. Nothing about how money moves was changed. Eight days after the monitor went live it caught a refused file first, so the client heard about the failure from us with the fix already made, inside two hours.Honest limits: the cause is an inference, because the bank gave no reason. The corrected files loading and paying is consistent with it and does not prove it. The failure path of one of the fixes has not fired in production yet, so it is verified by read-back and design review rather than by a real failure. No client is named, and no figure beyond record counts appears here. That catch is one incident rather than a track record.

Stranded Patient Refunds Recovery

The internal automation and AI substrate for a US managed service provider. I proposed it, built it and operate it. Every AI and integration system the company runs internally sits on it: the PSA ticket intelligence pipeline, the Teams assistant, the knowledge-base retrieval pipeline, the multi-tenant client tooling and the fleet-management sync.n8n in queue mode across five Docker containers, a main instance, a dedicated worker, Postgres 16, Redis 7 and Traefik, on a hardened Ubuntu VM in Azure. Live since September 2025 and still in daily production. Five production systems on a single 2 vCPU virtual machine.Production architecture was chosen up front rather than retrofitted. Redis-backed queue mode with a separate worker so a long job cannot block the webhook path. Bounded execution retention. A non-root application database user provisioned by an init script. An instance-wide error handler created the same day as the first workflow and later registered in 28 workflows, so a failure anywhere surfaces in one place instead of dying quietly. Daily workflow backups to blob storage. Credentials for every connected system live on the platform rather than scattered through the workflows.The part I am most pleased with is that other people build on it. Three colleagues and a third-party vendor have shipped their own workflows onto it. The instance holds 109 workflows and 1,284 nodes in total; 68 workflows and 981 nodes are mine. Making an internal platform safe enough for someone else to build on is a different job from making it work.Honest limits: 47 workflows are active, which means enabled rather than used. Backups run daily and no restore has been tested, so this does not support a disaster-recovery claim. No load test or utilisation series exists. Running cost is not stated because no cost reading was ever taken.

Self-Hosted Automation Platform on Azure

A fork of a public open-source ConnectWise Manage MCP server, extended so every staff member at a US managed service provider acts in the PSA as themselves from Claude. Forked, extended and live as the organisation connector for the whole company inside three days.The problem with the upstream server is subtle and important. It authenticates the user through Entra ID and then acts on the PSA with one shared credential, so the audit trail says the service did it, not who asked. The fork adds the missing piece: each signed-in member is impersonated as their own PSA member, with one key pair per member persisted in Key Vault, an audit line written per tool call, a cw_whoami tool so the model knows who is signed in, and a licence-class filter so only full-licence members qualify. Time-entry notes are held to the company's work-summary standard by the server rather than by convention.Around that: an Azure Pipelines build to a container registry and a Container App, with an image purge keeping the two newest tags plus latest, a user-assigned identity, two Key Vaults split into read-only configuration and read-write per-member tokens, and Log Analytics with a daily ingestion cap. A search parameter layer and a tool shadowing mechanism sit over every search tool.The part I would show first is the runbook. Thirteen sections, written so a developer who has never seen the project can make a change safely. It carries a file-by-file repo map saying what is ours and what is upstream's and where a merge will conflict, a dated timeline of every change, and the open items. Forking someone else's actively maintained server is a promise to merge it again later, and the map is how that promise gets kept.Honest limits: the server and 51 of its 52 tools are the upstream maintainer's work. The claim here is the impersonation layer, the deployment and the runbook.

ConnectWise MCP Server, Per-Member Auth

An internal AI assistant for the staff of a US managed service provider, delivered inside Microsoft Teams. People ask questions about the company in plain language and the assistant answers from live systems of record rather than from a static knowledge base.It is a three-tier agent, not a chat model with a knowledge base bolted on. A Teams front door terminates the Azure Bot Service channel and speaks the Bot Framework REST API directly rather than through a connector, with client-credentials token acquisition and proactive replies posted back into the originating conversation. A top-level orchestrator holds the persona and the routing rules and decides which of 12 registered tool workflows can answer. Specialist sub-agents sit under it: a knowledge-base agent over a pgvector store, a PSA search agent that knows the platform's conditions query language, and a service-ticket agent that resolves entities before it queries.The details that made it survive production. Four deterministic entity resolvers turn model free text into real record ids and are instructed to ask the user to disambiguate rather than pick, which is what removed hallucinated identifiers. Two-stage retrieval pulls 50 candidates by embedding similarity then reranks to 25, with a relevance floor and mandatory citation of the source page. Conversation memory lives in Postgres keyed by the user's Entra object id, so history is per person rather than per channel, and each person can clear their own and nobody else's. The front door fans each incoming activity into two branches, one posting an instant holding phrase and one calling the agent, so a multi-tool query never looks frozen.One deliberate trade: the orchestrator lists its available tools and has the user pick one before running anything. Conversational fluency given up for predictability, because this agent has live access to production systems. Model resilience is a primary model with a fallback, five retries, and an error branch that returns a readable sentence instead of a stack trace.126 sessions across 269 days with zero failures. That is a reliability record over the period, not an adoption figure, and it is written that way. No client is named and no client data appears here.

Internal Teams AI Assistant

An always-on AI pipeline over a live ConnectWise Manage PSA at a US managed service provider. Every ticket event fires a callback into the automation platform, the pipeline decides whether that event is worth an inference, and only then runs structured extraction over the ticket text, its notes and its schedule entries.What it produces is a ten-field record per ticket: a written summary, the customer's sentiment, and typed lists of impacted software, hardware, IT services, facilities, permissions granted and sensitive data touched. A second pipeline runs three times a day, finds the tickets where the customer sounds unhappy, and pushes a Teams Adaptive Card with an Acknowledge button behind it, so the same ticket is never raised twice.The engineering that matters is the gate. The pipeline recorded 2,097,878 successful executions between November 2025 and September 2026. Change detection against the stored row skips the model entirely when nothing material moved, and the workflow branches early on action and on service board, so a large share of events exit before inference is reached. On a stream this size that gate is the difference between a viable system and an unaffordable one. Batching, retry with backoff, a self-managing Postgres schema and a degradation path that records an empty result rather than failing the row sit behind it.The sentiment loop is the part people touch: 761 notification runs, answered 108 times by the service desk, with acknowledgement checked before the model call so handled tickets cost nothing.Honest limits: the 2.1 million counts callback events the pipeline handled, not AI summaries produced, and the same window carries about 1.2 percent failed executions. Built and operated solo. The client environment is not named and no client data appears here.