In construction and contracting, information usually lives in three places: spreadsheets, messaging groups and the site manager's notebook. Has a subcontractor worker's safety certificate expired? How much rebar is left at the Kartal site? What did we pay for the same material last month? The answers exist, but finding them takes a chain of phone calls.

The Work Management Platform (İYP in Turkish) is a web application we built to bring that information into one system. This article explains what we built and why.

Scope: four jobs, one screen

  • Subcontractor documents: subcontractor workers' documents and whether they're cleared to enter the site. Workers with missing documents are flagged on the timesheet.
  • Site stock: stock, material consumption and cost per site.
  • Quote comparison: a new quote is instantly compared with past purchase prices for the same material.
  • Field reports: reports from a tablet, with photos and location.

We kept the scope deliberately narrow. Instead of an "ERP that does everything", a system that does well the four jobs that waste the most time on site.

Role-based screens

A site manager and a board member seeing the same screen makes both their jobs harder. In the platform, every user sees the screens for their role. The demo has seven sample accounts: company administrator, HR and administration, two site managers responsible for different sites, purchasing and warehouse, field staff, and read-only management.

Field staff enter reports on a tablet but can't edit them; a site manager only sees the sites they're responsible for; purchasing manages stock, suppliers and quotes; management sees read-only summaries. Permissions are enforced on the server, not in the interface, and part of the automated test suite checks exactly that: a role can't reach through the API what it can't see on screen, and one company's data is isolated from another's.

Timesheets, and making peace with Excel

On site, timesheets usually live in Excel and are copied into payroll by hand at month end. In the platform, the timesheet is a table per project and month: tap a cell to record the day (worked, leave, sick, overtime), or fill today for everyone at once. HR approves and closes the month; a closed month can only be reopened with a reason. At month end, an Excel export goes to payroll.

Rather than ignore Excel, we chose to work with it: employee and material lists can be imported from a ready-made Excel template. A preview is shown before import, and invalid or duplicate rows are left out.

Data and security

Subcontractor and staff records include sensitive fields such as national ID numbers and IBANs. These are stored encrypted; only authorised users can reveal them on the person's record, and every reveal is logged. Two-factor authentication is available at login. When a data subject request arrives, the person's details, documents, timesheets and a record of who accessed their data can be prepared as a single file. The company administrator can export all data as Excel and JSON at any time; the data belongs to the company, not the system.

A system that grows through tests

The platform has 138 API endpoints, and 269 automated tests run on every release. These numbers aren't a boast but a necessity: in areas such as stock, cost and document compliance, the price of a bug is paid on site. When a new feature is added, a machine checks every time that existing calculations still hold, so making changes stops being scary.

Why does the demo run in the browser?

The best way to explain business software is to let people use it. But you can't demo with real data, and setting up a server for every visitor is an unnecessary cost. So we built the platform demo (interface in Turkish) to run in the browser:

  • It uses the real interface; an in-browser demo API takes the place of the server.
  • The data is entirely synthetic: no real national ID numbers, IBANs or email addresses.
  • Each role logs in with one click and no password; "Reset demo" returns everything to its starting state.
  • Changes a visitor makes stay in their own browser.

This approach let us offer a fully working product experience even on ordinary shared hosting.

Lessons from this project

  • Start narrow. Picking the few jobs that waste the most time on site creates value faster than a broad but half-finished system.
  • Put the role at the centre of the design. A screen that shows everyone everything helps no one.
  • Enforce permissions on the server. Hiding things in the interface isn't security.
  • Write tests from day one. For calculations like cost and stock, automated tests are the only safe way to grow the system.