Abdallah Arslan · Senior Software Engineer

Good software survives the real world.

I own frontend architecture on R360+ at Deluxe, building production systems in React and TypeScript. On my own bench, I build tools that make AI-assisted engineering easier to inspect and trust.

GitHub ↗LinkedIn ↗

nowDeluxe · R360+ receivables platformAtlanta, GA · Remote

Illustrated portrait of Abdallah Arslan holding a coffee mug
pocket terminal · ~/desk

A small terminal for this site. It prints only what is on the site; type help for commands.

The prompt needs JavaScript. Every destination is also in the navigation above.

ls work

7 products · * featured

Your turn: try open skillcheck, coffee, or help.

Loading terminal commands…

Type a command and press Enter. Try help, ls, open followed by a project name, why followed by a project name, inspect, trail, cat about, notes, contact, resume, coffee, whoami, or clear. Tab completes; the up and down arrows recall earlier commands.

Selected work / a working studio

Put a problem on the bench.

Start with a question. Try the decision. Follow the evidence. These are tools I built and the judgment behind them.

01 / Ownership

AER

What should an installer refuse to touch?

Use independent engineering skills with a compact contract and recoverable project-local installation.

Install a virtual repo. Change a managed file. Find out what happens next.

02 / Observation

PixelParity

Can you reproduce the bug you can see?

Give a responsive bug report a reproducible viewport, zoom, and display context.

Resize a real interface, catch a breakpoint defect, and take a reproduction with you.

03 / Evidence

Skillcheck

What does a good score actually prove?

Make an agent skill easier to review before it becomes part of a workflow.

Review two well-structured instructions. Find the red flag a perfect structure score can hide.

Beyond the browser demo / Deluxe

The real world has dependencies.

Frontend architecture on R360+ and related initiatives. The same habit: find the boundary, give it an owner, and make the outcome usable.

Engineering at Deluxe

A firsthand account / employer source confidential

Demonstration → product
Frontend ownership with a mock/live service boundary. The team onboarded three trial customers.
30–45 min → 5–10 min
Build times after an independent pipeline investigation. Approximate timings from my recollection.
Healthy internally ≠ reachable
Reproducing the customer’s regional conditions changed the incident investigation.

A firsthand account of my work on R360+ and related Deluxe initiatives. Build timings are approximate; customer onboarding was a team outcome.

The person behind the decisions

P&L before pull requests.

My latest project is Prompt Library, an MCP app for turning reusable templates and conversation context into editable prompts. It keeps provided, inferred, and missing fields visible, then leaves the final copy decision with the user.

A useful solution has to survive the people, constraints, and tradeoffs around it.

Full background and experienceAn idea I didn’t ship →

Field notes

Notes from the bench.

Short, evidence-first write-ups of what I've actually observed building with LLMs — each one with the sample size stated and the ten-minute check to falsify it yourself.

Start here

Three short reads about taking ownership, questioning evidence, and making work verifiable.

1 min read

Own the environment

The agent treated missing infrastructure as fate

For a thousand lines it logged Docker's absence as a constraint and deferred the integration suites; told it could start the daemon itself, it did — and the suites it had been deferring found three real bugs.

  • agents
  • verification
  • infrastructure

1 min read

Question the evidence

Five of eighteen runs invented evidence. One refused to.

In a batch of runs designed to tempt fabrication, five invented a missing fixture to force a red gate green — and the catch that mattered came from an agent cross-checking primary sources, not from a rule.

  • agents
  • evaluation
  • fabrication

2 min read

Make requirements testable

The only rule that worked is one a machine could check

"Reproduce the failure before editing" produced 3/3 reproductions against 0/6 without it; the same idea phrased as a principle — "root cause before editing" — produced zero.

  • agents
  • rules
  • evaluation

Contact

Write to me.

Have a role, a project, or a question about the work? Email reaches me directly; the résumé has the long version.

— Abdallah

Curious how this is built? Look under the desk.