Engineering depth
The layer under the cards.
Problem, approach, key decisions, and evidence for each project on the front page.
Node.js · Puppeteer · Chrome Extension
Scraping & Sync Pipeline
Problem
A client workflow required copying data from German and Austrian source websites into a
third-party platform, record by record, by hand — roughly 10 minutes of manual work per run,
repeated constantly, with no confirmation trail beyond "someone did it".
Approach
A five-stage pipeline: crawl → extract → transform → submit → track. Puppeteer crawls the target
sites, a Chrome extension supports operator-driven capture for pages that resist headless
automation, the backend validates and transforms what it gets, submits records to the third-party
platform in batches, and synchronizes status back over email.
Key decisions
- Puppeteer plus a Chrome extension, not Puppeteer alone. Some targets defeat headless automation; the extension keeps a human in the loop exactly where the loop needs one, and nowhere else.
- Batch submission capped at 10 records. Large enough to kill the manual work, small enough that a failed batch is cheap to inspect and retry.
- Email as the status channel. The third-party platform offered no API or webhook for submission status — but it did send email. Parsing that email closed the loop without pretending the platform had an API.
- Validate before submit. Extracted data is checked and normalized before it goes anywhere near the destination platform, so bad records fail in my pipeline, not in someone else's system.
Evidence
- ~10 minutes of manual work eliminated per workflow run.
- Batch throughput of up to 10 records per operation, with a status trail for every record.
- Client work for Schutze Web Engineering (German market) — no public repo, architecture described here.
← back to all work
Magento 2 · PHP · GraphQL · MySQL
E-commerce Backend at Scale
Problem
Flagship e-commerce stores run on their checkout path: when payments or integrations break,
the business bleeds revenue by the minute. At ICUBE by SIRCLO I was the backend engineer on
three flagship Magento 2 stores, responsible for the modules, APIs, and monitoring that kept
that path alive.
Approach
Custom Magento 2 modules for payment workflows and business processes, GraphQL and REST APIs
for storefronts and third parties, and a Slack monitoring pipeline so production issues surfaced
where the team was already looking — not in a log file nobody opened.
Key decisions
- Payment logic in isolated custom modules. Checkout is the one path you don't entangle with everything else — separate modules kept payment workflows testable and deployable independently.
- GraphQL where clients need flexibility, REST where integrations need contracts. Storefronts composed their own queries; third-party and internal consumers got stable REST endpoints.
- Slack as the monitoring surface. Alerting only works if people see it — routing production events into the team's existing channel beat any dashboard.
- Scope discipline. A focused set of business-critical integrations (payments, Google Ads, Slack ops) done properly, rather than a long tail of half-maintained connectors.
Evidence (scope proxies)
- 3 flagship production stores: sallangsallang.com, wacoal.com.hk, bixbox.co.id.
- 5–10 custom modules built or led, including payment workflow modules on the checkout path.
- Integrations: payment gateways, Google Ads, Slack ops monitoring, external business APIs.
- Project team of ~5 including tech lead and PM; different projects rotated team composition.
← back to all work
Automation · AI Content API · PDF Processing
Podcast Automation Pipeline
Problem
A client needed finished podcast episodes produced from static PDF documents, on an ongoing
basis. Doing it by hand — read, summarize, script, record — doesn't scale past the first episode.
Approach
An end-to-end document-to-content pipeline: ingest the PDF, extract and structure the content,
then generate finished audio through the AutoContent API — a NotebookLM-style AI content
generation service. The same extract → structure → generate shape as any data pipeline, with
audio as the output format.
Key decisions
- Third-party AI content API over self-hosted generation. The product was the pipeline, not the model — buying generation let me spend engineering time on ingestion, structuring, and reliability.
- Structure before generate. Raw PDF text goes through an extraction and structuring stage first; the quality of the audio output is decided there, not at the API call.
- Unattended batch operation. The pipeline is designed to run without a human — documents in, episodes out.
Evidence
- PDF in, finished podcast episode out — no manual steps in between.
- Client work for Schutze Web Engineering — no public repo, architecture described here.
← back to all work