Case study · Road & Highway Project Database

Every kilometre of Indonesia's toll road programme, in one Oracle database.

Indonesia's toll roads are tendered, built and supervised by a single agency, but the record of them lived in whichever workbook was nearest to the work. We built Badan Pengatur Jalan Tol one Oracle project database instead: a row for every road, a row for every section it is delivered in, and one place where the state of the national programme can be read without assembling it first.

See what we built Ask about a project database
Badan Pengatur Jalan Tol Badan Pengatur Jalan Tol
Sector
Toll road regulation & public infrastructure
Location
Jakarta, Indonesia
Engagement
Road & highway project database, on Oracle
Delivered
Delivered as a registered vendor of SMEC
Jan 2025 engagement began
Dec 2025 delivered and handed over
Oracle one database for the programme
12 months data model to handover
The client

The agency that regulates Indonesia's toll roads.

Badan Pengatur Jalan Tol, the Toll Road Regulatory Agency, is the unit of Indonesia's Ministry of Public Works responsible for the country's toll roads. It was established in 2005 and works from Jakarta.

Its remit is the whole life of a toll road. BPJT tenders toll road investment through open bidding, recommends initial tariffs and subsequent adjustments to the Minister, recommends the takeover of concessions that have run their term or failed their obligations, and supervises the business entities holding those concessions against the agreements they signed, reporting back to the Minister.

That is a large number of roads to hold in mind at once. Indonesia's operational toll network has passed 3,100 kilometres across Java, Sumatra, Bali, Kalimantan and Sulawesi, roughly three quarters of it built in the decade to 2024, and every road is at a different stage in the hands of a different concessionaire. Regulating a programme of that shape is a data problem before it is anything else.

  • Mandate Regulation & supervision of toll roads
  • Based in Jakarta, Indonesia
  • Established 2005
  • Network supervised National toll roads, 3,100 km and growing
What the database has to keep straight
  • Toll road concessions
  • Trans-Java network
  • Trans-Sumatra network
  • Sections & interchanges
  • Land acquisition
  • Construction progress
  • Tariff decisions
  • Operating agreements
The brief

What had to change.

The brief was not "build us a dashboard". It was to make a figure about the programme mean the same thing in every room it is quoted in.

One road, several workbooks

Each road, and often each section of a road, was tracked by whoever was closest to it. There was no single record you could open to settle where a project actually stood.

Sections did not roll up

A toll road is delivered in sections that start and finish years apart. Nothing connected a section back to its road, so progress on the road as a whole had to be reassembled by hand every time it was asked for.

Reporting took days and aged at once

A programme-wide status report meant collecting files, reconciling the ones that disagreed and reformatting the result. By the time it circulated, part of it was already wrong.

No history to answer with

When a date, a scope or a tariff had changed, the files held only the current value. There was no record of what it had been, when it moved, or who approved the move.

What we built

One Oracle database, and three ways into it.

The project database is what we actually delivered: a normalised Oracle schema for roads, sections, concessions, milestones, progress and money. Around it sit the screens the agency works in and the reports it is obliged to produce.

The project database

The system of record: one row per road, one per section, and every fact about them dated and attributable.

Road & section register

Every toll road in the programme, broken into the sections it is genuinely delivered in, each with its own length, alignment reference, concession and status.

Programme hierarchy

Sections roll up to roads and roads to corridors and networks, so a figure reads correctly at whatever level it is asked for rather than only at the level it was entered.

Concessions & operating agreements

The agreement behind each road: the business entity holding it, the concession term, the obligations it carries and the milestone dates it commits to.

Milestones & schedule

Planned, revised and actual dates for each stage of a section, kept side by side, so slippage shows up as a difference instead of as an opinion.

Land acquisition

Acquisition progress recorded against the section it holds up, because on a road programme that is usually what the schedule is waiting for.

Physical & financial progress

Periodic progress against plan and against contract value, stored as a dated series rather than overwritten each time a new return arrives.

Investment & tariff records

Investment value, initial tariffs and later adjustments held against the road they apply to, together with the decision that set them.

Supervision history

Supervision entries, findings and the reports issued from them, kept with the section they concern instead of in the folder of the engineer who wrote them.

The working application

Where the agency enters, reviews and approves everything that reaches the database.

Programme overview

One screen for the whole programme: what is operating, under construction, in tender and in planning, with the road count and the kilometres behind each number.

Entry with validation

Forms that refuse the impossible at the point of entry: an actual date before its start, a section longer than its road, a progress figure that goes backwards.

Review & approval

A submitted figure is reviewed before it becomes the official one, so a working draft never turns into a published statistic by accident.

Bulk import of returns

Periodic returns from concessionaires and supervision consultants loaded from the formats they already use, validated as a batch, with rejects listed rather than quietly dropped.

Search across the programme

Find a road, section, concession or milestone from one box, including by the different identifiers separate teams use for the same piece of road.

Roles & audit trail

Who may see a figure, who may change it, who may approve it, and a stamped record of every change made after first entry.

Reporting

The outputs the agency is asked for, generated from the database instead of assembled from files.

Programme status reports

The standing status report produced on demand from current data, at section, road, corridor or national level.

Progress & slippage analysis

Planned against actual over time, with the sections driving a delay ranked at the top rather than buried in the middle of a table.

Recurring reporting packs

The formats the agency has to issue on a cycle, built as templates, so a monthly pack is a run of the report rather than a week of formatting.

Excel & PDF export

Every report exportable in the formats already circulated, with the underlying rows available when somebody wants to check a total.

How it ran

Twelve months, January to December 2025.

The data model came first and took the longest. On a programme database, whatever you get wrong in the schema you pay for again in every report built on top of it.

  1. January 2025

    Engagement & requirements

    Brought in through SMEC's transport practice, we started from the reports the agency is obliged to produce and who reads them, and worked backwards to the data those reports need, before designing anything.

  2. February – March 2025

    The Oracle data model

    Roads, sections, concessions, milestones and progress series, and the relationships between them, reviewed against real historical reports rather than against a diagram on a wall.

  3. April – July 2025

    Build

    The register, the entry and approval screens and the import paths, built in the agency's own terminology so that a field on screen matches the word used for it in a meeting.

  4. August – September 2025

    Migration & reporting

    Existing workbooks and historical records migrated in, then every standing report rebuilt on the database and reconciled line by line against the last version produced by hand.

  5. October – November 2025

    UAT & training

    Acceptance testing role by role with the people who own the numbers, then training and a written procedure for the periodic update and approval cycle.

  6. December 2025

    Delivery & handover

    Handed over on the agency's own Oracle infrastructure, documented down to the schema, the import formats and the reporting templates, so the system does not depend on us to be understood.

How it was built

Oracle, because that is where the data has to live.

The agency runs Oracle, so the database is Oracle, and the effort went into the schema and its constraints rather than into the framework sitting on top. Our founder holds Oracle certifications in Autonomous Database and Analytics Cloud, which is a large part of why this work came to us.

Database

  • Oracle Database
  • PL/SQL
  • Normalised schema
  • Dated history tables

Application

  • PHP
  • Laravel
  • Queued imports
  • Scheduled jobs

Reporting

  • SQL views
  • Materialised views
  • Excel export
  • PDF templates

Controls

  • Role-based access
  • Approval workflow
  • Audit tables
  • Referential integrity

Nothing is overwritten

Progress, dates and tariffs are stored as dated entries rather than as current values, so last quarter's report can still be reproduced exactly next year.

The schema refuses bad data

Relationships, ranges and sequences are enforced by constraints in the database, not only by the screens above it. A bad import fails instead of landing quietly.

Every figure traces to its source

Any number in a report can be followed back to the return it came from, the section it belongs to and the approval that made it official.

The outcome

A programme whose state can be read in one place.

How the work reached us

An Indonesian government programme, built from Dhaka.

CodeFix IT is a registered vendor of SMEC, the international engineering and consulting firm whose transport practice works on road and highway programmes across Asia. SMEC traces its origins to the Snowy Mountains Hydroelectric Scheme in Australia, has been part of the Surbana Jurong Group since 2016 and works in more than forty countries; it has been in Bangladesh since 1977 and has kept a Dhaka office since 1978. Being on their vendor register is how software work on their projects reaches us, and it is why a database for an agency in Jakarta was written by a team in Mirpur.

  • Registered vendor Pre-qualified on the consultancy's vendor register, under their engineering review rather than alongside it.
  • Delivered across borders Requirements in Jakarta, engineering supervision through SMEC, build and testing in Dhaka, on one agreed data model.
  • Reachable after handover The schema, import formats and reporting templates are documented, and we are available when a reporting cycle raises a question.
Is your programme still tracked in spreadsheets? Roads, plants, schools, grants: any programme with many projects at different stages has the same problem, and it is a data model problem long before it is a dashboard problem. Tell us what you are obliged to report on and we will tell you honestly what it would take.
Talk to us about it +880 1327-422480
Contact us

Have a project? Let's build it together.

Call us +880 1327-422480
Email us info@codefixit.com support@codefixit.com
Visit us

241/A 60 Feet Road, South Pirerbag
Mirpur, Dhaka 1216
Bangladesh

Scroll