The 30-second test for board software

Every software vendor selling something to your HOA board will show you a screenshot of their dashboard. The dashboard is for the demo. The actual question that determines whether their product survives in your building is much simpler:

Can a board member create a useful log entry on a phone, in a mechanical room, with bad signal, in under 30 seconds?

If the answer is yes, the tool has a chance. If the answer is no, the tool will be used for a month and then abandoned, no matter how good the dashboard is.

We call this the 30-second test, and we apply it to every change we make to BuildingHQ.

Why 30 seconds?

Not because 30 seconds is some magic UX number. Because of the context in which board members actually need to record things.

The board member is in the boiler room. The fire panel has flashed a fault code. The plumber has just finished a visit and is heading out. The package delivery driver wants to know what to do with a crate of supplies. A neighbour stops them on the way back to their unit and says “by the way, the lobby door isn’t latching.”

In all of these moments the board member is on their phone, between two other things, in a building corner where the signal is two bars. If recording the moment takes more than half a minute, they will:

1. Not record it.
2. Mean to record it later.
3. Forget by the time they’re at their laptop.
4. Forget the boiler room one too, three weeks later, because there are now twelve un-recorded incidents and recording them feels like homework.

This is the failure mode for every board software in the market. Almost all of them are designed by people who imagine the user is at a desk.

What the 30-second test actually means

Here’s what you measure. Open the app. Get to the “new entry” screen. Type one sentence. Optionally attach a photo. Submit. Stop.

That entire flow should be under 30 seconds. On a phone. With one hand. In a mechanical room.

The implications of taking this seriously are interesting:

No login friction. The board member is already logged in. The session lives long enough that they’re not retyping a password on the second floor.

No “select a building” step. They’re a member of one building. The product knows that.

No “select a category” before they can start typing. Categories are inferred or assigned later. Typing first.

No mandatory fields. A vendor name, an equipment link, a tag — all optional, all infer-able from the text later. The entry has to be acceptable with just the sentence.

Offline. The signal in the boiler room is two bars. The entry has to save locally and sync when bars come back. The user shouldn’t have to know about this; they tap submit, they see “queued”, they move on.

Camera in the same flow. Not a separate “attach a photo” page. The camera icon is right there in the composer, opens the system camera, the photo lands in the entry on the same screen.

Most board software fails at least three of these. Some fail all six.

A small case study

We had a beta tester last year, a member of a 38-unit strata council in Vancouver. They’d been using a PayHOA-adjacent tool for two years. At the start of beta we asked them to log a dripping kitchen tap in unit S204. They opened the existing tool on their phone. The flow was:

1. Open app, see dashboard.
2. Tap ”+ New”.
3. Pick from a menu: announcement, work order, document, payment. They picked work order.
4. Select category. They picked plumbing.
5. Select unit. They had to scroll the unit list (the search was on the desktop only).
6. Select priority. They picked medium.
7. Add description. Three lines.
8. Submit.

90 seconds. And that’s an experienced user.

They tried the equivalent flow in our prototype. Open app. Tap the composer. Type “S204 kitchen tap dripping”. Tap submit. 14 seconds. They looked at the screen for a second and said “that’s it?”

Yes. The fields they were filling in with category, priority, “work order” type — none of those existed. A board member doing the weekly triage would assign them on a laptop, or — most often — the entry would stand on its own with no assignment because a kitchen tap that’s dripping is self-explanatory.

How to apply this when you’re evaluating

You don’t have to buy our product to use the 30-second test. If you’re evaluating any board software:

1. Install the app on a phone.
2. Walk to your building’s noisiest, lowest-signal spot.
3. Pretend a vendor just left. Time yourself logging one observation.

If it took longer than 30 seconds, ask yourself: how often, realistically, am I going to do this? If the honest answer is “less than I should”, the product won’t survive a quarter of real use, no matter what the dashboard looks like.

The 30-second test is also useful for our own discipline. When we add a new feature, “does this still pass the 30-second test for a new entry?” is the first question. It has prevented us from adding several useful-sounding fields that would have killed the product the moment they shipped.

---

Want to see what 14 seconds feels like? Sign up free — your first entry counts.