Mohammed J. Amer II

Forward Deployed Engineer · Technical Lead & Architect · Applied AI

New Jersey · NYC metro · open to hybrid · mjamer.com · linkedin.com/in/mohammedjamilamer · github.com/mjamilamer

Forward Deployed Engineer II New Jersey · NYC metro

I go where the
process is broken.

I embed with enterprise customers, sit with the people actually doing the work, find what's really failing, then ship the system that fixes it — and stay the person they call once it's live.

RoleArchitect, engineer, and domain SME
OwnershipDiscovery through post-production
EscalationCross-team point of contact
DomainsTelecom · Energy · Infrastructure
Core stackApex · Python · TypeScript
EducationM.Eng, Computer Science & Cybersecurity
Or press P
Portrait of Mohammed J. Amer II
Mohammed J. Amer II Sitetracker
Approach

Most broken processes aren't a technology problem first.

01 / LISTEN

Ask before building

The stated requirement is rarely the real one. I spend the first stretch with the operators — watching the workaround, the spreadsheet, the thing everyone stopped mentioning because it's just how it's done.

02 / NARROW

Simplest version first

When a stakeholder wants everything at once, I'll say so. I'd rather ship something small that gets used on Monday than something complete that sits unopened for a quarter.

03 / OWN

It doesn’t end at release

Architecture, code, release — then production support, the edge case nobody predicted, and the question three months later. Being the one who knows the system end to end is what makes the next build faster.

Selected work

Three problems that started as failures.

The process that wouldn't run

A large fiber-infrastructure customer needed to catch double-claimed footage in engineering design data. Each design line claims a stretch of a construction route — feet 100 to 250, say. When two lines claim the same stretch, that footage gets counted twice, and every cost and quantity rollup downstream is wrong. The check existed only as a Power BI process that had stopped completing, so it fell back to people reconciling by hand, four to eight hours at a time, every import.

Before

Failing report. Manual reconciliation. No reliable path to a clean dataset.

After

Native pipeline, validated in minutes, running inside platform limits on every import.

I rebuilt it as a native pipeline: indexed lookups instead of full-table scans, and a chunker that reads the remaining query budget and sizes itself to fit inside it. When a stretch of route comes back dense enough to threaten the row cap, it halves its own chunk width and picks up from the last row it saw. A separate guard watches heap against a soft ceiling set below the platform's hard limit. When that trips, the affected chunk fails with a message telling the operator what to narrow — instead of taking the whole job down at the hard limit.

Four batch phases folded into one configurable job, and tuning moved into metadata, so admins change thresholds and modes without a deployment.

100,000+Rows per import
4–8 hrs → minPer-job cycle time
4 → 1Batch phases consolidated
ZeroFailed runs at scale

Two terabytes of spreadsheet

An entire contractor payment operation lived in Excel — engineering drawings, GIS data, and field work logs, cross-checked by hand before anyone could be paid. Roughly two terabytes of it. Every error was a payment error, and every audit was an archaeology project.

Before

Hand reconciliation across three data sources. Errors surfaced downstream, in billing.

After

Completed work validated against engineered specs, posted to the ERP with a full audit trail.

I architected the platform that replaced it and led the two-engineer core build: ingest the engineering records alongside contractor-submitted logs, validate the work actually done against what was specified, and post reconciled records straight through to finance. The audit trail stopped being something reconstructed after the fact.

~2 TBSpreadsheet workflow retired
End-to-endField work → ERP posting
FullAudit traceability

Everyone used AI. Nobody the same way.

Across the engineering org, AI assistance had gone from novelty to daily habit without anyone agreeing on how. Output quality tracked whoever happened to write the prompt. The gap wasn't enthusiasm — it was that the models had no reliable access to how we actually build.

Before

Ad-hoc prompting. Inconsistent output. Conventions living in people's heads.

After

Shared MCP server and agent rule set — codebase conventions available to the tools themselves.

I built an internal Model Context Protocol server and an agent rule set encoding our conventions. Turning that into something the whole org actually used was a team effort — engineers across teams stress-tested the rules, pushed back on what didn't hold up in real work, and shaped what the tooling should enforce. The interesting part was never the wiring. It was the collective judgment about what models should not be trusted with, and where a human review gate genuinely earns its cost.

40%Less development time, org-wide
25%Less rework, org-wide
TeamShared build and rollout
Experience

The roles behind the results.

Dec 2023 — Present New Jersey · NYC

Sitetracker

  1. Forward Deployed Engineer IIAug 2025 — Present
  2. Forward Deployed Engineer IDec 2023 — Aug 2025

Sole technical architect and primary engineering point of contact for two enterprise fiber-infrastructure implementations — discovery through production support. Cross-team escalation point; sets technical direction and mentors through design and code review.

Sole technical architect and primary engineering point of contact for two enterprise fiber-infrastructure implementations, owning delivery from discovery through production support. The validation domain I own runs about 12,000 lines of production Apex, carried by roughly 11,500 lines of tests. Cross-team subject-matter expert and escalation point: running standups, mentoring engineers through design and code review, and setting technical direction on major projects.

ApexLWCFlowsERP integrationCI/CD
  • Rebuilt a failing Power BI validation process as a native Salesforce pipeline processing 100,000+ rows per import — each job dropped from 4–8 hours of manual reconciliation to minutes.
  • Engineered it to stay inside platform limits: indexed lookups, a chunker that sizes itself to the remaining query budget and halves its width on dense data, and a fail-soft heap guard — zero failed runs at scale.
  • Consolidated four batch phases into one configurable, metadata-driven job, moving tuning out of code so admins change thresholds and modes without a deployment.
  • Architected an automated invoicing platform replacing a ~2 TB Excel workflow and led its two-engineer core build, posting reconciled records to NetSuite with a full audit trail; a Sage Intacct integration removed a recurring class of failed upserts.
  • Built an internal MCP server and agent rule set adopted org-wide — about 40% less development time and 25% less rework across the org (shared team effort).
Jun 2022 — Sep 2023 Manhattan, NYC

Haven Technologies

  1. QA Automation Engineer

Led QA automation for a life-insurance technology platform — designing the end-to-end and browser-automation framework across web UI, REST APIs, and backend services, with behavior-driven specs both engineers and product could read.

CypressCucumberREST APIsTestRail
  • Designed and maintained the end-to-end and browser-automation framework (Cypress, Cucumber) across web UI, REST APIs, and backend services.
  • Automated regression, API, and UI suites that ran on every release — catching defects earlier and keeping coverage traceable in TestRail.
Research & personal builds

Algorithmic trading & decision-support system

Designed and built end to end: a Python / FastAPI backend runs Monte Carlo simulations to produce probabilistic return ranges rather than single-point forecasts, enforces a 25% position-concentration limit, and benchmarks every strategy against a market index. Results persist in SQLite and surface through a React / Recharts dashboard.

PythonFastAPIReactSQLite
Personal build

Stock-price forecasting — ARIMA vs. LSTM

Graduate AI research at Northeastern (CS5100), co-authored. A multi-layer LSTM in TensorFlow / Keras forecasts ten years of daily Apple closing prices. I built the LSTM; my co-author led the ARIMA side.

The paper reports RMSE under 1 for the LSTM and about 7 for ARIMA. Those two numbers aren't directly comparable, and I'd rather say so first: the LSTM error is on MinMax-normalized data, the ARIMA error is in dollars. The paper also notes the ARIMA series was likely over-differenced, which makes it a weak baseline. The model worked. The comparison needed a shared scale.

PythonTensorFlowKerasTime series
Stack

What I reach for, and why.

Applied AIModel Context Protocol servers and agent rule sets, local model serving via Ollama, TensorFlow / Keras
LanguagesPython, TypeScript, JavaScript, Apex, SQL / SOQL
BackendFastAPI, Node.js, REST API design, asynchronous and bulk data processing, ingestion and validation
IntegrationERP systems (NetSuite, Sage Intacct), third-party APIs, finance and operational data flow
PlatformApex (async, batch, stateful), Lightning Web Components, Flows, Bulk API 2.0, custom metadata
TestingCypress, Cucumber (BDD), browser automation, Pytest, TestRail
DeliveryCircleCI, GitHub Actions, Docker, AWS, Bitbucket
FrontendReact, Next.js, Tailwind, Recharts
SpokenEnglish and Arabic, Spanish (conversational)
EducationM.Eng, Computer Science & Cybersecurity — Northeastern University, Khoury College
Contact

Working on something nobody has a playbook for?

Tell me what you're working on. I read every message and reply from my own address — I just don't publish it.