I've built several software systems for Indonesian local government: SIREKA for financial reconciliation at BPKAD Kabupaten Tanah Laut, the ISDN platform connecting the district court with the national land agency, SIMPKB for vehicle tax reporting, and the BPKAD institutional website. Each project taught me something different, but the lessons share a common thread.
This post collects the most important things I've learned about building software that works in Indonesian government environments.
Lesson 1: Status is the most important feature
In government workflows, status isn't a small UI detail. It's how teams understand what has happened and what needs attention next.
Consider a financial reconciliation process. A report might be:
- Submitted by a SKPD
- Under review by BPKAD
- Rejected with revision notes
- Resubmitted by the SKPD
- Verified by BPKAD
- Approved and locked
- Archived for audit
Each status represents a different stage in the workflow, with different actions available and different people responsible. If the status isn't clear, the entire workflow breaks down.
In SIREKA 1.0, status existed but wasn't visible enough. Users had to check manually whether their reports had been reviewed. Administrators had to check manually which reports needed attention. The system tracked status internally but didn't surface it effectively.
SIREKA 2.0 fixed this by making status the centerpiece of the interface. Checklist indicators show uploaded vs. missing documents. Progress bars show completion rates per period. The monitoring workspace lets administrators filter by status across all organizations.
The lesson: in government software, status visibility isn't a nice-to-have. It's the core value proposition.
Lesson 2: Permissions need to match organizational structure
Indonesian government organizations have clear hierarchies and role divisions. BPKAD has administrators who manage the system. SKPD units have different roles — Pengurus Barang for asset reports, Bendahara Pengeluaran for expenditure, Bendahara Penerimaan for revenue. BLUD units have their own reporting structure.
The permission system needs to reflect this reality. Each role should see only the reports relevant to their function. An administrator sees everything. A SKPD expenditure officer sees only expenditure reports for their unit. A BLUD operational manager sees only BLUD-specific documents.
In SIREKA, this meant designing role-based access that maps to actual government roles — not generic "admin/user/viewer" roles, but specific roles like "Admin BPKAD," "Pengurus Barang," "Bendahara Pengeluaran," and "Bendahara Penerimaan."
The lesson: generic role systems don't work well in government. The permission model needs to mirror the actual organizational structure, or users will be confused about what they can see and do.
Lesson 3: Government workflows are state machines
The most useful mental model for government software is a state machine. Each piece of work (a report, a document, a request) moves through defined states with clear transitions and accountability at every step.
In SIREKA, a report moves through: submitted → under review → approved/rejected → revised → resubmitted → verified → archived. Each transition has a responsible party, a timestamp, and often a comment or reason.
In the ISDN platform, a land certification case moves through: filed → BPN verification → court hearing → ruling issued → BPN processing → certificate issued. Each stage has different data requirements and different stakeholders.
In SIMPKB, a vehicle tax report moves through: submitted → validated → processed → completed. Each stage has specific validation rules.
The state machine model works because it makes the workflow explicit. Everyone can see where a piece of work is, what happened to it, and what needs to happen next. It also creates a natural audit trail — every state transition is recorded.
The lesson: don't model government workflows as simple CRUD operations. Model them as state machines with defined states, transitions, and responsibilities.
Lesson 4: The data model must mirror the organizational structure
Government data has inherent hierarchy. In SIREKA, the hierarchy is:
SKPD
└─ Bidang (Division)
└─ Sub Bidang (Sub-division)
└─ Report Reference
└─ Template
└─ Submission
└─ Revision
└─ Approval
This isn't arbitrary nesting — it mirrors the actual government organizational structure. Each level has different responsibilities and different data needs.
When the data model matches the organizational structure, several things become easier:
- Permission checks are natural (a Bidang officer sees only their Bidang's data)
- Reporting follows organizational lines (reports can be aggregated by SKPD, Bidang, or Sub Bidang)
- The UI can present data in a way that matches how users think about their work
When the data model doesn't match, you get awkward workarounds — filtering that doesn't quite work, permissions that need exceptions, reports that require manual grouping.
The lesson: study the organizational structure before designing the database. The data model should be a digital mirror of how the organization actually works.
Lesson 5: Audit trails aren't optional
In government environments, accountability is paramount. Every significant action needs to be recorded: who did it, when, and why.
SIREKA records every state transition, every document change, every comment, and every user activity. This isn't just for compliance — it's for operational transparency. When a report is rejected, the rejection reason is recorded. When a document is resubmitted, the revision history is preserved. When an administrator reviews a report, the review activity is logged.
The ISDN platform records every step of the land certification process — from initial filing through court hearing to certificate issuance. This creates a permanent record that can be referenced if questions arise later.
The lesson: build audit trails from day one. Don't treat them as an afterthought. In government software, the ability to trace every action back to its source is a core requirement, not a feature to be added later.
Lesson 6: The interface must match real administrative routines
Government workers have established routines. They check certain things in the morning, process certain types of work after lunch, and prepare reports at the end of the day. The software should support these routines, not disrupt them.
In SIREKA 2.0, the admin monitoring workspace was designed around the actual monitoring routine. Administrators start by checking overall compliance (the dashboard), then drill into specific organizations (the sidebar), then review specific documents (the workspace). The interface follows the same sequence they would use when checking manually.
In the BPKAD website, the content structure was designed around how citizens actually look for information — not how the internal organization is structured. Citizens don't care about Bidang divisions; they care about services, news, and contact information.
The lesson: observe how people actually work before designing the interface. The best government software feels like a natural extension of existing routines, not a replacement for them.
Lesson 7: Document management needs structure, not just storage
Government work is document-heavy. Reports, templates, official letters, supporting evidence — documents are the currency of government operations.
The temptation is to build a document storage system — upload files, organize them in folders, search by name. But government document management needs more than storage. It needs:
Applicability rules. Not every document applies to every organization or every period. The system needs to know which documents are required for which scenarios.
Status tracking. Each document has a lifecycle — not uploaded, uploaded, under review, approved, rejected. The system needs to track this per document, not just per report.
Period-based grouping. Documents belong to specific reporting periods. A document uploaded for January's monthly report is different from the same document type uploaded for Q1's quarterly report.
Category filtering. Documents can be grouped by category (planning, expenditure, revenue) to help users and administrators navigate large document sets.
SIREKA 2.0's document matrix addresses all of these. It's not just a file storage system — it's a structured document governance system that knows which documents are required, for whom, and when.
The lesson: government document management needs rules, not just storage. The value is in the structure, not the volume.
Lesson 8: WhatsApp is the real notification system
In Indonesian government environments, WhatsApp is the primary communication channel. Official coordination, informal follow-up, status updates — much of it happens through WhatsApp groups and direct messages.
This has implications for software design. Push notifications through the app are useful, but they're not sufficient. Many users won't have the app open regularly. WhatsApp notifications reach them where they already are.
The ISDN platform uses WhatsApp for case status updates. When a case moves to a new stage, the resident receives a WhatsApp message. This works because residents check WhatsApp daily — they might not check the app as frequently.
The lesson: design notification strategies around existing communication habits, not idealized app usage patterns. In Indonesia, that often means WhatsApp integration.
Lesson 9: Start with the workflow, not the technology
The most successful government software projects I've worked on started with deep engagement with the actual business process — understanding not just what forms need to be filled, but how information flows between departments, where bottlenecks occur, and what "complete" looks like from every stakeholder's perspective.
SIREKA 2.0 wasn't designed by looking at the old system and adding features. It was designed by observing how BPKAD administrators actually manage reporting schedules, how SKPD users actually submit documents, and where the pain points were in the existing workflow.
The ISDN platform wasn't designed by connecting two databases. It was designed by understanding how court rulings actually flow into certificate processing — what data needs to transfer, what validations are needed, and what the resident needs to see at each stage.
The lesson: technology choices matter, but workflow understanding matters more. The best stack in the world won't save a project that doesn't understand the problem it's solving.
Lesson 10: Simple beats sophisticated
Government users have varying levels of technology proficiency. Some are comfortable with complex interfaces; many are not. The software needs to work for everyone.
This means:
- Clear labels instead of technical jargon
- Visual indicators instead of dense data tables
- Step-by-step flows instead of feature-rich dashboards
- Obvious actions instead of hidden menus
SIREKA 2.0's upload interface is deliberately simple. Each document has a card with a clear status indicator and an obvious upload button. There's no ambiguity about what to do or what the current state is.
The lesson: simplicity is a feature, not a limitation. In government software, the most sophisticated solution is the one that non-technical users can actually use.
What these lessons have in common
Looking back across all these projects, the common thread is this: government software succeeds when it respects the existing work.
The work has structure — status flows, organizational hierarchies, document requirements. The software should make this structure visible, not replace it with something new.
The work has routines — daily checks, periodic reviews, scheduled submissions. The software should support these routines, not disrupt them.
The work has accountability — audit trails, role-based access, traceable actions. The software should enable this accountability, not complicate it.
The best government software doesn't feel like software. It feels like a clearer, more organized version of the work that was already happening. It makes the existing process visible, traceable, and efficient — without forcing people to learn a new way of working.
That's the goal. Not flashy interfaces. Not cutting-edge technology. Just clear, reliable, well-structured software that makes government work easier.