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.
STAR Documentation.
Situation
Klaim.id needed a full reimbursement and claims management platform for HR operations, including claim submission, payment and reimbursement flows, multi-tenant separation, dynamic scheduling, internal operational tooling, and secure infrastructure from day one.
Task
- Architect and build the reimbursement SaaS platform from scratch.
- Define infrastructure, deployment, and permission strategy.
- Collaborate directly with the CTO and PM to align technical delivery with product goals.
Action
- Applied Clean Architecture and SOLID principles across the backend implementation.
- Designed and implemented infrastructure including CI/CD pipelines, Docker Swarm orchestration, secret management, proxy routing, and permission controls.
- Built APIs for delivery and payment/reimbursement workflows integrated with Midtrans.
- Implemented dynamic scheduling features based on customer requirements.
- Set up APM monitoring using the ELK Stack to track performance and reliability.
- Designed multi-tenant sharding to support scalable customer data separation.
- Developed WhatsApp BOT standby-mode features to improve customer engagement and automation.
Result
- Delivered a full reimbursement SaaS platform from scratch.
- Enabled scalable multi-tenant customer separation through sharding design.
- Improved reliability and issue detection using ELK-based APM monitoring.
- Expanded customer-facing automation with WhatsApp BOT capabilities.
Results & Metrics
Delivery scope
Full SaaS built from scratch
Tenant model
Multi-tenant sharding
Monitoring stack
ELK + APM
Technical Decisions
Choose Docker Swarm for orchestration
The environment needed practical orchestration with manageable complexity, allowing the team to move quickly while still supporting multiple services and routing needs.
Separate tenant data deliberately
Multi-tenant reimbursement flows create long-term scaling and security concerns, so data separation strategy had to be treated as core architecture.
Add APM and ELK early
The platform involved many workflows and integrations, so visibility across logs and traces was necessary for operational reliability.
Architecture Diagram
ERD
API Documentation
Base path
/api/v1/claims
Auth
Bearer token + role-based permission
Rate limit
100 req/min
/Create a reimbursement claim.
Auth: Required
Rate limit: 50 req/min
Example request
{
"tenant_id": "uuid",
"amount": 350000,
"category": "transport",
"attachments": ["file-id"]
}Example response
{
"status": "success",
"claim_id": "clm_123",
"approval_status": "pending"
}/:id/reimburseTrigger reimbursement payment workflow.
Auth: Finance role required
Rate limit: 20 req/min
Performance & Operational Notes
The most important performance work here centered on reliability, visibility, and scale readiness rather than public benchmark numbers.
Tenant scaling approach
Sharding-ready
Operational monitoring
ELK + APM
Automation
WhatsApp BOT support
Security Measures
- Permission controls designed as part of the platform foundation.
- Secret management included in infrastructure design.
- Tenant-aware separation to reduce data leakage risk.
- Proxy and gateway layer used to centralize traffic control.
Testing Strategy
The platform needed confidence across workflows, tenant separation, and payment/reimbursement actions.
Coverage / confidence
Portfolio-documented approach
- Validation of claim and reimbursement business rules.
- Role-aware access verification for approval and finance paths.
- Integration validation for Midtrans-backed payment flows.
Deployment Strategy
I owned a large portion of the operational setup as part of the delivery.
- CI/CD pipelines with GitLab CI and Jenkins.
- Docker Swarm orchestration for deployment management.
- Proxy routing, secret management, and environment setup as part of the platform foundation.
Challenges Faced
- Balancing platform architecture with direct business delivery needs.
- Designing multi-tenant behavior that would still remain maintainable later.
- Supporting payments, approvals, scheduling, and messaging without bloating the codebase.
Lessons Learned
- A multi-tenant SaaS platform becomes easier to evolve when infrastructure and permission design are treated as product requirements.
- Operational observability is especially important when multiple workflows and integrations meet inside one service boundary.
- Clean architecture is most valuable when the system has to keep adapting under changing customer requirements.
Related ADRs
adr-docker-swarm • Accepted
ADR-003: Use Docker Swarm for Reimbursement SaaS Orchestration
Use Docker Swarm as the orchestration layer together with CI/CD, proxies, and secret management.
adr-tenant-separation • Accepted
ADR-004: Design Tenant Separation Early for HRIS Reimbursement
Design multi-tenant sharding and permission strategy as core architecture, not as an afterthought.