CSGJava Software Engineer, Product R&DFull-timeAug 2025 – present
Product R&D — configuration and validation systems
Specification-driven services, shared validation, and quality practices in a large product R&D environment.
backend · integration · automation
I build software by figuring out how the pieces fit together.
I work on backend systems, integrations, and automation. Much of the job is tracing how services interact, finding where a fix affects another path, and making those changes easier to review.
Working note / delivery tracereviewable
follow the work from problem to release →
keep the important decisions recorded.problem → constraints
→ decision → documentation
keep the important decisions recorded.problem → constraints
→ decision → documentation
↻ feedback looprecord the trade-offs
01 / Selected work
Selected work
A few engineering problems I've spent real time understanding, changing, and improving.
InfinIDBackend EngineerFull-timeSep 2024 – May 2025
Backend & platform engineering
Backend services, API gateways, deployment tooling, and integrations for a loan platform.
Bank Central AsiaSoftware Engineer, General LedgerFull-timeOct 2019 – Aug 2024
Ledger systems and data pipelines
Backend and batch-processing work for General Ledger systems in a large retail bank.
02 / Writing
Writing from the work and its edges.
Case studies and shorter notes on the decisions, constraints, and lessons behind the work.
Featured writing · case study
Repeatable API-gateway delivery across environments
How I made API-gateway configuration easier to review and promote across environments.
Case-study summary
from the case study
Context
Gateway configuration had been handled differently in each environment. That made reviews manual and made it hard to see what changed during promotion.
Constraints
Changes must be reviewable in version control. Non-production and production may differ, but reviewers need to see exactly how.
Approach
Separate environment-specific settings — put them in named configuration layers so reviewers could see what changed between environments. Use one promotion pipeline — validate, package, and apply gateway configuration through the same documented steps. Document the gateway responsibilities — record where routing, authentication hooks, and rate limits were owned so operators could find the answer quickly.
contextconstraintsapproachtrade-offsoutcomes
Open case study ↗Featured writing · case study
Configuration playground for domain experts
An internal playground where analysts could test assessment-rule changes without production access or one-off engineer scripts.
Case-study summary
from the case study
Context
Loan assessment logic changes often start with analysts who understand credit policy but cannot safely experiment in production. Testing a policy change often required an engineer to run a script or interpret spreadsheet changes before analysts could compare the result.
Constraints
No customer or production data in the playground; synthetic inputs only. Changes must be explainable to compliance-minded reviewers, not only to the author. The tool should complement — not replace — the authoritative servicing systems.
Approach
Keep policy exploration separate from execution — give analysts configurable scenarios with named inputs and expected outputs they could compare. Define what could change — show which parameters were editable, which were fixed, and which needed an engineering release. Save useful scenarios — use them as regression cases when a policy changed again next quarter.
contextconstraintsapproachtrade-offsoutcomes
Open case study ↗Featured writing · case study
Legacy batch jobs to SQL pipelines
Moving COBOL-era batch processing toward observable, idempotent ETL while keeping the remaining mainframe work in view.
Case-study summary
from the case study
Context
A General Ledger organization still depended on a large COBOL batch estate. Teams needed faster change cycles, better observability, and pipelines that could survive retries without corrupting accounting state.
Constraints
Financial correctness mattered more than migration speed; partial automation could be worse than slower automation with evidence. Operations were still organized around batch windows, logs, and runbooks, so new tooling had to fit those workflows. Jobs still needed to show which environment and ledger slice they touched.
Approach
Inventory the real batch graph — which jobs are pure transform, which encode business rules, which are safe to parallelize. Move selected jobs incrementally to SQL-based ETL — with explicit logging and idempotency at load boundaries, while leaving jobs that still needed the legacy path in place. Instrument for operators — log parsing and replay-friendly steps so retries could be performed intentionally and traced afterward. Add internal tooling — a full-stack, metadata-driven parameter dashboard with soft locks, versioning, audit logs, and approval workflows so report owners no longer had to request production edits by email. Revamp the dashboard safely — clean architecture, atomic models, and decoupled metadata made the parameter workflow easier to scale and reuse.
contextconstraintsapproachtrade-offsoutcomes
Open case study ↗More writing
Shorter notes and external publications from the edges of the work.
Loading external writing…
03 / How the work connects
Questions that recur in the work
The Systems Map groups related work, projects, and writing.
Where does behavior vary?
Name the environment- or rule-specific differences instead of carrying them in special cases.
Seen in
Product R&D — configuration and validation systems · KrakenD infrastructure-as-code toolkit · Applied computer vision thesis system
See related work ↗How does a change get repeated?
Turn a one-off delivery step into a documented, tested sequence that someone else can run again.
Seen in
Product R&D — configuration and validation systems · Repeatable API-gateway delivery across environments · Legacy batch jobs to SQL pipelines
See related work ↗Who owns the decision?
Name the service or team responsible for a behavior, its interface, and the decision point.
Seen in
Product R&D — configuration and validation systems · Repeatable API-gateway delivery across environments · System assessment before commitment
See related work ↗04 / Projects
Independent projects and experiments.
Portfolio publishing pipeline
Astro portfolio site with Markdown-backed public content, typed publishing checks, and a selective Field Notes knowledge surface.
astrocontent-pipelineportfolio
Open project ↗KrakenD infrastructure-as-code toolkit
CLI and templates for API-gateway configuration across environments, with container build and publish automation.
krakendplatformopen-source
Open project ↗Applied computer vision thesis system
Web-based physical-distancing detector using object detection and deep learning, later developed into a published thesis project.
computer-visiondeep-learningresearch
Open project ↗06 / Contribution
I also spend time teaching, mentoring, and reviewing technical work.
Courses, capstone teams, curriculum work, code reviews, and community programs alongside engineering.
40Instructional sessions(Teaching + tutoring · 2022–present)
58Mentoring and facilitation sessions(2022–present)
188 hoursHours instructed(Recorded session duration · 2022–present)
50.75–82.75 hours · estimatedHours mentored(Estimated from available session records)
4.67–4.95 / 5 · avg 4.78Teaching/tutoring ratings
4.73–5.0 / 5 · avg 4.95Mentoring ratings
Instructor + advisor
Dicoding partner programs
Coding Camp, Bangkit, AWS Back-End Academy, Asah, and PIDI Digdaya.
Instructor + mentorRakamin · BNI ODP
DevSecOps instruction and final-project mentoring.
Student mentorStudent mentoring programs
Structured mentoring for vocational and university students through Microsoft Future Ready and Samsung Solve for Tomorrow.
Community contributionCode in Place · ADPList · community sessions
Introductory programming instruction, one-on-one mentoring, and community teaching.
Want to talk?
If something here overlaps with what you're working on, feel free to get in touch.
Email me ↗