Documentation.

What is Fieldjig?

Fieldjig is a construction field-management project for contractors, project managers, field crews, and office teams. It brings project coordination, crew time, daily reports, documents, and administrative workflows into a self-hosted application.

Our goal is to give smaller construction businesses access to practical management tools without breaking the bank. We're building an open-source, self-hosted alternative to costly larger platforms, while recognizing that hosting, setup, and ongoing maintenance still require a budget.

The code currently lives in the public Fieldjig repository. Older technical documents may use the previous project name, project-manager-app.

Building in the open.

The development checklist records implemented timecard lifecycle flows, daily-report workflows, document management, admin task tools, and a payroll foundation. Project workflows, reporting, mobile coverage, and other domains still have open work.

Feature completion is not a security or compliance certification. Payroll calculations and operational controls need validation for your organization and jurisdiction.

Before you start.

• PHP: the Composer manifest declares PHP 8.2+. Check the lockfile and required extensions against your target runtime; project guidance targets PHP 8.4.
• Composer: for installing the PHP dependencies.
• Node.js: the application uses Vite 7; use Node 22.12+ or a newer compatible LTS release, plus npm.
• Database: provision a database supported by your selected app configuration. Confirm migration compatibility before deployment.
• Services: configure mail, storage, cache, queue workers, and the scheduler as required by the workflows you enable.

Get a local workspace running.

This is a development starting point, not a production installer. Use a disposable database and review the repository's current instructions before running setup.

git clone https://github.com/eli-reid/fieldjig.git
cd fieldjig
composer install
npm install

Copy .env.example to .env using your file manager or shell. Set your local application URL and database connection. Never commit that file or share credentials.

php artisan key:generate
php artisan migrate
npm run build
composer run dev

Keep the development process running and open the local URL printed by the server. The repository includes automated tests; run the affected tests for your changes.

If package installation or migrations fail, stop and resolve the reported error. Do not use real production data to work around setup failures.

Self-host with a plan.

Production setup needs more than uploading a source archive. Serve the Laravel public directory over HTTPS, disable debug output, provision persistent storage, and configure workers and the scheduler.

• Back up both the main database and any persistent settings database.
• Use an approved release or deployment branch; review migrations before applying them.
• Build frontend assets and install production PHP dependencies.
• Verify permissions, notifications, file uploads, and enabled workflows.
• Plan rollback and test backup restoration.

The existing runbook refers to a production branch. Confirm that branch and your deployment policy before following it.

A modular Laravel foundation.

The application uses Laravel 12 and Livewire. Cross-cutting platform systems live under app/Core; business features live under app/Domains. Services and actions own business logic, while UI components stay focused on orchestration.

• Livewire-first route-facing interfaces.
• Policy- and permission-based authorization.
• Explicit boundaries between business domains.
• Dedicated mobile surfaces following mobile/{domain}.

A community plugin library is planned for this website. Catalog submissions, compatibility rules, and distribution are not available yet.

The consolidated architecture specification is the canonical reference; older documents may describe superseded structures.

There's more than one way to help.

Useful contributions include reproducible bug reports, field-workflow feedback, documentation fixes, tests, and focused code changes.

Report a bug

Open a GitHub issue with the app version or commit, environment, steps to reproduce, expected behavior, and actual behavior. Include sanitized screenshots or logs, never employee data or credentials.

Suggest a feature

Describe the jobsite problem first: who is affected, what they do today, and what success would look like. Search existing issues before creating a new one. Discuss large changes before implementing them.

Send a pull request

Read the repository's contributor instructions, keep changes scoped to the owning domain, add or update tests, and link the related issue. Explain what changed and how you verified it.

A small, useful tracking system.

GitHub Issues is the recommended starting point for bugs, feature requests, documentation, and maintenance work. The following is a proposed workflow, not a claim that these tools are already configured.

Before launch, confirm the open-source license and dependency redistribution rights, add contribution and security policies, and identify supported versions. A license field in a package manifest is not a substitute for a reviewed repository license.

Go straight to the source.