Back End Portfolio Report.

A structured backend engineering report covering executive summary, skills matrix, STAR project documentation, security awareness, ADRs, and lessons learned.

Back End Portfolio Report.

I am a senior software engineer with more than seven years of experience building backend systems and scalable business platforms. My strongest specialization is backend development with Golang, supported by working knowledge of JavaScript, TypeScript, PHP, C#, and Dart when product context requires flexibility.

Across fintech, HR SaaS, transportation, and internal operational products, I have worked on architecture design, API development, multi-tenant systems, observability, CI/CD, infrastructure setup, and large-scale backend improvements. I care about clean architecture, operational clarity, and building systems that stay maintainable as they grow.

This portfolio is structured to show not only what I built, but how I think: problem framing, technical decisions, architecture, security awareness, and measurable delivery impact.

Technical Skills Matrix.

Category	Skills	Proficiency
Languages	Golang, JavaScript, TypeScript, PHP, C#, Dart	Advanced
Databases	PostgreSQL, MySQL, MariaDB, MongoDB, Redis, SQL Server	Advanced
Backend & Architecture	REST API, Microservices, Multi-tenant Design, Clean Architecture, SOLID, System Integration	Advanced
DevOps & Platform	Docker, Docker Swarm, Jenkins, GitLab CI, GitHub Actions, Traefik, Kong	Advanced
Observability & Security	ELK Stack, Prometheus, Grafana, New Relic, APM, RBAC, Rate Limiting	Intermediate to Advanced

Featured Project Evidence.

These case studies are the strongest documentation-ready examples in the portfolio and each links to a dedicated detail page.

Digital finance and resident operations platform for transparent community management.

Sahabat Warga by Saga

Built the product foundation for a digital finance and services ecosystem that helps housing clusters and neighborhood operators manage dues, resident data, introduction letters, reporting, and communication in one platform.

GolangJavaScriptTypeScriptNode.jsVue.jsReactNext.jsPostgreSQLRedisMySQLRabbitMQJenkinsDockerDocker SwarmTraefikKeycloakQRISVirtual AccountWhatsApp

View case study Live product

Digital finance platform work inside Amartha's inclusive financial ecosystem.

AmarthaFin E-Wallet

Architected and delivered a full e-wallet platform from scratch inside Amartha's broader digital finance ecosystem, with a strong focus on clean architecture, observability, migration safety, and reusable backend modules.

GolangPostgreSQLRedisPrometheusGrafanaNew RelicRedashMicroservices

View case study Company site

Claims management platform built from scratch with multi-tenant and infrastructure ownership.

Klaim.id Reimbursement SaaS

Architected and developed a reimbursement SaaS product from scratch that aligns with Klaim.id's public positioning as a fast, customizable claims management platform connected with WhatsApp.

GolangPostgreSQLRedisMongoDBDockerDocker SwarmGitLab CIJenkinsKongTraefikELK StackElasticsearchKibanaAPM

View case study Live product

Interactive maps, integrated data sources, and operational reporting.

Smart Geo Trace

Drove redevelopment of internal maps data visualization with interactive features, integrated several data sources, and improved the cost and effort of existing implementation flows.

GolangJavaScriptTypeScriptNode.jsVue.jsReactNext.jsPostgreSQLRedisMySQLMapLibre JSDockerDocker SwarmTraefikRabbitMQ

View case study

Security Awareness.

I treat security as part of delivery quality. Even when a project is not explicitly a security product, backend systems should document how access control, safe integration, observability, and operational safeguards are handled.

Vulnerability	Status	Implementation
Broken Access Control	Mitigated	Role-aware permissions and approval boundaries on sensitive workflows.
Cryptographic Failures	Addressed operationally	Sensitive flows designed around provider-backed integrations and secure environment handling.
Injection	Mitigated	Backend validation and structured query handling in service layers.
Insecure Design	Mitigated	Clean architecture, tenant separation, and explicit workflow modeling.
Security Misconfiguration	Mitigated	Secret management, proxy routing, and infrastructure setup treated as first-class concerns.
Logging and Monitoring Failures	Mitigated	ELK, APM, Prometheus, Grafana, New Relic, and operational dashboards.

Architecture Decision Records.

adr-clean-architecture-walletAccepted

ADR-001: Use Clean Architecture for Wallet Core Services

Context

The wallet platform needed to evolve safely while supporting migrations, financial workflows, and observability.
The backend would likely change over time, so business logic needed protection from framework and infrastructure churn.

Decision

Use clean architecture boundaries so wallet business rules remain isolated from delivery and infrastructure layers.

Positive

Reduced long-term coupling inside the service.
Made core use cases easier to reason about and evolve.
Supported reusable modules for logging and monitoring.

Trade-offs

Added design effort up front.
Required stronger discipline across the team.

Alternatives

Direct framework-centric service design (Rejected)

Pros: Faster at the beginning

Cons: Harder to change safely later

adr-observability-firstAccepted

ADR-002: Build Reusable Observability Into Financial Backend Work

Context

Distributed financial systems become expensive to troubleshoot when visibility is inconsistent.
Operations teams needed better support for tracing and production decisions.

Decision

Standardize reusable logging and monitoring modules and connect them to dashboards and APM.

Positive

Improved troubleshooting speed.
Raised team confidence in production changes.
Created reusable operational leverage.

Trade-offs

Required additional implementation effort outside core feature work.

Alternatives

Minimal service-specific logging only (Rejected)

Pros: Lower initial effort

Cons: Poor cross-service observability

adr-docker-swarmAccepted

ADR-003: Use Docker Swarm for Reimbursement SaaS Orchestration

Context

The platform needed practical service orchestration, routing, and deployment support without unnecessary operational overhead.
The team needed to move quickly while keeping operational control.

Decision

Use Docker Swarm as the orchestration layer together with CI/CD, proxies, and secret management.

Positive

Balanced operational simplicity with multi-service deployment needs.
Worked well with the delivery setup the team could support.

Trade-offs

Less feature-rich than heavier orchestration platforms.

Alternatives

More complex orchestration platform (Rejected)

Pros: Broader orchestration feature set

Cons: Higher complexity for the team at the time

adr-tenant-separationAccepted

ADR-004: Design Tenant Separation Early for HRIS Reimbursement

Context

The product would serve multiple customers with data isolation requirements.
Retrofitting tenant separation later would significantly increase risk.

Decision

Design multi-tenant sharding and permission strategy as core architecture, not as an afterthought.

Positive

Created a cleaner scaling path for customer growth.
Reduced risk around customer data separation.

Trade-offs

Added design and implementation complexity early.

Alternatives

Single-tenant assumptions with later migration (Rejected)

Pros: Lower early complexity

Cons: Higher long-term migration risk

adr-geo-aggregationAccepted

ADR-005: Aggregate Multi-Source Data Before Visualization

Context

The geo platform needed several data sources to support internal operational questions.
Direct frontend dependence on multiple sources would increase fragility.

Decision

Introduce an aggregation API layer so map-facing clients receive visualization-ready data.

Positive

Simplified client integration.
Made future source changes easier to manage.
Improved operational clarity.

Trade-offs

Added an additional backend layer to maintain.

Alternatives

Connect each source directly to the frontend (Rejected)

Pros: Lower initial backend work

Cons: Fragile client complexity and harder scaling

Lessons Learned & Growth

Architecture should protect delivery speed, not slow it down.
Observability is one of the highest-leverage investments for backend teams.
Migration and platform work deserve as much planning as feature work.
The best internal systems are built with the same rigor as customer-facing products.
Strong backend engineering combines technical clarity with business understanding.