From JIRA to pipeline,without the chaos.
Salesforce engineer — B2B Commerce, Sales, Experience, Health, and public-sector programs. I've built customized Experience Cloud for administration and a public portal at voter scale (~12M), and I live in integrations, Platform Events, and delivery automation from JIRA to pipeline.
Not just config.
Delivery you can trace.
I work where Salesforce meets the rest of the stack — JIRA, Git, CI/CD, and the documents the business actually signs. A status in JIRA is only useful if it starts a machine you can trust: something that creates the work, opens a review, and hands off to a pipeline that enforces what "done" means.
The other side of my work is paper that has to be right. I built a PDF Engine that takes fillable PDFs, applies data from the systems you already use, and lets the people who know the form own the mapping — not engineering for every new template.
This site is a thin slice of that same philosophy: small services, clear contracts, and a UI that doesn't pretend to be more than the product it represents.
Domains
Triggers with intent
JIRA should kick off real work — not another dashboard nobody watches. I connect signals to automated paths humans still approve.
Pipeline owns repeatability
Code review, static checks, unit tests, test classes — the boring stuff belongs in CI once you’ve drawn the boundary clearly.
Documents as products
PDFs aren’t one-offs when mappings live in config. Users define how fields map to data — templates stop being bespoke scripts.
Agents & document engines
Implementing E2E flows from JIRA Dev Ready through reviewed commits and CI/CD — plus a PDF Engine with designer-controlled mappings.
Pipeline-first mindset
Shifted left on quality: automated unit tests, Apex test classes, and review gates as non-negotiable parts of delivery.
Salesforce at depth
Lived in Apex, integrations, and release hygiene — not just declarative builds.
Foundations
Cut teeth on real business problems: messy data, deadlines, and stakeholders who care about outcomes — not buzzwords.
Work that explains itself.
Delivery automation, document engines, voter-scale Experience Cloud, and integration architecture — including Platform Events and patterns that stay coherent as load grows.
JIRA Dev Ready → E2E delivery agent
When a ticket hits Dev Ready, an agent drives implementation, opens a commit for human review, and hands off to CI/CD for the rest.
"Dev Ready" often stops at a green checkbox — someone still has to branch, implement, and babysit quality by hand. Manual handoffs dilute traceability and slow everything before tests even run.
Use JIRA as the canonical trigger. When Dev Ready fires, an end-to-end agent picks up the spec, generates or updates the Salesforce-side work, pushes a commit, and stops at a human gate — developers review intent and risk; automation carries the repetitive verification.
Implemented an E2E agent wired to JIRA Dev Ready: it kicks off development work, pushes commits for developer review, then the pipeline runs code review rules, unit tests, Apex test classes, and whatever quality gates you already trust — same path every time, auditable from ticket to merge.
Signals
Scope note
Cloud names (Commerce, Sales, Experience, Health) reflect where the work lands — the stories above are written to be reviewable by engineers and hiring managers, not as marketing fluff.
How I build systems.
How I connect planning tools, Salesforce work, git, and CI — and how I treat documents as mapped data, not one-off scripts.
Trigger, then hand off to the machine
A JIRA Dev Ready signal should start a closed loop: agent work, commit for review, then pipeline — not a Slack thread. The human reviews intent; automation enforces the bar.
# Delivery spine (conceptual)
JIRA_DEV_READY
-> e2e_agent.build()
-> git.push(branch, commit)
-> pr.await_review(developer)
-> ci.run(tests, apex_tests, static_analysis)Separate concerns ruthlessly
Routers route. Services handle logic. Models define data. When everything has one job, debugging takes minutes instead of hours.
app/
routers/ # HTTP layer only
services/ # Business logic
models/ # Data shapes
config.py # SettingsMake the dev experience a feature
One command to run everything. Clear error messages. Hot reload. The dev loop should be fast enough that you don't lose the thread of what you were building.
# Start everything with one command
docker compose up
# Or individually:
cd backend && uvicorn app.main:app --reload
cd frontend && npm run devObservable from day one
Structured logs, health endpoints, clear status signals. You can't fix what you can't see. I build in observability before it becomes urgent.
@router.get("/health")
async def health_check():
return {
"status": "healthy",
"version": settings.APP_VERSION,
"uptime": get_uptime()
}Delivery
Dev Ready → review → pipeline
At runtime scale, integrations lean on Platform Events and API boundaries so systems decouple — see Work → Scale & events for that thread.
This site
How this portfolio is structured
Client
Next.js
API
FastAPI
Chat Service
Node.js · WIP
Data Store
PostgreSQL
Say hello
if the work matches.
I'm strongest where Salesforce meets scale — Experience Cloud for millions of users, integrations that don't flake under load, and delivery patterns that survive audits and elections alike.
- Custom Experience Cloud — separate administration and public-facing portals built for real civic scale (~12M voters).
- Integration-heavy delivery: APIs, enterprise patterns, and room to grow without painting yourself into a corner.
- Scalability and operations in mind from day one — not a prototype dressed as production.
Domain expertise
At a glance
~12M
Voter-scale audience on a customized Experience Cloud program — admin tools and public portal, one platform, integration-first.
Integrations · scalability · Platform Events
Commerce · Sales · Experience · Health · Public Sector