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

STAR Documentation.

Situation

The stealth startup was building a digital finance ecosystem for communities and residential operators that still relied on manual dues tracking, fragmented resident data, paper-based letters, and ad-hoc communication. The public product now appears as Sahabat Warga by Saga, positioned as an all-in-one app for iuran, surat pengantar, data warga, reporting, and resident communication.

Task

  • Analyze the business problem and translate it into a practical product and system plan.
  • Build the platform foundation from scratch so finance, resident operations, and communication could live in one product.
  • Prepare the architecture and integrations needed for digital dues, reporting transparency, resident data management, and broadcast workflows.

Action

  • Designed the overall backend and product flow for a community finance and services ecosystem rather than shipping isolated features.
  • Built core modules around iuran digital, resident data management, surat pengantar workflows, and communication features.
  • Prepared payment-oriented integrations so the product could support flexible collection flows such as QRIS, virtual account, and e-wallet style payment options highlighted on the public site.
  • Structured the platform with containerized services, identity management, reverse proxy routing, and async messaging to keep the system adaptable as the product expanded.
  • Aligned technical delivery with business needs by turning manual neighborhood administration processes into a more transparent digital workflow.

Result

  • Delivered a product foundation that combines digital dues, resident administration, reporting, and communication in a single ecosystem.
  • Supported a transparency-first product positioning with real-time financial reporting and audit-oriented workflows.
  • Helped shape a live public product whose website highlights usage across 100+ communities, 24+ clusters, 1242+ residents, 3 cities or regencies, and 8 managed areas.

Results & Metrics

Public site signal

100+ communities

Cluster coverage

24+ clusters

Resident footprint

1242+ residents

Regional reach

3 cities/regencies

Managed areas

8 areas

Technical Decisions

Treat finance and resident operations as a single platform

Dues, resident records, letters, and communication are operationally connected, so keeping them in one product reduced context switching and improved traceability for administrators and residents.

Separate payment and notification workflows from the core resident domain

Billing, reminders, and payment updates evolve faster than resident master data, so a modular boundary made integrations easier to extend without destabilizing core workflows.

Use container orchestration and centralized identity early

The product needed a reliable deployment path and manageable access control while the business was still iterating, making Docker Swarm, Traefik, and Keycloak pragmatic choices.

Architecture Diagram

ERD

API Documentation

Base path

/api/v1

Auth

Bearer token with role-based access for resident and admin flows.

Rate limit

Applied per client and integration channel for operational safety.

GET/communities/{communityId}/dashboard

Return a consolidated dashboard for resident count, billing status, and communication activity.

Auth: Admin

Rate limit: 60 req/min

POST/billings

Create a billing cycle for digital dues and assign it to target residents.

Auth: Admin

Rate limit: 30 req/min

Example request

communityId
period
amount
dueDate

Example response

billingId
status
residentCount
POST/payments/callback

Receive payment confirmation updates from external payment channels.

Auth: Integration signature

Rate limit: 120 req/min

Example request

transactionId
channel
status
paidAt

Example response

accepted
billingStatus
POST/letter-requests

Submit a resident letter request for neighborhood administration workflows.

Auth: Resident

Rate limit: 20 req/min

Example request

residentId
letterType
purpose

Example response

requestId
approvalStatus
POST/announcements/broadcast

Broadcast an announcement or payment reminder to targeted residents.

Auth: Admin

Rate limit: 10 req/min

Example request

communityId
message
targetScope
channel

Example response

broadcastId
queuedRecipients

Security Measures

  • Aligned the product narrative with public security commitments shown on saga.co.id, including AES-256 data encryption and SSL/TLS protected connections.
  • Used centralized identity and access management with Keycloak to control administrative and resident-facing roles.
  • Kept payment-facing flows behind controlled integration boundaries so billing confirmation and resident-facing operations could be audited separately.

Testing Strategy

Focused on validating billing, resident administration, and integration-sensitive workflows before release.

Coverage / confidence

Backend domain, payment callback flows, and operational scenarios.

  • Validated billing state transitions and payment callback handling.
  • Tested resident data and letter-request workflows against role-based access expectations.
  • Checked communication flows for queued broadcast and reminder scenarios.

Deployment Strategy

Prepared the system for repeatable delivery using the infrastructure stack referenced in the CV.

  • Containerized services with Docker for consistency across environments.
  • Used Docker Swarm and Traefik as a practical orchestration and routing setup.
  • Supported CI/CD-oriented delivery with Jenkins and modular service boundaries.

Challenges Faced

  • Translating offline neighborhood administration habits into product flows that still felt practical to operators.
  • Balancing financial transparency requirements with simple resident-facing experiences.
  • Designing for payments, communication, and resident data in one ecosystem without creating a tightly coupled monolith.

Lessons Learned

  • Community finance products become much more valuable when payment, records, and communication are designed as one workflow.
  • Early architecture choices matter even more when the business is still discovering product-market fit.
  • Public trust features like clear reporting and secure payment handling are product features, not just backend implementation details.

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.