Quote Goat Platform Program 2027

Build order: 1 of 11 priced epics (on-ramp from the Sept 1, 2026 estimating pilot)

Delivery window (proposed): Q4 2026 – Q1 2027

What Kelso gets

Bidding across OpCos becomes a decision backed by data: Before estimating hours are spent on an opportunity, management gets a scored recommendation with the history to back it up - how bids like this one have gone and what the won ones actually earned.

In scope

• Go/no-go scoring (informed by the working concept demo)
• Configurable scoring criteria (e.g., customer history, project type, region, margin potential, bonding, resource availability) with weights and thresholds
• Per-OpCo scoring models: Each OpCo maintains its own criteria and weights, or shares the enterprise model
• Score captured on the opportunity/bid record; go/no-go recommendation with override + reason capture
• Go/no-go decision log and history
• Every go and no-go recorded with who decided, when, score at decision time, and a reason code + notes on no-gos (reason codes configurable: Workload, margin, customer risk, bonding, geography, …)
• Decision history sliceable by customer, region, project type, estimator, OpCo - "we declined to bid this customer 4 of the last 6 times, and here is why"
• Decision-point context panel (shown while making the go/no-go call)
• Win rate for similar bids (same customer / region / project type)
• Bid margin on won AND lost bids - what we priced work at when we won vs. lost
• Actual margin on won jobs vs. what was bid - closes the loop from estimate to reality. Data note: Bid-vs-bid history accrues in QG from the pilot forward; actual job margin arrives via the NetSuite cost feed (feature 4 Live Cost).
• Bid pipeline hardening (POC → production)
• Win/loss analytics by customer, PM, estimator, project type, region
• Quadrant/ROI view; backlog & forecast
• Multi-OpCo filtering, permissions-aware views, saved views, CSV/Excel export

Ideas worth considering (priced options, not in base - see Priced options for this feature)

• Expected value of bidding: score-implied win probability × typical margin for this segment, minus the predicted cost to produce the estimate - a single "is this bid worth the estimating hours?" number
• Estimating capacity check: show current estimating backlog/committed bid hours vs. the bid's due date at decision time - a no-go for workload reasons becomes visible instead of anecdotal
• Similar-bid lookup: side-by-side view of the 3–5 most comparable past bids

Out of scope (this epic)

• AI-suggested scoring or document-driven scoring (future/AI roadmap)
• CRM automation beyond what exists today
• External data enrichment (credit, market data)
• Formal multi-step approval workflow on the go/no-go decision (a priced option, see Priced options for this feature)

Existing assets this builds on

• Production-grade bid pipeline analytics, CRM + saved views/dashboards plumbing (this epic hardens them); go/no-go scoring is a new build informed by the concept demo
• CBS/estimating core is live product - no estimating-engine work in this epic

Build order: 2 of 11 priced epics

Delivery window (proposed): Nov 2026 - Mar 2027

Depends on: estimating core (live); Kelso's MuleSoft integration for NetSuite updates (the Feature 5 model)

What Kelso gets

Change orders priced the same way the job was bid - from the same CBS structure and resource library - instead of one-off spreadsheets. Every CO carries its cost buildup, its markup, and its approval trail, and approved COs roll into the revised contract value and budget automatically.

In scope

• CO creation from the project CBS
• Add, modify, or credit CBS lines using the same resource library, productivity factors, and rate hierarchies used at bid time
• CO-level pricing: Markup/margin rules, lump-sum vs. unit-price presentation
• Per-OpCo markup rule sets: Each OpCo maintains its own markup configuration, with an admin UI to manage them
• CO lifecycle
• Statuses: Draft → priced → submitted → approved / rejected / void, with dates, owners, and notes at each step
• Revised contract value and revised budget math: Approved COs roll up into project totals; original vs. revised always visible
• Schedule impact captured as an entered value on the CO (days and notes); dynamic linkage to the feature 9 schedule is a priced option
• CO register
• Per-project CO log (number, description, status, submitted/approved dates, value), filterable and exportable - the view a PM brings to an owner meeting
• Print-quality owner-facing CO packages on each OpCo's letterhead
• Approved-CO data feed for NetSuite
• On approval, Quote Goat exposes the revised budget and contract values through the documented API, with an approval trigger event, for Kelso's MuleSoft integration to carry into NetSuite. Same integration model as Features 4 and 5: Quote Goat provides the data and the documentation; the NetSuite-side update is built by Kelso's team with Feature 5 support.

Out of scope (this epic)

• Owner-facing CO portal or e-signature routing (priced options, see Priced options for this feature)
• Building or operating the transport into NetSuite itself (Kelso's MuleSoft, per the program integration model)
• Subcontractor change orders / flow-down COs (future phase)
• T&M ticket capture in the field that converts to a CO - the capture side arrives with feature 7 (mobile); the conversion is a priced option (see Priced options for this feature)

Existing assets this builds on

• CBS grid, resource library, rate hierarchies, live margin recalc (all live product)
• Documented API surface and background-job infrastructure (live product)

Build order: 3 of 11 priced epics - deliberate prerequisite for the mobile app (feature 7)

Delivery window (proposed): Q4 2026 - Q1 2027

Depends on: project CBS (live)

What Kelso gets

Production quantities recorded directly against project CBS lines from the desktop - the structure the mobile app will later feed into. Percent complete stops being a gut-feel number: It's installed quantity against budgeted quantity, line by line.

This replaces the 2026 interim (weekly SharePoint extract → NetSuite statistical journals) with production data living where the budget lives.

In scope

• Trackable CBS lines
• Flag CBS lines as production-tracked with unit of measure and budgeted quantity (Kelso's 7–8 UoMs: Pounds, linear feet, weld inches, etc.)
• Desktop quantity entry
• Grid-based batch entry: Quantities installed by date/period against CBS lines, with validation (over-100% warnings, locked periods), edit history and audit trail
• Crew/foreman attribution on entries: Who installed it, recorded with each entry
• Photo attachment on desktop entries
• Percent complete + production math
• Installed vs. budgeted quantity per line; earned quantity rollups to cost codes and project level; required-production-rate-to-finish per line
• Production views
• Per-project production dashboard: Installed vs. budget, period trend, lines at risk (rate needed exceeds rate achieved), export

Out of scope (this epic)

• Mobile/field entry - that is feature 7, landing on this foundation
• Labor-hours-per-unit productivity analysis tied to timekeeping (future; Kelso timekeeping module is deferred)
• Automated ingestion from the current Power Apps / SharePoint process (the interim path stays NetSuite-side in 2026; loading prior production history is priced separately, case by case)

Existing assets this builds on

• CBS data model with quantities/UoMs at the resource line level (live product)
• The batch-entry grid patterns proven in estimating
• 2026 NetSuite stat-account interim defines the field-proven UoM list and cadence

Build order: 4 of 11 priced epics

Delivery window (proposed): Q2-Q3 2027

Depends on: feature 5 mapping decisions; Kelso's MuleSoft feed (Kelso-delivered)

What Kelso gets

NetSuite cost transactions flowing into Quote Goat on a scheduled hourly cycle, so the platform shows live budget vs. actuals on the same CBS the job was bid and is being produced against. Actuals also feed backward into estimating intelligence (feature 1's "what did won jobs really earn" panel).

Integration model (important): Kelso builds and operates the NetSuite→QG feed on their MuleSoft platform, consistent with their other integrations. Quote Goat provides the receiving API and support (feature 5). This epic is the QG side only.

In scope

• Transaction ingestion API
• Authenticated endpoints accepting transaction create/edit/delete events from Kelso's middleware; duplicate-safe processing, protection against out-of-order events, and a holding queue with replay for anything that fails; ingestion monitoring dashboard
• Transaction layer
• Quote Goat transaction records mirroring what NetSuite sends: Transaction type (vendor bill, credit card, journal, expense report, check), the vendor or employee behind it, date, amount, and source reference. Cost detail lives in the platform, so reporting can slice by vendor, type, cost code, or period
• Transaction placement
• Transactions land against the QG project and cost breakdown automatically where the coding allows; anything that cannot be placed automatically queues in a review workbench for a human decision, so nothing silently disappears
• Cost storage + aggregation at scale
• Transaction store sized for Kelso reality (hundreds of budget lines, tens of thousands of transactions per large job); pre-aggregated rollups so screens stay fast
• Budget-vs-actuals views
• Project cost screen: Budget, actual, remaining by CBS cost code and line; drill-down from cost code to transaction detail; period filters; export
• Feed to estimating intelligence
• Actual job margin surfaces in feature 1's decision-point context panel

Out of scope (this epic)

• Backfill of NetSuite cost transactions - explicitly excluded. New projects only. Cost data flows for projects that go live in QG from cutover forward. Loading past transactions would require a separate bulk-load path plus data cleanup. If ever wanted, it is a separately scoped project.
• Purchase orders and committed cost - explicitly qualified out. The feed carries posted actuals only; PO lifecycle handling and no-double-count reconciliation is a second data domain. Pre-scoped as a separately scoped project (600 hrs) if Kelso ever wants it, but it is not part of this program
• The MuleSoft integration itself - Kelso-delivered (feature 5 covers QG's support)
• Writing anything back to NetSuite (one-way feed, NetSuite stays system of record)
• Forecasting/cost-to-complete in QG - the Financial Forecast module on NetSuite is the 2026 answer; a QG-native forecast is a future phase
• WIP/revenue recognition math (stays in NetSuite/BCP)

Existing assets this builds on

• Import-side background-job infrastructure (worker, staging storage, job tracking), which this epic extends for inbound events; the ingestion API, transaction layer, review workbench, and monitoring are built new in this epic

Build order: runs alongside feature 4 (same delivery window)

Delivery window (proposed): Q2-Q3 2027, alongside feature 4

The model

Kelso builds and operates the NetSuite→Quote Goat integration on MuleSoft, their established middleware platform, the same way they've delivered other integrations. Quote Goat's role is to make that easy: A documented, stable API surface and expert support during mapping and testing.

This is priced the way a mature platform prices connector enablement - a small, bounded support line, not a build.

In scope (QG-side support)

• API documentation package - endpoint reference, event schemas, auth setup, error codes, duplicate-handling rules, sandbox connection guide
• Field-mapping workshops - working sessions with Kelso's integration team to map NetSuite records/fields to QG's transaction schema and cost-code structure
• Sandbox support - QG sandbox tenant + credentials, test data, and turnaround on questions during Kelso's build
• First-sync validation - joint verification that an agreed test set of NetSuite transactions lands correctly in QG (counts, amounts, mappings) before production cutover

Explicitly Kelso's responsibility

• The MuleSoft flows: Development, error handling on their side, scheduling/eventing, production operations and monitoring of the pipe
• NetSuite-side configuration (saved searches/SuiteQL or event sources feeding MuleSoft)
• Ongoing maintenance when NetSuite customizations change upstream data shapes

Boundary rule (for the SOW)

Support hours cover enablement of the integration as designed in the mapping workshops. Debugging inside Kelso's MuleSoft flows or NetSuite configuration is billable beyond the included hours - the line that keeps "support" from quietly becoming "build."

Build order: 6 of 11 priced epics - before mobile (feature 7), so mobile has a place to land daily reports

Delivery window (proposed): Q1-Q2 2027

What Kelso gets

Project document workflows living on the platform: RFIs, submittals, and daily reports with photos and notes.

Continuity: these workflows exist today on NetSuite infrastructure in Kelso's sandbox and are moving to NetSuite production as the 2026 interim. This epic rebuilds the same functionality on Quote Goat infrastructure - the interim proves the workflows and trains the teams; the QG build is the permanent home. Nothing learned is thrown away. The functional spec is the NetSuite interim as documented in the joint baseline dated at contract signing; changes made to the interim after that baseline are scoped as additions.

In scope

• RFIs
• Create, assign, route, respond; status and ball-in-court tracking; due dates and aging; RFI log per project with filters and export; attachments
• Email-in / email-out workflow: RFIs go out by email and recipients respond by replying; inbound replies are parsed onto the RFI thread with their attachments
• Submittals
• Submittal register; revision cycles (rev 0, 1, 2…); review statuses (approved / approved-as-noted / revise-and-resubmit); lead-time visibility; attachments
• Daily reports
• Structured daily entry: Crew/headcount, weather, work performed, delays/issues, photos and notes; per-project daily log, searchable history
• Core services (built once here, then applied to every feature as it emerges)
• File/photo attachment service (cloud storage, thumbnails, previews)
• Core email service: Templated delivery with per-user routing, used by every feature's notifications from here forward
• Core notification service + consolidated notification center: Triggers (assigned, due, overdue, response received) landing in one inbox-style feed with read/unread state and per-user preferences (what to be notified about, in-app vs. email). New features plug their events into this same service as they ship. Mobile push arrives with the feature 7 app
• Print/PDF output for RFIs and daily reports (send-to-owner format)

Out of scope (this epic)

• Mobile entry - feature 7 adds phone-based daily reports and photos on this foundation
• External-party portal (the design team answering RFIs inside QG without a seat) - a priced option; external parties receive RFIs by email and their replies are captured by the email-in workflow above
• Transmittals, drawing management, full document control - delivered by feature 11 (document management)
• Migration of in-flight NetSuite RFI/submittal records - out of scope; records open on the interim run to completion there

Existing assets this builds on

• The NetSuite sandbox build = a validated functional spec (fields, statuses, routing)
• Basic file storage and task attachments exist today; the shared attachment service (thumbnails, previews, tenant-scoped storage) is built in this epic
• QG task management's assignment/watcher/notification patterns

Build order: 7 of 11 priced epics - lands on feature 3 (production units) and feature 6 (daily reports)

Delivery window (proposed): Q2-Q3 2027, overlapping the tail of feature 3 and feature 6

Depends on: feature 3 (units model), feature 6 (daily reports + photo service)

What Kelso gets

Foremen and superintendents working from their phones: Units complete recorded against CBS lines, photos from the field, and daily reports filed the day they happen - all landing in the same structures the office already uses.

Sequencing note (deliberate): the desktop foundations ship first so mobile data has somewhere to land. In practice, mobile development overlaps with feature 6 - but the dependency direction is real: Mobile is a client of the units and daily-report models, not a separate system.

In scope

• Mobile app on the app stores (one web codebase inside a native shell)
• Phone-first UI, login, project selection, role-aware navigation
• Delivered through the Apple App Store and Google Play from day one; public listing or Apple Business Manager private distribution is Kelso IT's call, and either way the app is manageable through your device-management (MDM) tooling
• Store accounts, listings, privacy declarations, signing, build pipelines, and review cycles are all in this feature's scope
• Push notifications
• Real push on iPhone and Android (the Apple and Google push services), wired to the feature 6 notification services and the consolidated notification center
• Spanish-language field UI
• The field surfaces ship in English and Spanish from day one
• Units-complete capture
• Pick a CBS line (or a foreman-friendly filtered list), enter quantity installed and the date; the foreman sees budgeted quantity and installed-to-date for context (feature 3 model)
• Photo capture
• Native camera capture with compression and background upload; photos attach to daily reports and production entries (feature 6 photo service)
• Best-practice photo policy included: Photos are compressed on capture for upload, full quality is preserved in cloud storage, and photos are retained for the life of the project with archive export at closeout
• Daily report (mobile flow)
• The feature 6 daily report as a fast, thumb-friendly flow: Crew count, weather auto-fill, work performed, delays, photos, submit
• Field-network resilience
• Graceful behavior on weak connections: Queued submits with retry, draft preservation - short-interruption tolerance, not full offline

Delivered separately, in the program

• True offline capture is feature 8 (feature 8, 200 hrs, $30,000): Full offline-first operation - work all day with no signal, sync at the truck. It is an architecture upgrade (local store, sync engine, conflict resolution), which is why it is its own epic rather than folded into this one. This epic delivers short-interruption tolerance; feature 8 delivers the zero-signal workday.

Out of scope (this epic)

• Timekeeping from the field (Workday covers it, per Kelso)
• RFIs/submittals authoring on mobile (view-only is a priced option, see Priced options for this feature)

Existing assets this builds on

• feature 3 production model, feature 6 daily report + attachment service, QG auth/roles

Build order: Feature 8 of 11; follows the mobile field app (feature 7) and extends it

Delivery window (proposed): Q3-Q4 2027

Depends on: feature 7 (mobile app shell, units capture, daily reports, photo service)

Start: begins when feature 7 meets its agreed pilot exit criteria. If feature 7's pilot moves, this window moves; the scope and price do not change

What Kelso gets

A full workday with zero signal. Plants, mechanical rooms, basements, and remote sites are where Kelso's crews work, and they are also where phones lose coverage. With offline mode, a foreman opens the app in the morning, works the full day without a connection, and every entry captured offline is queued durably and synchronized when connectivity returns. Nothing is re-keyed from paper, and conflicts are surfaced for review rather than silently overwritten.

Why offline is an architecture change

The base mobile app (feature 7) tolerates short signal drops: It queues a submit and retries. True offline is a different architecture, because the phone must become its own small system of record for the day:

• The data has to already be on the phone. Working offline means the app cannot ask the server anything. Each user's projects, CBS lines, budget quantities, form templates, and open daily report must be stored on the device and refreshed whenever there is signal, scoped tightly so a phone is not syncing the whole company.
• A sync engine, not a retry loop. A day of work is hundreds of entries and photos. The outbound queue must survive the app being killed, the phone rebooting, and the battery dying, then resume mid-sync with server-side deduplication and resumable upload when signal returns for ninety seconds in the yard.
• Conflict resolution. Two foremen offline on the same crew can both record quantities against the same CBS line, or edit the same daily report. "Last one wins" silently destroys data. Quantities need merge rules (two entries become two entries, not one overwriting the other), and true collisions need a review queue a human can settle.
• Photos at job-site volume. A day of offline photos is gigabytes on a phone. Local storage has to be managed (compression, caps, cleanup after confirmed upload) so the app never fills the device, and upload has to run in the background without burning the battery.
• Security while disconnected. Login tokens expire during an offline day. The app needs a secure local session that keeps working, then re-authenticates and syncs without losing the day's work, while keeping the device data encrypted in case the phone is lost.
• Trustworthy records. Every offline entry carries when it was really captured (not when it synced), survives incorrect device clocks, and lands in the same audit trail as online entries.

In scope

• On-device data store with per-user project scoping and freshness refresh
• Durable, resumable, restart-safe sync engine with server-side dedup
• Conflict rules for quantities, daily reports, and forms + a review queue for true collisions
• Offline photo management: Local storage caps, compression, background upload
• Offline-safe authentication and encrypted local storage
• Capture-time audit metadata end to end
• Field pilot under real conditions (airplane mode all day, sync at the truck)

Out of scope (this epic)

• Offline for desktop/office screens (field capture only: Units, daily reports, photos, form fill, checklist runs when feature 10 lands)
• Peer-to-peer sync between devices with no server
• Offline drawing/document viewing (documents are feature 11, now in the program; taking drawing sets offline is a priced option, see Priced options for this feature)

Build order: 9 of 11 priced epics; runs in unison with feature 4 live cost (they do not build on each other)

Delivery window (proposed): Q2-Q3 2027, with live cost

Depends on: CBS (live); benefits from feature 3 production data for progress-vs-plan

What Kelso gets

Scheduling on the same structure the job was bid and is being produced against: A Gantt built on the CBS, a master schedule per project, and the working rhythms crews actually use - weekly SIPs and the three-week look-ahead.

(2026 interim: BCP scheduling on NetSuite is already licensed and in use. This is the platform-native replacement, arriving last by design - after cost and production data are live so the schedule reflects reality.)

In scope

• Schedule model on the CBS
• Activities linked to CBS lines; durations, dependencies (finish-to-start + lags), milestones; baseline capture and current-vs-baseline
• Gantt view
• Interactive Gantt: Drag to move/resize, dependency lines, critical path, zoom levels (day/week/month), print/export
• Master schedule + weekly SIPs
• Project master schedule view; weekly Short-Interval Plan: This week's commitments by crew/area, carried-over items visible
• Three-week look-ahead
• Rolling filtered view of the next three weeks; mark constraints/blockers (material, access, design) so the look-ahead meeting runs from the system
• Schedule import
• One import format, selected at design time (MS Project XML unless agreed otherwise); each additional format is a priced option
• Progress vs. plan
• Where activities map to production-tracked CBS lines (feature 3), percent complete flows onto the schedule automatically

Out of scope (this epic)

• Resource-loaded scheduling / manpower leveling - deliberately kept to what field teams use; enterprise resource planning is on the deferred list
• P6/Primavera bi-directional sync (a priced option; one-way import only in base)
• Multi-project portfolio scheduling views (a priced option, see Priced options for this feature)

Existing assets this builds on

• CBS hierarchy (the schedule's backbone), durations on resource lines from estimating, feature 3 production percent-complete

Build order: 10 of 11 priced epics; lands late in the year on the mobile and quality foundations

Delivery window (proposed): Q3-Q4 2027

Depends on: feature 6 (attachment service); core permissions from the platform investment (the platform foundation); mobile flows land in the feature 7 shell

What Kelso gets

The project quality workflow, end to end: Checklists run against the work, issues are tracked to closure, every job-site photo is searchable in one place, and Kelso's five field forms are delivered ready to use on day one.

The forms model: BlueCollar builds Kelso's five forms from Kelso's own library (daily safety sign-off, T&M documentation, equipment inspection, near-miss/incident, daily production sign-off) as standardized forms on a lean runtime. New forms are added through small change orders. A self-serve builder, where Kelso admins design their own templates, is pre-scoped as a separate on-request item targeting this same runtime.

Reuse note: Photo storage and capture plumbing already exist in features 6 and 7 and are not rebuilt here. This feature adds the quality objects (checklists, issues), the form runtime with the five forms, and the photo log aggregation on top of those services.

In scope

• Best-practice field forms
• Lean form runtime: Fill and submit on desktop and in the feature 7 mobile shell, validation, per-form submission log with counts and export, PDF output per submission
• Kelso's five forms built for them, including signature capture and photo fields where their library uses them
• Checklists
• BlueCollar-authored checklist templates on the same runtime: Items with pass / fail / N/A, notes, and photo evidence per item
• Checklist runs assigned to areas, CBS lines, or equipment; completion tracking per project; failed items spawn issues automatically
• Issues / punch list
• Create an issue from anywhere (checklist failure, daily report, photo, or directly); assign with due date; status lifecycle open → in work → ready for review → closed, with ball-in-court
• Photos and notes on every issue; per-project issue log with filters, aging, and export; close-out report for turnover
• Photo log
• One project-wide gallery aggregating photos from daily reports, production entries, issues, checklist items, and form submissions
• Filter by date, source, area/CBS line, uploader; tap through to the record the photo came from; bulk download for claims/close-out

Out of scope (this epic)

• The self-serve forms builder (Kelso admins designing new templates) - pre-scoped as a separate on-request item
• Commissioning workflows (system/equipment cert chains) - stays on the deferred list
• AI photo analysis or auto-tagging (future/AI roadmap)
• Owner-facing punch list portal (external access is priced under feature 6's external-party option)

Existing assets this builds on

• feature 6 attachment service (photo storage, thumbnails) and core notification/email services; feature 7 mobile shell for field capture; the platform's existing role machinery (roles created and assigned feature permissions today), extended per feature as core product

Structure: three tiers, all in the program. Tier 2 prices ONLY the additional work beyond Tier 1; Tier 3 prices ONLY the additional work beyond Tier 2.

Build order: feature 11 of 11 by number, but it delivers early: Tier 1 lands alongside feature 6 (RFIs and submittals attach to documents), Tier 2 lands before the mobile app (the field drawing viewer rides inside it), Tier 3 follows.

Delivery window (proposed): Q2-Q4 2027, tiers in sequence

Spec source: "Files & Documents" in Kelso's own Field Ops mockup. On the 2026-08-05 call, drawings and specs on a foreman's phone were named a top field priority ("a huge time save"), and contracts storage in permissioned folders was requested.

Tier 1 - Files, Versioning & Permissions (400 hrs · $60,000)

The foundation: Project documents living on the platform instead of scattered drives.

• Project folder structures (templated per project type, admin-managed)
• Upload/download, drag-in, bulk upload; file preview for common types
• Spec books, contracts, and subcontracts stored as ordinary documents in permissioned folders (requested on the 2026-08-05 call)
• Version history: New versions stack on the same document, prior versions retained and downloadable, "current" always unambiguous
• Role-based access using the core permission model (who sees/edits which folders), including a folder-level flag for whether a folder is visible on mobile at all
• Search and filter by name, type, folder, uploader, date
• Builds on the feature 6 attachment service (cloud storage, thumbnails, previews)

Tier 2 - Drawing Management (adds 275 hrs · $41,250)

Additional work only; requires Tier 1.

• Drawings tracked individually: Sheet number, title, discipline, revision
• Revision control: New rev supersedes prior automatically; current-set view vs superseded history; rev clouds noted per upload
• Drawing list/log per project, filterable by discipline and status
• Field-friendly drawing viewer, shipping inside the store-delivered mobile app (feature 7): A foreman opens the current set on a phone without walking back to the trailer

Tier 3 - Markups & Transmittals (adds 250 hrs · $37,500)

Additional work only; requires Tiers 1-2.

• PDF markup and annotation: Pens, shapes, text, stamps; markups saved as layers per user, sharable without altering the base document
• Transmittal packages: Group documents/drawings into a formal transmittal with recipients, cover sheet, and a send log (what was sent to whom, when)
• Transmittal history per project; re-send and superseded-notice support

Out of scope (all tiers)

• CAD/BIM model viewing (PDF-based drawings only)
• External-party accounts for receiving transmittals (delivered as email + PDF; external write access is priced under feature 6's external-party option)
• OCR/auto-extraction of sheet numbers (a priced option, see Priced options for this feature)
• RFIs pinned on drawings (view-only overlay raised on the 2026-08-05 call; a priced option, see Priced options for this feature)
• Offline drawing sets on the phone (a priced option on feature 8)

What this is: The self-serve builder itself, pre-scoped for the day Kelso wants to create new forms without asking. Admin and permissions are core platform; Kelso's five best-practice forms are delivered by feature 10.

If purchased: A fast-follow once feature 10's forms are in daily use.

What this would add

Kelso admins designing their own form templates without a developer: Sections and fields with required flags and defaults, the full field palette (text including auto-populated, number, yes/no, multi-select, photo, signature, date, dropdowns from lists), template versioning so edits never corrupt past submissions, and publish/retire.

What Kelso already has without it

• The five best-practice forms from their own library, built for them in feature 10 on the same runtime this builder would target (new forms arrive as small change orders in the meantime)
• Checklists, issues, and the photo log (feature 10)
• Roles, permissions, and the admin console as core product (the platform foundation, BlueCollar's investment)

Out of scope (if purchased)

• Conditional form logic (branching, show/hide, calculated fields) - a further priced option
• Approval routing on submissions - a further priced option
• A dedicated safety management module - a third-party product, outside the platform's scope. The forms capture safety forms as forms

Build order: continuous through 2027, front-loaded before feature 7 (mobile)

Price to Kelso: $0 - this is BlueCollar's investment in the platform Kelso runs on

What this is

Everything Kelso's scope requires from the platform itself, built and carried by BlueCollar as the product owner. It appears in this proposal at zero deliberately: It shows what the subscription and the partnership carry, and that the feature prices above are not padded with platform overhead.

What BlueCollar is investing in (2027)

• Roles, permissions, and enterprise admin as table stakes - the platform's role machinery exists today (roles created and assigned feature permissions); BlueCollar seeds the field role templates (PM, superintendent, foreman, view-only), builds project-level access control and the admin experience, and extends permissions to each new feature as it ships. Core product, never a Kelso line item
• Security hardening - ongoing hardening ahead of field and mobile expansion, including Kelso's isolated tenant
• Production launch infrastructure - production email delivery, monitoring and alerting, automated post-deploy checks, tenant provisioning
• Multi-tenant performance - caching, query performance, and event architecture that keep Kelso-scale data fast
• Platform operations - AWS environments, storage, backups, security posture, and architecture
• QA infrastructure - automated regression coverage run on every release

Why it's shown at $0

If Kelso commissioned this platform as custom development, work of this class would run to thousands of hours on the invoice over the life of the program. It is not on the invoice because BlueCollar owns the product and carries the platform: Kelso pays for Kelso features, and BlueCollar pays for the platform they run on.