All projects
Backend Engineer — Python/Django & LLM Pipelines2022

Construction Subcontractor Portal

Multi-company construction portal for Senseit (now predictIT), where I built the document register, the activity planning module, and the access rules between companies.

DjangoDjangoPythonPythonMySQLMySQLAzureAzure BlobDockerDockerCeleryCelery

At Sirin Software I worked on SC Portal for Senseit, now predictIT, a Dutch software company working with clients in construction and infrastructure. SC Portal was a multi-company portal where a customer, a main contractor, and subcontractors planned work and exchanged contractual documents. My contributions were the document register, the project and activity module, and the access rules between companies.

A document register companies can share without oversharing

I built the register’s models and flows: a base document with version, release reason, release date, and releasing user, plus deliverable and acceptance-plan variants that carry the metadata QA needs at handover. Create and update views handle file replacement. Uploads go to Azure Blob through a UUID-keyed file record, and a failed database write removes the uploaded blob, so the register never points at a missing file. Lists use DataTables with row-level detail.

For the business this replaces the usual email-and-attachments handover with a register that has an explicit audience. A main contractor publishes a document to exactly the organizations that need it, and the release metadata keeps an audit trail of what was delivered and when.

Access rules for multi-company projects

I implemented the permission layer across the project, document, and organization views: three organization kinds (customer, main contractor, subcontractor), projects shared with selected organizations through an access list, and a database constraint that keeps an account’s role consistent with its organization membership.

That layer is what makes the multi-company model viable. Subcontractors work in the same project and see only the activities they are responsible for, filtered by design, supplies, or execution, while the main contractor keeps the full picture. Customers and subcontractors cannot create or edit the plan.

Planning work across company boundaries

I built the milestone, work package, and activity models and their forms and views: activity categories, statuses, a priority field validated both in the form and with a database check constraint, and dependencies between activities. The dependency editing was the interesting part: two sortable lists in the activity form, the chosen order submitted as JSON and stored on the link model, rewritten on update, with validation errors returned as JSON so the form shows them inline.

The goal was to let a main contractor communicate sequence and responsibility in the system instead of a spreadsheet, and let each subcontractor report status only on its own scope.

Delivery work

I set up the Docker Compose configurations for local, demo, and test runs, added gettext to the images, wrote the translation workflow docs, started the npm and webpack pipeline, and prototyped Celery for background jobs. The test configuration runs MariaDB on a ramdisk, so the suite doesn’t touch development data. The demo configuration gave the team a repeatable environment to run the portal for reviewers.