All work

Field service / QuoteIQ

A whole business.
One connected app.

A field-service CRM that connects estimates, scheduling, invoices, payments, and customer communication.

Visit product

Jump to

QuoteIQ’s official product video. Its claims are QuoteIQ’s, not mine. Watch on YouTube
Role
Senior Flutter / Full Stack Engineer
Constraint
One estimate has to hold together across the Flutter app, the customer portal, and the downloadable PDF.
Result
PDFs reflect the chosen offer. Scheduling preserves accepted selections, and percentage deposits exclude the convenience fee.

Inside the interface

The customer’s decision has to survive the next screen. Each note marks where one of my changes lives in the estimate workflow.

QuoteIQ estimate builder showing service selection, pricing inputs, and a calculated service total

Fees stay out of the deposit

I added convenience-fee handling to Flutter estimate totals, keeping percentage deposits based on the amount before that fee.

Illustrative numbers: $100 of work and a $3 fee make a $103 total, and a 20% deposit stays $20, not $20.60.

01Fees stay out of the deposit

I added convenience-fee handling to Flutter estimate totals, keeping percentage deposits based on the amount before that fee.

Illustrative numbers: $100 of work and a $3 fee make a $103 total, and a 20% deposit stays $20, not $20.60.

02Accepted terms survive scheduling

I fixed the customer portal’s accepted-to-scheduled transition so selected items stay locked and totals remain visible.

03Price the work they chose

I connected option and package selections to server-validated PDF pricing, so the document reflects the work the customer chose.

Decisions I made

  1. 01

    Make the total mean the same thing

    The problem
    A convenience fee changes what the customer pays, but a percentage deposit should not grow with it.
    What I did
    In the Flutter estimate totals, I calculate the fee separately and keep two bases: the total includes the fee, and the percentage deposit is computed from the amount before it.
    How it is checked
    The change sits in the estimate-totals code that has its own regression cases.
  2. 02

    Keep the decision intact

    The problem
    Scheduling an accepted job should not reopen the estimate the customer already agreed to.
    What I did
    The portal’s final-decision check now includes both scheduled statuses, and the estimate view and its line items read from that one check. Accepted selections stay locked and totals stay visible.
    How it is checked
    Tests cover scheduled and pending states and both consumers.
  3. 03

    Price the work they chose

    The problem
    Customers choose between options and packages. A PDF that prices the whole estimate tells them the wrong number.
    What I did
    The PDF request now carries the selected package rows. The server validates that selection against the estimate’s current revision and reprices only the selected rows before the document is generated.
    How it is checked
    Regression tests cover the request, the server-side selection check, and the generated PDF.

Sources

Basis
Three changes I authored, checked against QuoteIQ’s Git history and current source in October 2026.
Imagery
QuoteIQ’s official product video on YouTube. Its claims are QuoteIQ’s, not mine. View source
Not claimed
Deployment status, production metrics, payment outcomes, or authorship of every pictured screen.