A construction punch list app is only as good as the record behind one item.

The list is evidence, not a reminder

On federal construction work the standard inspection clause is blunt about where the burden sits. The contractor has to maintain an adequate inspection system and perform the inspections that keep the work conforming, and then the clause goes further: the contractor shall maintain complete inspection records and make them available to the Government. That single sentence is the business case for a defect tracking app for construction. Photographs in a group chat are not records anyone can produce on request.

The same clause says nonconforming work gets replaced or corrected without charge, unless the Government consents to accept it with an appropriate adjustment in the contract price. So an item has two legitimate endings and they are not the same ending: fixed, or accepted as it stands with something written down. An app with only open and closed cannot record the second one, and the second one is the expensive one.

Acceptance is then final except for latent defects, fraud, gross mistakes amounting to fraud, and rights under a warranty or guarantee. In practice that means your records become most valuable after everyone has left the site. Private contracts use their own words and the shape is the same: a list at substantial completion, money held back until it clears, and a correction period afterwards during which somebody asks what you did in March.

FAR 52.246-12, Inspection of Construction

What one punch item has to carry

Start with location, because that is the field people get wrong. Second floor bathroom is not a location on a job with nine of them. A site punch list app wants a level, a room number or grid reference, and ideally a pin on the drawing, so that a tiler who has never been in that room can walk to it without phoning anyone.

Then the responsible party. An item assigned to a company is an item nobody picks up. An item assigned to a person at that company gets picked up. The moment an item needs a date, a cost and a sign-off from somebody outside your own office, it has stopped being a punch item and become a small job, which is why this data grows towards a work order management app whether you planned for it or not.

Status needs more than two values. Open, fixed and waiting for verification, verified, and accepted as it stands with a note are four different facts, and one boolean flattens them into something untrue. Add a due date, a trade, who raised it and when, and a single item is roughly ten fields. That is the whole schema. Every screen in the app is a view over it.

Give the item a reference a human can say out loud. Items get discussed on the phone and on a ladder, and L3 to 42 is something two people can exchange in a noisy stairwell. A database identifier nobody ever sees on screen is not.

Two photographs, and what they do not prove

The before photograph and the after photograph are the reason this work moved off paper. Take both from inside the item rather than from the camera roll. A roll from a three hour walk is two hundred pictures of grey surfaces in bad light, and nobody is going to pair them up on Friday afternoon.

So can a generated app actually do this? Here is what we saw. The starter Expo project a Newly build begins from lists Expo's image picker among its dependencies, and that module opens both the camera and the photo library. The product documentation says apps keep their data on the device until they need accounts or sharing, and that file storage for photos and uploads arrives with the backend the agent adds at that point. A punch list crosses that line immediately, because subcontractors have to see their own items. We did not run a build and watch a second photograph close an item, so treat the two photograph flow as assembled from parts that exist rather than something we witnessed.

There is a smaller catch worth knowing before your first real device build. iOS will not open the camera or the library without a usage string in the app configuration, and the image picker documentation names them: NSCameraUsageDescription for the camera and NSPhotoLibraryUsageDescription for the library. Ask for both by name rather than discovering it when a site manager taps the camera button and nothing happens.

The same documentation is honest about metadata. EXIF comes back only if you ask for it, and on iOS an image taken through the picker does not include GPS tags. So do not build the location of a defect on whatever the image file happens to carry. Write the item reference, the level, the time and the person into the database row at the moment of capture, and treat anything inside the file as a bonus.

Expo, ImagePicker permissions and EXIF

The list gets walked, not read at a desk

A closeout walk is one hand on a phone, the other holding a torch, in a plant room with no bars. That shapes the interface more than the data model does: large targets, one thumb, a choice wherever typing can be avoided, and the camera two taps from the item rather than six.

Who sees what is the other site problem. The general contractor, four subcontractors, the architect and the owner each want a different slice, and the subcontractor does not want a licence or a training session. A link that opens their own items and lets them mark one done with a photograph covers most of the value. Some findings are not defects at all but hazards, and those belong in a safety incident reporting app with its own reporting clock, not in a queue somebody works through by Friday.

Expect the list to be walked twice. The first pass raises items and the second verifies fixes, and the second pass is the one that gets skipped because the app made it tedious. Design for the verification walk first and the raising walk will look after itself.