Crews.pay_model plus a rate field whose meaning changes with the model ($/hr, $/unit, lump $), a unit label for per-unit work, and the day-rate-only settings. The model drives what the field and sub portals capture and how the P&L prices actual labour.
Also called: hourly vs lump sum · cost plus · per unit pay · how do I pay this crew · pay model
- 1The crew card exposes Type (internal / subcontractor) and Pay model, with the rate label switching per model.
- 2day_rate_pool hides the single rate field entirely, because the pool is priced from the members' tiers.
- 3per_unit exposes a unit label — 'sq ft', 'square', whatever you measure in.
- 4The job P&L prices approved time entries by the crew's model: units x rate, hours x rate, or one lump per crew.
- 5The subcontractor portal renders its logging UI from the same model.
A builder does not pay every crew the same way — the framing crew is on day rates, the concrete sub is on a fixed bid, a labourer is hourly — and one company-wide pay setting forces most of them into a shape that does not fit. Each crew carries its own pay model, and that model decides what its portal captures and how its labour is costed. Crews are also either employees tracked in-house or subcontractors working through their own link, so both sit side by side on the same job without being made to look alike.
- Systems that assume a single pay arrangement for all labour.
- Rate fields whose meaning is ambiguous across models.
- Job costing that cannot price a lump-sum or per-unit crew.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →