Angga.
← Back to all works

KYDA Management Systems

Founding Engineer & Technical Lead (solo)

2024 — Present

Multi-tenant construction management platform

A multi-tenant SaaS for Australian construction firms to run projects end to end — work requests, scoping, estimation, quoting, scheduling, subcontractor work orders, and GST-compliant invoicing — across three role-based portals on a single Django API. Built and operated solo.

Construction SaaSDjango + DRFReact + TypeScriptMulti-tenant
KYDA — construction project management platform (preview placeholder).

The project

KYDA is a B2B platform that digitises how a construction business runs a project. A head contractor raises a work request, which becomes a project → site → job; each job breaks into classifications (Site Inspection, Scope of Works, Work Orders, Quotes, Invoices), and each classification holds assets and costed tasks. From that one model the platform drives estimation, quoting, subcontractor work orders, timesheets, RFIs, scheduling, milestones, and GST-compliant invoicing — surfaced through three distinct portals: a head-contractor admin, a client/owner portal, and a subcontractor portal.

I own this product end to end, alone — frontend, backend, infrastructure, and the roadmap itself. There's no separate platform team, no PM, and no QA function: when something needs designing, shipping, operating, or deciding, it's me. The discipline that makes that sustainable — clear service boundaries, standardised conventions, automated tests, and documentation written as I build — is as much the work as the features.

It's substantial for a solo build: 8 domain services, 85+ data models, and 190+ REST endpoints on Django 5 + DRF, backed by PostgreSQL, Redis, and Celery, with WebSocket real-time and S3-backed document storage. It's built for Australian tax and business rules (GST, ABN, public-holiday-aware scheduling) and operated for high availability via Docker and a GitHub Actions CI/CD pipeline.

What I shipped

  • Designed and built the entire platform single-handedly — three React + TypeScript portals and the Django + DRF API behind them — covering work requests, projects, sites, jobs, estimation, quoting, work orders, timesheets, RFIs, purchase orders, scheduling, and invoicing.
  • Built a GST-compliant estimation and invoicing engine: per-task costing (labour + material, margin, GST), draft/publish invoice snapshots with post-publish immutability, and server-rendered PDF quotes and invoices matching the Australian tax format.
  • Replaced an unreliable scheduling view with a real construction schedule: an MIT-licensed SVAR React Gantt wired to the timeline API (durations + precedence), plus a milestones calendar mirrored read-only into the client portal.
  • Shipped a decision-grade analytics layer: budget/spend/variance KPIs, a planned-vs-actual S-curve backed by a new time-phased actual-spend endpoint, a task-status donut, and a cost-by-trade breakdown.
  • Built an API-driven end-to-end test harness that provisions a full realistic project (every classification type, assets, tasks, work orders, quotes, invoices) and asserts money and flow correctness — it caught a GST bug before release.
  • Modernised authentication to PASETO, replacing long-lived DRF bearer tokens with short-lived, tamper-evident tokens to remove a class of token-replay risk.
  • Ran the infrastructure myself: Dockerised services, GitHub Actions CI/CD, an application-level Redis cache over the hottest reads, cloud cost monitoring, security reviews, and an architecture upgrade toward high availability.
  • Authored the documentation — technical overview, architecture notes, API and data-model references, and the end-to-end test playbook — so the platform is legible and operable, not just running.

How it works

One data model, three portals

Challenges worth talking about

Being the entire engineering org

No platform team to lean on, so I engineered for a team of one: eight focused Django apps, standardised API and Redux data-flow conventions across all three front ends, Postgres triggers (pghistory/pgtrigger) for an automatic audit trail, and docs written as I built. That discipline is what makes solo ownership of 85+ models and 190+ endpoints sustainable rather than fragile.

Money has to be exactly right

Invoicing is GST-regulated and customer-visible, so 'close enough' isn't acceptable. The end-to-end harness flagged a GST-free task still being charged $240 of GST on a published invoice — line-item snapshots weren't carrying the gst_free flag, so the publish-time rounding re-applied 10%. I fixed it across every code path that creates or updates a line item; the suite then confirmed the corrected total ($11,927.30 → $11,687.30). A revenue/compliance bug caught before any customer saw it.

A faithful schedule without a paid dependency

The schedule was rendering on a broken calendar component. I deliberately chose the MIT-licensed SVAR React Gantt over a visually similar GPL library to keep the codebase license-clean, then wired it to the timeline API (durations + precedence) for a real critical-path view — and extended the same data into a construction S-curve that merges planned cumulative value against actual invoiced spend on one time axis.

Decision-grade analytics on race-prone shared state

The dashboards rendered blank intermittently. I root-caused a data race: three concurrent fetches wrote the same Redux task store, and one passed the wrong identifier and resolved last with an empty result — silently wiping the data the charts depended on. I removed the offending call, made the analytics view re-hydrate defensively, fixed the field-mapping bugs, and the dashboards now render correct data deterministically.

Secure, cheap, and always up — alone

Reliability and cost are my problem too. I moved auth to PASETO, added a Redis cache over the hottest read paths, set up cloud cost monitoring and trimmed spend through right-sizing and caching, ran regular security checks, and drove an architecture upgrade toward high availability — containerised services with a repeatable GitHub Actions pipeline so deploys are recoverable.

Stack

Backend

  • Django 5
  • Django REST Framework
  • PostgreSQL
  • Celery + Beat
  • Django Channels (ASGI)
  • Gunicorn + gevent

Frontend

  • React 18
  • TypeScript
  • Vite
  • Redux Toolkit
  • Tailwind CSS
  • Tremor + Recharts
  • SVAR React Gantt

Auth & security

  • PASETO
  • dj-rest-auth + allauth
  • pghistory / pgtrigger audit trail

Caching & real-time

  • Redis (cache + broker + channels)
  • WebSocket notifications

Docs & storage

  • AWS S3 (django-storages)
  • ReportLab + pdfkit
  • react-pdf

Cloud & ops

  • Docker + Compose
  • GitHub Actions CI/CD
  • Cost monitoring
  • AU GST / holiday rules

Outcomes

  • Single-handedly delivered and operate an entire multi-tenant construction platform — 3 portals, a Django API of 85+ models and 190+ endpoints, infrastructure, and product direction.
  • Built a GST-compliant invoicing engine and an end-to-end test harness that caught a revenue-impacting tax bug before release.
  • Hardened authentication by migrating to PASETO, eliminating long-lived-token replay risk.
  • Cut cloud spend ~35% through cost monitoring, right-sizing, and a new Redis caching layer.
  • Reduced hot-path API latency ~40% by caching the heaviest job, estimation, and timeline reads.
  • Drove an architecture upgrade toward high availability, targeting 99.9% uptime with containerised, repeatable deploys.
  • Documented the platform end to end, keeping a solo-owned system legible and operable.