Kalzar 🛠️

• Configurable, modular work-management software.
• Configure each setup around the organization’s workflow.
• Enable modules as needed and refine them through feedback.
• The initial areas below are starting specializations.

Initial areas of specialization

Construction financial tracking

• Track:
  • Contracts
  • Schedules of values
  • Payment applications
  • Subcontractors
  • Payments
  • Earned, requested, approved, retained, and paid amounts
• Support payment applications to an owner / general contractor and applications received from subcontractors.
• Keep work completion, payment requests, approvals, and actual payments distinct.

Equipment maintenance

• Maintain shared equipment records.
• Track:
  • Maintenance schedules
  • Service and repair history
  • Availability
  • Downtime
• Keep information synchronized for authorized users.
• Make responsibility and equipment status clear.

Dumpster scheduling and dispatch

• Track dumpster availability and status.
• Coordinate deliveries and pickups.
• Assign jobs, people, vehicles, and other related resources.
• Surface scheduling conflicts where useful.

Product direction

• Kalzar remains a modular product intended to support the specializations above.
• The current demo replaces the previous demo workflows with a focused construction progress-billing / payment-application workflow.
• Equipment maintenance and dumpster scheduling are two additional planned demos.
• The demo uses fictional data and browser-local IndexedDB storage; no customer spreadsheet or personally identifiable information belongs in the repository.
• Later work will include:
  • Server-side persistence
  • Broader feature sets
• Timing and scope will follow customer discussion.
• Features and priorities may change as the initial areas are validated.

Demos

Progress Billing

• The user enters all project, contract, subcontractor, and payment-application information.
• The company using the construction demo is the general contractor. Enter the project owner once on the project; owner contracts use that name automatically. Changing the project owner updates owner contracts and draft applications, while submitted applications preserve their original details. Subcontracts have their own subcontractor names.
• Each owner contract and subcontract has its own schedule of values and application history.
• Schedule-of-values rows represent scopes of work, not child projects or subcontractors.
• Track scheduled values, previous work, this-period work, presently stored materials, cumulative completion, balances, and retainage.
• Support change orders and successive billing periods with prior-period carry-forward.
• Keep subcontractor requested and approved amounts separate, and owner payment requests separate from certified amounts and payments received.
• Track payments received and payments made independently of earned work.
• Use a sheet-first payment-application workspace with line details for sources, calculations, history, and adjustments.
• Prefer Kwila UI components wherever possible.
• Automation proposes amounts from explicitly linked, reviewed subcontractor progress; the user retains control over final entries and adjustments.
• Refreshing suggestions must not overwrite the user's adjustments.
• Recalculate totals from final entries and show reconciliation warnings rather than blocking domain discrepancies such as overbilling or contract mismatches.
• Preserve submitted versions; corrections create revisions rather than silently rewriting history.
• Applications are identified by number, period and revision in the application list and PDF. Previously saved application names are no longer displayed.
• Application numbers are positive whole numbers, editable before first submission and unique within each contract, including deleted applications. Submission locks the number for every revision. Next application suggests the highest existing number plus one. Internal sequence and payment links remain unchanged when renumbering; existing browser records keep their original numbers.
• Enter/Shift+Enter moves down/up a progress column; Tab/Shift+Tab moves across editable cells. The selected contract, application and tab survive reload in the same browser tab. Only record IDs and the tab identifier are saved as view state.
• Line-item names remain visible while scrolling across billing columns; long names wrap on narrow screens to leave room for amounts.
• Paste rows adds tab-separated Description and Scheduled value columns copied from a spreadsheet, without headers. Review rows and totals before adding.
• Paste a rectangular block into a draft progress field to preview replacing amounts starting at that cell. The preview shows current and new amounts and totals for the selected range. Only the displayed range changes. Blank amounts are rejected (use 0); invalid numbers and ranges outside the table apply nothing. Dollar signs, thousands separators, and accounting-style negatives are accepted.
• Provide PDF export with an original summary and schedule-of-values layout similar in function to the existing spreadsheet, without copying proprietary form artwork, certification text, or branding, or claiming official AIA forms.
• Subcontractor-facing submission and external sending are out of scope.
• Marking an application submitted records its state locally; it does not send it or post to an accounting ledger.
• Review & submit opens a confirmation sheet with reconciliation warnings. Warnings do not prevent submission; Confirm submission preserves the version.

Walkthrough

• Open Progress Billing and select the fictional example project.
• Switch between the owner agreement and concrete subcontract using Contract.
• Application #1 is a preserved submission; Application #2 is an editable draft.
• Payment Applications has a horizontally scrollable card list below the tabs. Cards show each application's revision, status, and period; Next application sits at the end. Submission and PDF actions remain in the application summary.
• A separate Application configuration card shows its number and period and its Edit and Delete actions using Kwila UI's ActionArea.
• Edit opens the selected draft's number and Period through editor. Save updates only that draft; Cancel leaves it unchanged. Submitted versions have no edit action and require a revision to change their period.
• Delete soft-deletes all its revisions, including submitted versions, after confirmation. Linked payments and later applications remain unchanged and produce review warnings. Deleted records remain in browser storage but are excluded from active views, approval totals, suggestions, and printing. Their application numbers are not reused.
• Contracts open on Overview, followed by Contract Details, Payment Applications, and Payments. Subcontract Overview shows total paid, percent paid, contract balance remaining, and approved amount unpaid after retainage.
• Contract views use Kwila UI's TabBar with linked tab panels, Arrow/Home/End keyboard navigation, and horizontal scrolling on narrow screens.
• Kwila UI cards provide content panels and header actions. Contract overview metrics use responsive indicator cards; schedules and application accounting breakdowns retain their tabular or row-based presentation.
• Edit amounts directly in the schedule. Select a line item to see its linked source, suggestion, retainage adjustments, notes, and submitted history.
• Refresh suggestions beside the schedule to update linked progress without replacing manual adjustments.
• Use Contract Details to add or edit line items and contracts, link equivalent subcontractor scopes, and add change orders. Allocate change orders into the schedule separately; mismatched totals produce warnings.
• Delete contract in Contract Details requires confirmation and permanently removes all its application versions and payments. Links from other contracts are cleared without changing their entered amounts. The project remains.
• Mark submitted opens a confirmation explaining that the current version is preserved, later changes require a revision, and nothing is sent externally. Warnings remain nonblocking. Cancel leaves the draft unchanged. Create revision makes an editable correction; Next application carries prior work and stored materials forward separately.
• Certification (owner applications) and Approval (subcontract applications) record previously certified or approved amounts and the current application's final amount. These are separate from actual payments. When no final amount is recorded, carry-forward uses the calculated net application amount; the user can adjust it in the next draft.
• Use Payments to record actual receipts and disbursements. Link a payment to a submitted application or leave it unlinked. Contract Details shows the unallocated or excess amount when scheduled values do not match the contract.
• Subcontract payment totals include linked and unlinked payments. Approval figures use the latest application's latest revision, including draft approvals, without adding cumulative applications together. A recorded final approved amount takes precedence over the calculated net amount. The approval basis is shown. Warnings flag payments above the approved amount or adjusted subcontract value; they do not block payments. Payments are not allocated to individual line items.
• Collapse the desktop sidebar to an icon rail; its state persists in this browser. Narrow screens use bottom navigation instead of the sidebar.
• Print / Save PDF opens an original summary and detail layout. Choose Print / Save as PDF to export through the browser's print dialog.
• Projects, contracts, line items, change orders, applications, revisions, and payments save automatically to IndexedDB and survive reloads in the same browser at the same site address. The example data is used only when no saved workspace exists.
• Wait for “Saved in this browser” before closing or reloading. Storage failures show a warning; edits remain usable in memory but are not saved.
• Browser storage is not a backup or shared database. Clearing site data, using private browsing, or switching browsers or site addresses can lose or hide the workspace. Use one tab for editing; concurrent tabs do not synchronize changes.
• This demo has no external sending, authentication, subcontractor portal, or server-side persistence.

Local development

• The local environment runs the Angular frontend, Go/PocketBase backend, and Caddy reverse proxy through one port.
• just run uses the development compose stack; Angular watches the mounted source tree and reloads changes without restarting or rebuilding the stack.
• Prerequisites:
  • Docker
  • just
• List available recipes or start the environment:

just
just run

• Nix users can enter the reproducible development shell:

nix develop
just install-deps

• The shell provides the project toolchain and a Nix-compatible Playwright browser.
• The application is available at http://localhost:8080 by default.
• Stop the environment with:

just stop

License

• Licensed under the MIT License.