The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Insights
When the person writing the quote is not the person who ran the calculation, the same data is typed twice and two prices appear. We trace a chain where every quote line reads back to its input.
The software ticks every line on your list and the work still does not fit. How to bring the two things a developer asks about, the conditions of the work and the record, to the first meeting.
The quote is in; the budget will not carry the list. Which line can you drop and lose nothing, and which one forces a rebuild later? The test is not price: is the line a record, or a reading of one?
A decision is architectural when undoing it is expensive, and timing sets the price. Boundary sentences, derived records, inherited limits and the three calls we bind before the first line of code.
In the foreground and with permission, a web browser gives a page the camera and location, so why is the field app installed? The needs list decides first, then who holds the device.
A system that 'talks to the accounting program' is a handover point between two owners, not a module. Which records stay with you, why one way beats two, and where a correction lands.
The same question comes in daily; whoever reads the messages that day answers it. Whether a bot can take it depends on where the answer lives, not on its topic. No rule, and the bot improvises.
An OMR device sits in one office; branches ship their answer sheets to it and wait. Move the reading from the device's optics to the form image, and every branch that can scan can score.
If there is a system you want built, the quote form is the place to describe it.
