Government services / Client project
Bridging a legacy PHP back office to a modern mobile app.
A Flutter mobile app and REST API that make a government document and permit workflow available to citizens and staff.
- Project
- Petakita (LayarSigap19)
- My role
- Flutter developer; built the REST API the app syncs with
- Scope
- Mobile citizen-facing app and REST API for document submission, status tracking, and staff review
- Built with
- Flutter, Dart, PHP 5.6, MariaDB, REST API
- Period
- 2025–2026 · repository activity
- Project status
- Delivered to client
Engineering focus
Legacy workflow mapped into an API
The REST layer exposes an existing SIPENATA approval chain as mobile-consumable JSON while leaving the older server-rendered back office in place.
Citizen and staff paths
Flutter services cover request submission, status/detail views, document access, tracking, notifications, and role-specific approval actions.
Client project for a government agency, deployed to that client as “LayarSigap19”. The screenshot is the real Flutter app running in the iOS Simulator against a local API with synthetic sample data; no real citizen or staff data is shown.
The Flutter repository history runs 2025-10-22–2026-09-06 and the PHP API repository 2025-11-01–2026-09-06; these are repository dates, not delivery dates. The archive records deployment to the government client as LayarSigap19; current availability and maintenance are unverified.
Make an existing workflow useful on a phone
Petakita — deployed to its government client as “LayarSigap19” — pairs a Flutter mobile app with a REST API built specifically for it. The app gives citizens a mobile path to submit requests and follow their status, while staff and leadership keep the review workflow they already use.
The difficult part was the system underneath. The existing PHP back office, known as SIPENATA, already encoded years of approval logic: roles, departments, document permits, and the order in which a request moves through review. It had no API surface, so the work started with tracing that business logic before writing endpoints around it.
Add an API without breaking the back office
I built the REST API to expose the parts the mobile client needs, including token-based authentication, article content, workflow data, and geomap information. The API reads from the legacy database and returns mobile-consumable JSON while leaving the existing server-rendered application in place for the teams that still rely on it.
That meant being conservative about what the API assumed and testing the approval chain against the rules already embedded in the older code. The Flutter app then gives the public and internal users a clearer mobile entry point without pretending the legacy system can be replaced in one step.
A local record of the real app
This case study uses a real local capture of the Flutter application and API. The screenshot shows the supplied app branding and interface, while the local database contains synthetic article and staff records only.