Property Preservation SaaS — Revised Consolidated Development Plan

Updated: 31 Oct 2026 (Revision 8)
Status: Consolidated reference of the user's decisions and development planning. Not a claim that implementation is complete.
Goal: Build our own multi-company subscription SaaS, using PPW as the workflow and feature reference.

1. Basis and limits of this file

This plan was created by combining the original discussion document with the corrections from later chats. It is only for the Property Preservation SaaS; Paper Desk, trading, branding, educational content and other projects are not in its scope.

The user's Confirmed decisions, proposed implementation and unresolved decisions are kept separate below. Proposals added in this revision are marked “Proposal”; they are not decisions until the user approves them. The historical vendor information and estimates in the reference document have not been re-verified. Creating this file is not new permission for implementation, external messaging, publishing or deployment.

PPW is the reference software here. “Master copy” means our own implementation that follows the necessary workflow/features; it is not a claim that PPW's source code or proprietary assets are available. PPW's screens, text or branding will not be copied verbatim. No preservation company has yet been fixed as a real pilot customer.

2. Confirmed decisions

2.1 Impact of the worldwide market — Proposal

• First sales market — Confirmed: USA. The product will be international-ready from the start. In other countries the closest markets are property maintenance, inspection and field-service companies; their workflow may differ.
• Currency: Each company will have a base currency setting; only USD is supported in v1. Mixed-currency transactions will not be in v1. This way, adding GBP/AUD/CAD later will not require database changes.
• Localisation: Avoid US-only assumptions — state/ZIP not mandatory in address fields; company- and property-based timezone; date format and units (sq ft/m²) as company settings; v1 UI in English, all text in translation files.
• Privacy: Photos with GPS and property addresses may be personal data. For EU/UK customers, GDPR — data processing agreement, deletion on request, region-specific hosting if needed. To be determined in line with the retention/deletion policy (§11).

3. Main parts of the product

1. Platform administration and company subscription management.
2. Company office web portal.
3. Android contractor app, with offline support.
4. Photo, metadata, forms and documents system.
5. QA, rework and delivery workflow.
6. Web accounting and reports.
7. Future Aspen and other client connectors, and automation extension points.

4. Roles and permissions

The detailed permission matrix will be determined after looking at the PPW screens and the real workflow. The design will not assume that having platform administration means unrestricted viewing of every company's private records is permitted.

Proposal — Support access: To help a customer, support access will be available with the company's consent, time-limited and with an audit log.

5. Complete order flow

Manual/CSV order → office review → assignment → field work → submission → QA → correction or approval → client delivery → client acceptance → billing/payment → closure.

5.1 Order creation

Proposed fields:

• Internal order ID and external/client order number.
• Company, client, property and service type.
• Property address (international format) and necessary location details.
• Received date, due date, priority and instructions; the property's timezone.
• Tasks, quantities, units, forms and required photo categories.
• Client rates and contractor costs, visible according to permission.
• Source: Manual, CSV, or later Aspen/other client connector.
• Attached documents and reference photos.

Multiple orders can be kept on the same property. For CSV import, a template, field mapping, validation preview and rejected-row feedback are proposed. Proposal: a separate saved CSV mapping template for each client. There will be a mechanism to detect duplicate external orders.

5.2 Assignment and field work

The office will assign the contractor. The contractor will see the order instructions, deadline, tasks and required evidence. Whether an accept/decline feature is needed will be determined in the reference review.

The contractor will save photos, answers, quantities and notes and submit them later. Draft and submitted versions will be kept separate.

5.3 Bids and additional work — Confirmed for v1; detailed rules from PPW screens

If additional work is found in the field, the contractor submits a bid with photos → office review → submit to the client → client approves/rejects → the approved bid is added to the order as a new task. Bid history and approval reference will be kept.

5.4 QA and rework

The office will review photos, metadata, forms, quantities and completeness. A correction reason can be given on a specific task/photo. The contractor will correct and resubmit. Previous submission and review history will be kept.

5.5 Delivery and closure

A downloadable package of approved photos/results will be created. While there is no Aspen access, delivery to the external portal is manual; the office will record the delivery date, reference and acceptance/rejection.

Office-approved, delivered, client-accepted, invoiced and paid are separate states. Operational closure and financial settlement will be tracked separately. There will be cancelled, on hold and exception states; final transition rules will be determined in the specification.

Confirmed (v1) — invoice cuts and chargebacks: For many clients the invoice is submitted together with completion, and the client may later reduce the invoice (invoice cut) or charge back. Therefore invoicing will remain possible even before client acceptance, and invoice adjustments and chargebacks will be tracked. A deduction/percentage from the contractor's pay is proposed. Detailed rules will be determined from the PPW screens.

6. Photo and metadata system

6.1 Photo record

• Company, property, work order and task reference.
• Before/during/after or a client-specific category.
• Capture date-time, timezone/offset and upload date-time kept separate.
• GPS latitude/longitude and available location accuracy.
• Available device/app information.
• Available original EXIF.
• Original filename, format, dimensions and size.
• Source: in-app camera or gallery.
• Uploader, caption, submission version and QA status.

6.2 Original, metadata and watermark

The original image and available embedded EXIF must be kept intact. App-collected metadata can be stored separately with the photo record; there is no assumption that every device writes the same EXIF fields. The watermarked/display copy will be separate.

The watermark's fields and layout will be determined according to client requirements. A compressed/watermarked copy will not be stored in place of the original.

6.3 Missing metadata and exceptions

If required GPS/time is missing, the photo will be flagged. The contractor will give a reason; office QA will decide on replacement or exception approval. Hard block versus exception policy must be set per client in the specification.

The current location at the time of a gallery upload cannot be shown as the original capture location. Missing metadata will not be fabricated to fill gaps. Metadata presence by itself does not prove authenticity or constitute tamper-proof evidence.

Proposal — Client-wise photo rules: Whether gallery upload is allowed, minimum photo count, required categories, watermark layout and missing-metadata policy will be per-client settings; not hard-coded.

7. Android app and offline support

7.1 Confirmed scope

Android-only first release. It will include the contractor field workflow, photos, metadata, forms, draft, submission and corrections. There will be no accounting module.

Proposal: In the worldwide market (especially the US, UK and Australia) many contractors use iPhones. Therefore choose a cross-platform framework (such as React Native or Flutter), so iOS can be added later at low cost. The first release will remain Android-only.

7.2 Proposed offline behaviour — detailed approval pending

• Download assigned orders, instructions and forms while online.
• View downloaded orders offline.
• Save forms, notes and quantities as drafts.
• Offline camera capture and collection of available GPS metadata.
• Queue photos and drafts on the device.
• Resumable/retry upload and sync when the internet returns.
• Show pending, uploading, failed, synced and submitted states separately.
• Do not show a submission as successful without server acknowledgement.

GPS location may be available even without internet, but depending on permission/device/location conditions it may be missing or inaccurate; the exception flow applies.

7.3 Sync rules — proposed rules, pending approval

• If the contractor is offline when an order is reassigned/cancelled or instructions are updated, the local draft will not be lost; after sync a conflict will be shown and the office will resolve it.
• Every submission and photo will have a device-generated unique ID, so there are no duplicate uploads/submissions.
• Logout will be blocked (with a warning) while unsynced items exist.
• The local copy will be deleted only after server confirmation.
• Policy for local storage limits and device loss is still to be determined.

8. Office web portal

• Dashboard: unassigned, due/overdue, submitted, awaiting QA, rework and delivery pending.
• Properties and work orders.
• Clients, contractors, rates and service templates.
• Assignment and work queues.
• Bids and additional work approvals (Proposal).
• Photo gallery, metadata inspection and documents.
• Forms, submissions and QA comments.
• Rework and submission history.
• Delivery packages and manual external-delivery records.
• Accounting and reports.
• Users, permissions and company settings (currency, timezone, units, client-wise rules).

Layout and detailed interactions will be determined from the PPW reference screens; unseen PPW features will not be assumed to be implemented.

9. Accounting — web portal only

Revision 5 (Confirmed): In v1, order billing, payments and operational reports are our own; the actual accounting is in the customer's QuickBooks Online, via sync. 9.1 below (ledger foundation), the bank reconciliation in 9.4, and the P&L, balance sheet, trial balance and general ledger in 9.5 are in v2. 9.2, 9.3, job costing, ageing and statements are in v1.

9.0 QuickBooks Online sync (v1)

• One-way sync (our app → QuickBooks): client company → Customer, contractor company → Vendor, client invoice → Invoice, contractor bill → Bill, payments → Payment/Bill Payment, invoice cut or chargeback → Credit Memo/Vendor Credit.
• Item and account mapping in each company's settings.
• Sync log, error list and retry (like PPW's "QuickBooks sync errors" report).
• If a contractor is marked as a 1099 vendor in QuickBooks, the US 1099 is handled there; this matches our decision to exclude tax.
• Intuit developer app and OAuth 2.0; Intuit's app review before production. The Intuit App Partner Program tier and API fees must be verified.
• QuickBooks Desktop not in v1. CSV/Excel export for those who do not use QuickBooks.

9.1 Foundation

• Chart of accounts and double-entry general ledger.
• Journal entries and opening balances.
• Accounting periods, closing and adjustment controls.
• Reversal/adjustment of posted entries and audit history.
• Company-level base currency; only USD in v1.

9.2 Client billing

• Invoice draft from order/services.
• Approved invoice posting.
• Receipts, partial payments and outstanding balances.
• Credit adjustments, invoice cuts/chargebacks and receivable ageing.

9.3 Contractor/vendor accounting

• Contractor bill/payable from the order.
• Contractor pay percentage and deductions (Proposal).
• Approval, payment recording and partial payment.
• Adjustments and payable ageing.

9.4 Banking and job costing

• Bank/cash accounts and reconciliation.
• Expenses and supporting documents.
• Order-wise revenue, contractor cost, other costs and profit.

9.5 Reports and export

• Profit & loss, balance sheet and trial balance.
• General ledger.
• Receivable/payable ageing.
• Client and contractor statements.
• Job profitability.
• Invoice, receipt and payment registers.
• Operational order/status reports.
• Contractor-wise yearly payment total (e.g., for US 1099 preparation) — Proposal.

Applicable date/client/contractor/property/order filters and PDF and Excel/CSV export will be available. SaaS subscription billing and the tenant company's accounting will be kept separate.

9.6 Accounting boundaries

Tax calculation, tax filing and tax documents are outside the first release. Since tax differs by country, this decision is reasonable for a worldwide market. Proposal: still keep a manual tax line on invoices and a tax ID field for clients/contractors (e.g., US TIN/W-9 status, UK VAT number) — without any tax engine.

Payroll, bank feeds and actual payment execution are not approved scope; a separate decision must be made if needed.

Reporting basis — Confirmed: cash basis. In the P&L, income and expenses will be recognised on the date payment is received/made. Since invoice and bill records will be kept, receivable/payable ageing and statements can be shown. Data will be kept in a way that allows accrual reports to be added later. Financial year, opening balance import, invoice numbering and posting rules are not yet determined. It is proposed that the acceptance criteria for “full accounting” being complete be determined using accountant-reviewed examples.

Item for review (not a change of decision): Full GL, reconciliation and period closing are the largest development cost. As an alternative, operational billing in v1 (invoice, contractor pay, payments, job profit, ageing) plus QuickBooks/CSV export, with the full ledger in v2 — this can be compared at budget estimate time. The current decision is full accounting.

10. Multi-company SaaS

Each company will have separate users, clients, contractors, orders, photos, accounting and settings. Company-level data separation is part of the core design; it will not be dropped even though commercial verification is postponed.

Cross-company contractor — Confirmed: one login. A contractor who works for multiple companies will use the same account. Design: global user identity + company-based membership. In the app, the contractor will see orders separated by company. Company A will never be able to see the contractor's Company B orders, photos, rates or payments. Each company can add/remove its own membership; this will not affect another company's data.

Each company's settings: base currency (v1: USD), timezone, date format, units and language.

11. Subscription pricing and storage policy

Both of these are Confirmed as necessary; specific prices and limits are not yet approved. Subscription prices will be in USD.

11.1 List of items to determine

Retention — Confirmed: An active company's photos will be kept forever. If a company cancels its subscription, that company's photos will be deleted.

Impact and Proposals:

• Storage cost will keep growing. Example: photo ~4 MB, ~100 photos per order, 300 orders per month → ~1.4 TB per year per company. So pricing needs a storage tier (included TB + a charge for additional TB).
• Move older photos (e.g., more than 1 year old) to lower-cost infrequent-access/cold storage.
• Export window after cancellation (Proposal: 30 days): during this time the company can download all photos/data, after which it is deleted. Deleting from backups may take longer (Proposal: at most 90 days); this will be stated in the Terms.
• Keeping photos for a specific number of years under a client contract is the customer company's responsibility; exporting before cancelling is their responsibility — to be made clear in the Terms.
• On non-payment, no immediate deletion; grace period → suspension → export window → deletion.

11.1.1 The user's proposed prices (Revision 7)

• $100/month per company, including 5 users; beyond that, $10/month per user.
• Break-even (5 companies, total cash investment ~$5,500, monthly running cost ~$300):

• The break-even count starts from when 5 companies begin paying regularly; it does not include own time and living costs.
• Confirmed: office staff, vendors/contractors and crew — everyone who does work — each account will be counted; after 5, $10/month per account.
• Example: 30 users in a company → $100 + 25 × $10 = $350 per month; 5 companies → $1,750 per month; net ~$1,400; break-even ~4 months.
• Confirmed (rule): only active users will be counted — those who logged in during the month or were assigned to any order; no charge for inactive or blocked accounts. If a contractor works for two companies, each company pays $10 for its own membership. If a user is added mid-month, a prorated charge; via Stripe per-seat subscription.
• Proposal: add a storage tier (e.g., 1 TB included, then a monthly charge per TB), because photos are kept forever, so each company's storage cost grows every year; consider a lower price for field users; discount on annual plans.

11.2 Method for determining pricing

A cost model will be built from each company's monthly orders, photos/order, original photo size, retention, users and support effort. The subscription price will be set accounting for infrastructure, backups, tools, support, payment processing fees and later Aspen fees. No specific selling price recommendation can be called an approved price at this point.

11.3 USD subscription collection — Confirmed: US LLC + Stripe

• Form a US LLC, get an EIN and a US business bank account; then subscriptions via Stripe Billing.
• Important: A foreign-owned single-member LLC must file Form 5472 and a pro forma Form 1120 every year; failure brings large penalties (up to $25,000 per form). Hiring a US accountant is proposed.
• Some US states levy sales tax on SaaS subscriptions; as revenue grows, Stripe Tax or an accountant's advice will be needed. This is a separate matter from the decision to exclude tax from tenant accounting.
• Opening an organization developer account on Google Play through the LLC is proposed (requires a D-U-N-S number). New personal accounts have a requirement of 12 testers for 14 days in closed testing before production.

Manual subscription activation is proposed for the first pilot; Stripe integration in Phase 6.

12. Aspen and other client integration options

Now

Manual/CSV input, Android field work, QA, delivery package and accounting will run independently. Settings may show Aspen as “Not connected”.

Foundation for future integration

• External order/client IDs and source fields.
• Provider-specific status mapping.
• Connector separate from the core workflow — Proposal: a generic connector layer, so Aspen is just one of many client connectors.
• Per-company authorized connection.
• Sync history, retries, errors and reconciliation.
• Duplicate-safe import and submission.

After access is obtained, the supported order import, status, and photos/results return flow will be determined. Invoice/accounting data transfer will not be assumed to be supported. Vendor access, fees, documentation and permissions are still pending.

13. Future automation

With stable internal interfaces, events, queues and audit history, reminders, assignment suggestions, missing-photo checks, invoice preparation and rules can be added later. These automated business decisions are not mandatory in the first release.

14. Development roadmap

Multi-company design will be there from the start; tenant separation will not be deferred to Phase 6. Framework, database and hosting stack are not yet final; hosting region will be considered according to the privacy requirement (§2.1).

15. First end-to-end milestone

A company will create a manual/CSV order → assign a contractor → the contractor will take the downloaded order in the Android app, work offline and save photos/forms with metadata → when online, sync and submit → the office will do QA/rework/approval → create the delivery package → the client invoice and contractor payable will be created → payment recording and the job profit report will be visible.

This milestone will work without Aspen and will be completed with Phase 4's minimal billing slice. QuickBooks Online sync is a separate milestone (Phase 5); full ledger in v2.

16. Verification and launch boundary

Per the user's instruction, formal commercial launch verification is postponed for now. Necessary functional checks will take place during feature development — especially offline draft retention, metadata flags, sync acknowledgement, duplicate handling and accounting posting.

Proposal — Minimum checks before the pilot: When the pilot company provides real data, production effectively begins. So before the pilot, run a tenant isolation test, a backup restore test, and have the access audit log enabled.

A full security review, external integration acceptance and a full assessment of production readiness will be in the future launch phase. These cannot be called completed or passed now.

17. Budget and target schedule

A budget estimate and schedule are needed, but no fixed ceiling, team capacity or deadline has been given. A phase-wise estimate will be prepared after PPW feature coverage, offline details and accounting rules are determined. The product's selling price is in USD; which currency the development cost accounting is kept in is the user's decision.

Historical planning figures — not a new quotation

The original discussion mentioned a BDT 1–2 lakh reserve for a self-built/AI-assisted pilot, BDT 10–25 lakh or more for outsourced full development, and BDT 10–25 thousand per month for small-pilot infrastructure/tools. These are not a validated budget for this corrected scope. The self-built reserve did not include own development time or Aspen fees; the operating estimate excluded paid support, large photo volume and other items. For the current scope (offline Android + multi-company SaaS + full accounting), BDT 1–2 lakh is unlikely to be sufficient; it is proposed to define a small pilot scope first and then estimate.

Preliminary estimate (Revision 3) — not a commitment

Basis: one developer (the user), AI-assisted, TypeScript-based stack (§21). The estimate will be revised after reviewing the PPW screens.

• Up to the pilot (Phases 1–4): ~27–40 weeks, i.e., 6–9 months full-time; 12–18 months at 20 hours per week.
• Complete v1: ~40–59 weeks, i.e., 9–14 months full-time.
• Update (Revision 5): After adding the extra scope of §22 and shrinking Phase 5, up to the pilot ~32–48 weeks (7.5–11 months full-time) and complete v1 ~38–58 weeks (9–13.5 months full-time). Details in §22.6.

Cash costs (USD, approximate):

Total cash cost for the first year: approximately $2,500–6,000 (≈ BDT 3–7.5 lakh, assuming $1 ≈ BDT 120). Own development time, later Aspen fees and the Apple developer fee for iOS ($99/year) are excluded.

17.1 Target schedule (Revision 6) — not a commitment

Basis: 40 hours per week, starting Monday, 2 Nov 2026. At the end of each Phase, the following dates will be revised based on actual progress.

This calculation does not include holidays or illness; in practice another 2–4 weeks should be added.

Other work alongside development:

17.2 Total cash cost up to complete v1 (Nov 2026 – Dec 2027, approximate)

Realistic middle: $5,000–6,000 (≈ BDT 6–7 lakh, assuming $1 ≈ BDT 120). This does not include the user's own time, living costs, Aspen fees, iOS or the Intuit API fee (verification pending).

Value of own time (for comparison): ~1,500–2,300 hours. Outsourcing the same work would cost approximately $23,000–70,000 with offshore developers ($15–30/hour), and $75,000–350,000 with US developers ($50–150/hour). The original discussion's BDT 10–25 lakh outsourcing estimate is low for this scope.

Monthly running cost after launch: hosting and tools $100–300 per month + photo storage ($15/TB/month, growing each year per company) + Stripe fee (~2.9% + $0.30) + annual costs of the US accountant and LLC. The break-even will be calculated once the subscription price is set.

Items for the new estimate

• Requirements and PPW reference mapping.
• Web order operations, bids and QA.
• Android app, offline storage and sync.
• Photo originals, metadata, storage and transfer.
• Full web accounting and report exports.
• Multi-company/subscription administration and localisation.
• Payment gateway/merchant-of-record setup and fees.
• Hosting, backups, tools, maintenance and support.
• Necessary accounting, legal/privacy and technical review.
• Later Aspen connector development and vendor fees separately.

Target dates will be determined after reviewing each phase's scope, effort, dependencies and acceptance criteria. This document does not give any fixed price or delivery commitment.

18. Required reference materials

The main reference will be the PPW screens provided by the user:

1. Dashboard and order list.
2. Order details, tasks and instructions.
3. Contractor assignment.
4. Field forms, photos, metadata and watermark examples.
5. Bids and additional work approval.
6. Submission, QA and rework.
7. Client delivery/export.
8. Invoice, invoice adjustments, contractor bill and payment.
9. Accounting reports and settings.

Personal information must be masked where necessary. No login password is needed. If unknown behaviour is inferred from the screens, it will be marked as an assumption. Business rules will be more accurate if sample orders, rates, forms and payment examples are obtained; this is not a claim that they have been obtained at present.

19. Remaining Decision register

20. Next actionable steps

Create the feature inventory, screen-by-screen specification, permission matrix and sample order flow from the PPW reference screens. The fundamental decisions (contractor identity, retention, first market, payment collection) were made in Revision 3; in parallel, start forming the US LLC and obtain the pilot company's consent. Then prepare the development effort, budget and schedule based on the specific limits of Android offline and web accounting.

Core committed scope: A USD-based multi-company preservation SaaS for the worldwide market that runs without Aspen; Android offline field workflow; photos with metadata; office QA; web-only order billing, payments and reports + QuickBooks Online sync (full ledger v2); tax excluded; room to add Aspen/other connectors, iOS and automation in the future.

21. Proposed tech stack — pending approval

Principle: for one developer, a single language (TypeScript) across web, server and mobile; reduce server maintenance by using managed services.

22. PPW reference findings (Part 1–2) and proposed v1 scope

Source: read-only observation in Chrome (30 Oct 2026). PPW's text or design is not copied; only the necessary workflow is understood. All lists in this section are Proposals; pending approval.

22.1 Key lessons

1. The pricing engine is central. In the item catalog, each item has a contractor and a client unit price; pricing rules by client, work type, lot size and state; client discount % (state-based), contractor discount %, line-item markup %. The contractor total can also be calculated by subtracting a discount from the client total. The item examined ("Grass Recut") has no pricing filter rule; this suggests that rule-based pricing is probably little used in this account, and prices mostly run on each item's base price and discount % (unverified). Proposal: simple pricing first in v1 (item price + client/contractor discount % + client-wise price override); lot size/state rules as a general table, extended after seeing the pilot company's real usage. The work type edit form does not open in this account (only the Add form and a trash icon), so the full field list for work types is unknown.
2. Default instructions rule engine. Client × customer × work type × loan type → default line items and instruction text. The client's photo requirements mainly live in this instruction text.
3. Contractor company and crew — unverified. PPW has only four groups: Client Company Login (inactive, effectively no permissions), Contractor, Manager and Vendor.mgt. The name Vendor.mgt is misleading: it is the office's processing/QA role (assignment, QC, invoicing, payment, users), not a vendor company's role. Individual contractors and crew are all in the "Contractor" group. There are some signs of company-based delegation: the "Use contracting companies to delegate access" and "only show office staff company name" settings, a Company field on each user, permissions named "Sub Contracting Company" (Ready for Office, Follow Up) and a subcontractor invoice report. However, how delegation actually works was not observed. Revision 5: The user has confirmed that crew members use separate logins. Proposed rules (v1):
   • The contractor company (vendor) is one entity; with its owner/lead and crew users.
   • The office will assign an order to the contractor company or directly to a crew member; the contractor owner can reassign within their own crew.
   • Crew will see only their own assigned orders; they will not see the contractor's prices and payments (depending on settings).
   • Contractor bills and payments will be in the contractor company's name, not the crew's; crew pay is the contractor company's own matter.
   • Which crew member performed photo, check-in and submission will be recorded.
4. Accounting: No full ledger was seen in PPW; there are QuickBooks Online integration and Sage fields. This suggests customers probably do their actual accounting in QuickBooks (§22.5).
5. PPW's own billing appears to be monthly and usage-based; one large account's monthly bill is several thousand dollars. The market is used to paying large amounts.
6. The PPW mobile app works very poorly offline (the user's experience, Revision 5). So reliable offline is our main differentiator and the core selling point; this will be prototyped and proven in Phase 1 itself.
7. PPW weaknesses to avoid: two levels of Status and Category; ~400 permission checkboxes; one long settings page; old and new pricing systems side by side; empty dashboard; import credentials shown in plain text.

22.2 Added to v1

Order and property

• Client and Customer (investor/servicer) kept separate; loan #, loan type, mortgagor, occupancy.
• Access codes (lockbox, key, gate, lock location) visible only to the assigned contractor and the office; loan # masked, unmasked with permission.
• Contractor due date and client due date (client-wise due date offset); received, start, estimated complete, complete, cancel and sent-to-client dates.
• Rush (24/48 hours), BATF, recurring orders (frequency, limit, cutoff).
• Work type catalog: company-configurable, recurring and inspection flags, starter template.
• Property entity: order history; property notes and order notes kept separate.
• Duplicate order.
• List of "Unable to complete" reasons (e.g., occupied, no access).

Workflow

• Fixed system statuses + company-defined tags (not two levels of status).
• Ready for Office: who and when, resubmit count; Office Lock after QC.
• Contractor accept/reject (company setting); unread-late alert.
• Mobile check-in/check-out (GPS and time), can be made mandatory per client or contractor.
• Zip-based contractor coverage and zip lookup (manual assign; auto-assign later).
• Order list: advanced filter, saved views, column chooser, bulk actions; separate search page.

Pricing and billing

• Item catalog + pricing rules (client, work type, lot size range, state).
• Client discount % (state-based), contractor discount %, markup %.
• Bid grid: contractor price and client price side by side; bid info and completion info kept separate; past bids; PDF.
• Per-order client invoice and contractor invoice: flat fee, adjusted price (invoice cut), credit memo, invoice complete, sent-to-client.
• Payments: check #, chargeback flag; client payment import (remittance file); incomplete invoices report; AP/AR report (column picker and Excel export).

Photos and forms

• Photo rules at three levels (company default, client, order): minimum photos, photos per flag, no future date stamp, no EXIF editing.
• Order-level QC: missing timestamp, missing GPS, date range, max distance (requires property geocoding).
• Flags, move/copy, rotate, reorder, datestamp overlay, PDF download.
• Client-wise delivery copy: resize, header text, filename pattern; original kept intact.
• PCR/forms: form builder (basic question types), which orders require it set by filter, required, photos required, transfer of answers from the previous form.

Users and security

• Role templates (Owner, Manager, Office Processor/QA, Accountant, Contractor owner/lead, Crew) + limited toggles; not 400 checkboxes. Crew rules in item 3 of §22.1.
• Contractor documents (insurance, licence) with expiry date and alert.
• Vendor directory (Confirmed, Revision 8): 4 ways to add vendor details: (1) manual form, (2) Excel/CSV + column mapping + duplicate check, (3) PDF (read W-9 and insurance certificate/ACORD 25 and fill in fields; office verifies and saves), (4) invite the vendor, who fills it in themselves, and the office approves. Admin can filter and view any information: status, state, ZIP/county, work type, on-time %, open orders, chargebacks, insurance expiry, missing W-9, pay method, 1099, QuickBooks link; column picker, saved views, Excel export. EIN and bank number show only the last 4 digits; the Owner can see the full value, logged each time. Estimate: +1–1.5 weeks (the PDF-reading part is the large one).
• 2FA (authenticator), login history, device and app version.
• Audited "Login As" (support access, §4).
• Integration credentials encrypted; never shown in plain text.
• User-wise notification matrix (email + push); event templates with placeholders; SMS later.

Reports (v1): 11 of the 12 in PPW's Reports menu (details §22.7). PPW Link Queue later.

22.3 Later (v1.5/v2)

• Scheduled auto-import (login-based), push-link/inbound API, and Fannie Mae platform, XactPRM, Pruvan, ServiceLink and Aspen connectors.
• Reading work orders from PDF/email with AI (potential differentiator).
• Rule-based auto-assign (zip, previous contractor, priority).
• Client login portal.
• Mapping PCR answers to order fields; fillable PDF form mapping.
• Hazards grid, route print, vendor availability, property merge, duplicate field settings, SMS.
• Order link queue (sending/receiving orders when another company is on our system).
• Client-wise document and training library.

22.4 Excluded

• Embedded analytics (Insights/Liveboards) and dashboard builder; instead, a useful default dashboard.
• Internal messages inbox.
• JPG bid print.
• Background check-in provider.
• Two pricing systems at the same time.

22.5 Accounting decision — Confirmed: (B)

Evidence was found that PPW customers do their accounting in QuickBooks. Options:

• (A) Current decision: full accounting in v1 (§9).
• (B) Proposal: in v1, the order billing and payments of §22.2 + QuickBooks Online sync/export; full ledger in v2, if customers want it.

The user chose (B) (Revision 5). Details in §9 and §9.0.

22.6 Impact on the estimate

With the pricing engine, form builder and contractor crew model added, the estimate up to the pilot will increase by approximately 5–8 weeks: ~32–48 weeks, about 7.5–11 months full-time. With (B) adopted, Phase 5 has dropped from 10–14 weeks to 3–5 weeks; complete v1 ~38–58 weeks, about 9–13.5 months full-time.

22.7 Reports — Confirmed (Revision 8)

The user wants PPW's Reports menu and the AP/AR report in the very first Draft.

Confirmed rules:

• Sub-contractor company = crew. Not a separate entity; "Group by sub-contractor" in AP/AR means grouping by crew.
• The Customer (loan owner/investor) comes with the client's order. There will be a field for it in manual entry and CSV import; the office can change it manually.
• Client payment remittances arrive as PDFs. Method: PDF upload → read the text → match each line to an invoice by invoice # or client WO # → office reviews and confirms. A template (where the columns are) will be set up once for each client's PDF layout. For scanned PDFs (no text), manual entry with the PDF alongside. There will also be our own standard CSV format (Spec Part 2).
• The contractor does not always bear a chargeback/cut. Each chargeback records "who bears it": Contractor / Company / Split (amount or %). The contractor's share will be deducted from the next contractor bill; the company's share comes only out of the company's margin.
• One report engine: filters → group by → column picker → saved presets → background Excel export (notification and email). All reports will use it.
• Limit: a maximum 1-year date range per report; no date is needed when searching by invoice # or check #.

PPW audit (Chrome Claude, Revision 8):

• AP/AR: 36 result columns with all extra columns enabled; with group by, a subtotal row after each group.

• Contractor Reportcard: 12 columns; an On-time % / Late % bar at the end of each contractor; late in red, on-time in green; no grade. When the Ready for Office date is blank, PPW shows a wrong (5-digit) number in "Days in Field". Our rule: when the date is blank, count up to today, with a "still in field" label.

• Mass Writeoff/Chargeback: Writeoff or Chargeback mode; in chargeback mode, contractor and amount on each row. PPW has no "will the contractor bear it" option; ours will have Contractor / Company / Split (differentiator).

• Customer field in the order's Loan Info, read-only (comes from the client).

• Client payment import (PPW): a separate importer per client: Excel/CSV/ODS (column mapping), PDF (AFAS, BofA, MCS, Five Brothers, ServiceLink, M&M), and email text paste (Altisource, Safeguard). Ours: (1) Excel/CSV + column mapping, (2) PDF + client-wise template, (3) email text paste + the same template method; in all cases match → review → Apply.

• AP/AR result: 36 columns (Invoice #, dates, contractor, vendor ID, processor, address, masked loan #, client WO #, customer, work type, category, due dates, WIFCD, client total, discount %, paid amount/date/check #, write-off, etc.); an internal invoice note row below the invoice; grand total and "Client total due" at the end. In PPW, payments can be saved and QuickBooks synced from the result; for us these will happen from the Billing screen, and the report is only for viewing and export.

• Status change log: by order/client/customer/contractor/work type; in each order's block, status, who (name + login), when (to the second); resubmission "Ready for Office (2)". Ours will come straight from the history table.

• Check-ins: multiple check-ins on the same order; lat/long, timestamp, provider sync status. Check-out: total time (hours).

• WIFCD: a date field on the order, meaning unknown (not in PPW help). Decision: a company can create 2–3 custom date fields with its own names; WIFCD will be imported as one of them. The pilot company will be asked what it means.

Still remaining: the result for PCR responses (the account has no PCR form; will be designed from our form builder).

Impact on the estimate: adding the report engine and export, payment import (PDF) and mass write-off adds approximately 4–5 more weeks. Complete v1 approximately 27 Aug 2027 – mid-Jan 2028.

Change log (Revision 8)

• 11 reports from PPW's Reports menu in v1; Link Queue later (§22.7).
• Sub-contractor = crew; the customer comes with the client order; remittance PDF import; who bears a chargeback is set per chargeback.
• Mass write-off and city-wise income moved from §22.3 into v1.
• Complete v1 slipped by approximately 4–5 weeks.
• Vendor directory: manual / CSV / PDF / invite and admin filter (§22.2). The vendor will add crew members themselves from the app; the office will not need crew CSV/PDF import.
• v1 scope freeze (30 Oct 2026): from now on, a new feature enters v1 only for a proven need of the pilot company, and only by dropping something or moving a date.

Change log (Revision 6)

• Confirmed: 40 hours per week; target schedule and parallel task timeline (§17.1).
• Pricing method unknown; simple pricing in v1 (§2, §19).

Change log (Revision 5)

• Confirmed: accounting (B) — order billing, payments and reports + QuickBooks Online sync; full ledger v2 (§2, §9, §9.0, §14, §15, §17, §21).
• Confirmed: separate logins for crew; crew assignment and pay rules proposed (§22.1).
• Confirmed: PPW's offline is poor; offline prototype in Phase 1 (§14, §22.1).
• Estimate updated (§17, §22.6); Decision register updated.

Change log (Revision 4)

• PPW Part 1–2 findings, proposed v1, later and excluded lists (§22).
• New decision question on accounting scope (§22.5).
• Impact on the estimate (§22.6); Decision register updated.
• Correction: Vendor.mgt is actually an office processing role; contractor company/crew model marked as unverified (§22.1, §22.2).

Change log (Revision 3)

• Confirmed decisions added: first market USA; one contractor login; photos forever, delete on cancellation; US LLC + Stripe; bids and chargebacks in v1; cash basis; the user builds it themselves; PPW access available; potential pilot company exists.
• Impact of retention and export window Proposal (§11).
• Warnings about the US LLC's annual filing and the Google Play account (§11.3).
• Preliminary time and cost estimate (§17).
• Proposed tech stack (§21).
• Decision register updated.

Change log (Revision 2)

• Confirmed decisions added: target market worldwide, currency USD.
• Impact of the worldwide market (§2.1): localisation, per-company currency, privacy.
• Proposals added: bids, invoice cuts/chargebacks, client-wise photo rules, support access, sync rules, cross-platform framework, manual tax line/tax ID, payment collection route, pre-pilot checks.
• Roadmap: minimal billing slice in Phase 4; contractor identity, retention and localisation decisions in Phase 1.
• Decision register updated.