Forward deployed engineer at Greene IS. I solve complex business problems from inside the business.

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.

Creator Content Platform, Three Surfaces

A software studio I founded and ran in the Philippines, registered with the Bureau of Internal Revenue in June 2024 and trading under the name from December 2023 until September 2026. AI-assisted custom builds and project rescue for small businesses. It ran seasonally alongside my full-time engineering role.What I did here was the whole of it. One person carried an engagement from the enquiry to the invoice: the discovery conversation that worked 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 authored, estimated in weeks, prioritised and moved through acceptance, and the invoicing and payment reminders at the other end. I was the only person who spoke to the client, so requirements came in through me and reached the developers as work.About ten developers were 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 were my decisions alone. The workspace was 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 worked 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.

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.The vendor reports also record what did not move. On the 2025 cutover, 66,393 of 1,683,860 entities did not migrate in production against 23 in the final rehearsal, mostly change history, parent links, comments and watchers, and 2,100 in-scope issues in one project did not migrate. The Confluence copy reported no loss, and three weeks of remediation followed for broken links, duplicate personal spaces, page ownership and permissions. 98 of the 132 spaces are personal spaces. On the 2025 cutover a second engineer worked on the export and relink work.

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.

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.Of the 109 workflows, 47 are active.

Self-Hosted Automation Platform on Azure

A fork of a public open-source ConnectWise Manage MCP server, extended so each signed-in member at a US managed service provider acted in the PSA as themselves from Claude. Forked, extended and deployed as the Claude.ai organisation connector 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.The server and 51 of its 52 tools are the upstream maintainer's work. Mine are 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 in production.

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.The 2.1 million counts callback events the pipeline handled, not AI summaries, and about 1.2 percent of executions in the same window failed. Built and operated solo.