FastBuild

Origin and problem

Construction work is distributed across sites, crews, shifts, and field conditions. A project manager needs reliable visibility into attendance, assigned work, daily activity, and workforce cost without forcing field teams into heavyweight desktop processes. FastBuild focuses on operational records that connect the jobsite to management workflows.

The current product direction is narrower than a general project scheduling suite: its public product and repository describe workforce and site operations, not a complete WBS, critical-path scheduler, or cost-control platform. Those broader project-management capabilities are not claimed here.

Product and domain model

Repository architecture describes companies as tenants, with tenant-scoped records, membership roles, and company context resolved per request. Product areas include construction sites and geofences, employees, check-in/out work sessions, tasks and attachments, payroll profiles/periods/entries, tax rules, reports, notifications, subscription entitlements, and offline/mobile work.

Domain boundaries

• Site presence and attendance are operationally sensitive and require trustworthy location and time records.
• Employee, work session, task, and payroll data cross several workflows; effective permissions depend on company membership and role.
• Payroll and tax calculations are market-specific. The repository explicitly distinguishes verified and unverified rule sources.
• Subscriptions and feature entitlements gate access, so billing state must not be confused with product data ownership.

Technical architecture

The documented backend uses Django 5.1 and Django REST Framework, JWT authentication, shared-database/shared-schema tenancy, Redis for selected rate-limit/token/queue functions, Celery integration, OpenAPI generation, and pluggable media storage. The frontend is React/Vite and exposes English, French, German, and Persian localization in the repository. Production deployments use separate market-specific application environments.

Authorization is layered through company membership, role claims, request company resolution, feature checks, and tenant-aware selectors/services. This is the documented design; it is not a security certification or substitute for an independent assessment.

Operational workflow

Site and crew setup → worker membership → attendance/task capture → supervisor review → reports and payroll preparation. GPS/geofence behavior and payroll outputs need market-aware validation; the user-facing product should disclose permissions and collection purpose.

Localization and commercial configuration

FastBuild has separate Canadian and Iranian product deployments with different authentication and billing contexts. Canadian-facing operation includes email login and Canadian payroll/tax domain work; the Iranian configuration uses mobile OTP and local billing/payment integrations. Currency, tax logic, SMS delivery, app-store distribution, and legal copy therefore belong to explicit market configuration rather than generic UI strings.

Mobile delivery and offline-related code exist in the current worktree, including Capacitor/Android artifacts. The inspected snapshot alone does not establish a complete store release or reliability envelope; those are separately gated release outcomes.

Validation and evidence

The 19 October dual-production acceptance report documents targeted backend/frontend checks and real-browser acceptance against both production-market applications for selected owner-demo flows, including health checks and media handling. It also records known limitations and a later market-aware payroll workstream. This is scoped evidence, not proof that every module, tax calculation, payment path, or mobile/offline mode passed end-to-end testing.

The public product site advertises field operations, task management, GPS attendance, and daily reporting. Marketing content is not used as proof for the technical implementation summary above.

Current limitations and trade-offs

• The worktree contains many uncommitted changes; HEAD and current working files are different states.
• Shared-schema tenancy depends on consistent filtering and authorization at every data-access path; a full isolation assessment is not established by the portfolio audit.
• Market-specific payroll/tax rules require traceable sources, effective dates, and explicit confidence labels.
• Mobile/offline code does not alone prove store distribution, conflict resolution quality, or reliable synchronization under field conditions.
• Payment integrations are not evidence of processed customer volume or commercial traction.

Role, outcomes, and lessons

My contribution centers on product framing, domain and platform architecture, multi-market requirements, and translating field workflows into a coherent operational product. The engineering lesson is that localization is not just translation: identity, payroll rules, payment rails, operational assumptions, and support models all vary by market.