Nobody types a password on a roof

When we designed the job site survey app, the longest discussion was not about what should go into it. It was about the login page.

We scrapped it.

Where this thing actually gets used

Picture it for a second. Someone is standing on a job site. It may be raining. He is wearing gloves, or his hands are dirty. He has three minutes before he has to move on. And in those three minutes he has to take a few photos, note down a few measurements and say how urgent it is.

Now put a login screen in front of that, with an email address and a password nobody remembers because the app gets used twice a week. What happens next is predictable. People don't use it. They take photos with the normal camera and send them in a message, exactly like before, and your app sits there for nothing.

Software used out in the field doesn't compete with other software. It competes with the usual habit: sending a photo, writing something on a scrap of paper, mentioning it later. Ask for more steps than that and you lose.

What we did instead

You open the link and you pick who you are from a list of four names. That's it.

No password, no account, no email verification. The app knows who you are because you pointed at yourself, and for this purpose that is enough. We record who did the survey so the work can be followed up, not to deny anyone access to anything.

There is a barrier, but it sits on the link itself: a PIN code that shields access to the whole thing. Type it once, after that the device remembers it. Anyone without the link and the code doesn't get in.

Isn't that insecure

That question always comes, and it is a fair one, so here is the honest answer.

It depends on what is in there. In this case: photos of roofs and facades, with measurements and notes. Commercially sensitive, certainly. But there is no personal data in it that does damage when it leaks, no payment details, no HR file.

Against that risk sits another risk that is far bigger: an app nobody uses. Then you have no job site surveys at all, and that costs money for certain.

That is the trade-off, and it does not always fall the same way. If there were payroll or customer data in there, I would be telling you something different. But the default reflex of putting every system behind a full login is not a security decision. It is a habit, and it costs you usage.

The other things we took out

We applied the same logic to the rest.

No free text fields where a dropdown does the job. Urgency is urgent, scheduled or not urgent. Three buttons. Let people fill that in as free text and you get fifteen variants of the same thing, and nothing you can count afterwards.

No required fields you cannot possibly know on site. If the app forces you to enter something that is not there at that moment, someone types "n/a" or "1" and you have a polluted field for the rest of the ride.

And no separate step to send anything. You are done, it is sent. Anything that still asks for a tap after the last meaningful action is a place where someone drops out.

What you do need alongside it

One thing that does not look like functionality but is: the output has to be immediately usable for the next person in the chain. With us, a job site sheet rolls out as a PDF that you simply forward or print.

That is what sells the app to the people who have to use it. Not the fact that it lands neatly in a database, because a salesperson rightly does not care about that. What he does care about is no longer having to type up a report in the evening.

The database is what it gives me. The PDF is what it gives him. You need both, and you have to know which of the two you use to convince someone.

The claim

With software for the field, the question is not which features go in. It is how much you dare to leave out so that it still gets used by someone with dirty hands and three minutes to spare.