CASE 01 / Product & systems
The backend behind an order's next step.
I co-built GreenFortune's survey-to-handover operations platform. This story follows one critical detail: keeping partial production, dispatch, and installation counts consistent.
- THE PROJECT
- Behind the order
- THE CONTEXT
- GreenFortune
- THE CHAPTER
- 2025 - Present
- THE PROBLEM
- Production, dispatch, and installation need a consistent view of each order's progress.
- WHAT I OWNED
- Backend workflows, state transitions, permissions, and typed APIs within a team-built platform.
- THE RESULT
- Incremental production and installation updates retain their history without breaking dispatch's existing records.
Behind the order / THE BIG PICTURE
How the
backend changed.
The first correction fixed the total. A second change kept the submission history: the screen needed to show "5 produced, then 3," not just "8 produced."
- 01 / INPUT
Produced in this update
A production submission records an increment. It must not overwrite the previous total.
- 02 / VALIDATION
Stay within the target
The handler adds the increment, checks the work-order limit, and completes production at the target.
- 03 / HISTORY
Keep each submission
An additional ledger stores the individual updates and returns the remaining balance for each one.
- 04 / COMPATIBILITY
Leave dispatch working
The existing component totals remain in place for dispatch. The migration adds history rather than replacing those records.
An anonymized case study and simplified product map, not a production diagram. Private code, infrastructure details, and customer data are not included.
COMPONENTS / RESPONSIBILITIES / SCOPE
How the parts fit together.
The four parts involved in this correction. This is a simplified code-level explanation, not GreenFortune's deployment topology.
01
React workspace
The production screen submits the units made now and lists earlier submissions.
- The boundary
- A value entered in that form is an increment, not a replacement for the total.
- Implementation note
- I made the API return each submission's remaining balance rather than requiring the screen to reconstruct it.
02
Fastify handlers
I changed count-based updates to add to the recorded total and reject amounts beyond the work order's target.
- The boundary
- Production completes when the count reaches the target; completion does not record the final increment a second time.
- Implementation note
- The existing per-component input still means an absolute count. I kept that path separate.
03
PostgreSQL records
I added one production ledger row per submission, alongside the existing total.
- The boundary
- A running total cannot reconstruct the sequence of updates that produced it.
- Implementation note
- Keeping both records avoided changing the data contract used by downstream dispatch.
04
Dispatch & installation
Dispatch continues to read the existing component totals. Installation has its own submission ledger.
- The boundary
- Installation updates are checked against what was delivered, not just what was planned.
- Implementation note
- Unlike production, installation can be deliberately closed with units still due. Its completion reports the installed count.
Conceptual responsibility map. Not a production deployment diagram or a screenshot.
01 / The problem.
The production screen asks how many units were made in this update. The backend treated the answer as a replacement total. On a 25-unit work order, entering 15 and then 10 left the record at 10 produced, not 25. The people recording production and the dispatch workflow were then working from a count that had moved backwards.
02 / My role.
As an SDE-II at GreenFortune, I co-built the operations platform with Fastify, PostgreSQL, Drizzle, and React, covering survey through handover. My backend work includes unit-level state transitions, server-side role checks, database constraints, and typed API contracts consumed by the frontend. This example follows my September 2026 changes to count-based production and installation: accumulating submissions, retaining their history, and applying different completion rules to the two stages.
- My contribution
- Production and installation handlers, submission-ledger tables, migrations, and regression tests.
- Shared scope
- The React workspace and wider operations platform are team-built. This is not a claim of sole authorship of every layer.
- What changed
- Count-based updates add to prior progress and return the submission history alongside the current total.
03 / Where this fits in the workflow.
- 01
Survey
Record the units required for the project.
- 02
Order
Set the quantities the production work order is expected to fulfil.
- 03
Production
Add each count-based submission to the total. Retain the individual entry.
- 04
Dispatch & install
Use produced totals for dispatch availability, then validate installation updates against delivered units.
- 05
Handover
Keep the recorded quantities available through the remaining order workflow.
04 / What I changed and preserved.
Record the increment in one place.
I moved count recording into the update handler. When an update reaches the production target, completion reads that total instead of adding the last submission again.
The constraintThe per-component input already had absolute-count semantics. Changing every input to an increment would have broken that existing path.
The total was not enough for the screen.
After correcting accumulation, I added a per-submission ledger. The API returns each entry with the balance still due, so reloading the screen does not lose the individual updates.
The constraintDispatch still reads the old component totals. I retained those totals and made the ledger migration additive instead of replacing the storage model.
Installation closes differently from production.
I applied incremental recording to installation too, but kept closing as a deliberate action. A closed installation can have units still due; its completion now reports what was actually installed.
The constraintReusing production's auto-completion rule would have changed that workflow. The installation handler instead validates accumulated counts against delivered units.
05 / Implementation details.
- Distinguishing an increment submitted now from the total produced so far.
- Keeping the individual submissions available after a reload, not just their sum.
- Preserving the existing component totals that dispatch uses to calculate availability.
06 / The result.
- The regression case now records 15 + 10 as 25 produced and zero due.
- Production history returns each submission and the units still due at that point.
- Installation adds new counts to earlier progress and reports the actual installed amount when closed.
07 / What the tests check.
- A regression test submits 15 and then 10 against a target of 25, and checks 25 produced with zero due.
- Another test rejects an increment that would take the accumulated total over the work-order target.
- Ledger tests check that separate submissions return separate entries with the correct remaining balances.