ViewR - three pilots in person

Why I went in person

The founder could have sold the pilots remotely and shipped me the install kit by courier. He did not. His pitch was that we would learn more from one in-person install than from five remote ones. He was right. I did three in person between March and June 2025, and they reshaped how I built the product.

What I packed

After the first pilot I built a checklist. Here is the list, plus the reasons each item earned its place.

Hardware -

• The Windows mini-PC with the app pre-installed. We did not trust customer IT to install fresh.
• A spare mini-PC, sealed. In case the first one had a hardware fault during install.
• Three IP cameras of the brand I knew best, pre-configured. Customers sometimes wanted to install cameras alongside our app.
• A network switch. Customer ports may be busy.
• Five Ethernet cables of varying lengths. Customer cable management is always bad.
• A USB Wi-Fi adapter. In case wired ports were not available.
• A USB Ethernet adapter, in case the mini-PC's port died.
• HDMI dongles for the operator dashboard display.
• A small UPS. Power dips in commercial sites are real.

Software -

• A USB stick with the latest installer, the previous version's installer (for rollback), and the OS recovery image.
• Wireshark and tcpdump on the mini-PC.
• A pre-built test page that hit AWS endpoints and reported pass/fail, for network debugging.

People -

• A printed install guide for the customer's IT person.
• A printed operator training booklet.
• A printed list of cell numbers, in case the customer's Wi-Fi died and I needed to coordinate.

The checklist took 4 iterations to stabilize. The first pilot I forgot the spare Ethernet cables. The second I forgot the USB Wi-Fi adapter. By the third I had everything.

Pilot 1 - Masters Union, Gurgaon

Business school. The brief was attendance and intrusion detection. Six cameras across two buildings, around 400 students to enroll.

Site survey - day 1 morning

Walked the site with the facilities head. Identified camera positions for entry doors, lecture rooms, and after-hours corridors. Marked power and network availability for each. Two positions did not have network drops nearby - we got cable laid the next day rather than working around it. Total camera count came down from 9 (their wishlist) to 6 (what actually solved the problem).

Install - day 1 afternoon

Cameras up, Ethernet to a switch, switch to a port the IT team gave us. App installed on a mini-PC near the security desk. First boot, no cameras showed up. 20 minutes of debugging - the IT team had put us on a guest VLAN that did not have access to the camera subnet. Reconfigured to a corporate VLAN. Cameras showed up.

Enrollment - day 2 morning

The school had a student database with ID photos. I wrote a 20-line script that pulled the photos and ran them through IndexFaces with the student ID as the external ID. 400 students enrolled in 15 minutes. The enrollment was the part I expected to take a day. Using their existing data saved us.

Operator training - day 2 afternoon

The security manager watched students walk through the entry for an hour while the dashboard updated. I demoed the watchlist flow with my own face. I showed the after-hours alert routing. They asked thoughtful questions about false positives, which led to me adding a "mark as false positive" button in the next release.

What broke later

A week in, after-hours alerts spiked because cleaning staff were walking through corridors at 5am and not enrolled. We added a "staff" enrollment category with separate alert rules. Lesson - your enrollment plan has to cover everyone the camera will see, not just the primary user population.

Pilot 2 - Giva flagship stores

Jewellery brand, two experience centers. The brief was security via watchlist matching (industry-shared list of known shoplifters) plus visitor frequency tracking.

Store 1 - smooth

Site survey, install, enrollment, training, all in two days. Watchlist had 80 faces from the industry source. We hit two watchlist matches in the first week, both confirmed by store staff as legitimate concerns. The store manager loved the alert UX.

Store 2 - the network bug

Same install plan, same hardware, second store. Install went fine. Dashboard came up. Then everything was slow. Face matches that took 200ms at the first store took 8 seconds here. Watchlist alerts arrived 30 seconds late.

The dashboard error log said nothing useful. The Electron app's network panel said "request timeout". My first instinct - blame Rekognition. Wrong instinct.

I SSHed into the mini-PC and ran tcpdump -i any host rekognition.ap-south-1.amazonaws.com. Most TCP SYNs to Rekognition were not getting a SYN-ACK back. The packets were going out but not coming back. That was the smoking gun - the customer's network was blocking or rate-limiting outbound HTTPS to AWS.

Talked to the customer's IT vendor. Their answer - the store was on a "managed Wi-Fi" service from their telecom provider that ran a captive portal and rate-limited "unrecognized" traffic. The portal had let our initial HTTPS handshake through (we accepted the terms) but subsequent connections were getting throttled.

The fix - moved the mini-PC to a wired connection on a separate ISP line the store had for POS terminals. Bypassed the managed Wi-Fi entirely. Latency dropped back to 200ms. Everything worked.

What broke later

The customer asked for a feature - notify the store manager on WhatsApp when a watchlist match fired. We built it in week 2 after the install. Lesson - the channel the customer wants for alerts may not be the channel you assumed (email vs. SMS vs. WhatsApp vs. push). Ask.

Pilot 3 - enterprise office

An enterprise customer, will not name them. The technical install went fine. The pilot did not convert.

The post-mortem from the founder was the most useful lesson of the year. The customer's actual problem was visitor management - they had hundreds of visitors a week, paper sign-in sheets, no auditability. Face recognition at the door was a "nice to have" for them. What they really wanted was a system that issued QR-code badges, tracked visitor host approvals, integrated with their calendar system, and produced compliance reports.

We could have built visitor management. We chose not to, because it was outside the vision pipeline thesis. The pilot taught us that for that customer segment, our product was a feature, not a product. We pivoted toward smaller customers where security was the real concern, not visitor logistics.

The non-technical lessons

A laundry list of things I now do before any customer visit.

• Confirm the install date with both the buyer and the IT lead. The buyer sometimes does not know IT is on vacation.
• Ask for the network setup in advance - VLAN structure, internet egress, firewall rules. Half the time the customer's IT does not know either, but the asking surfaces unknowns.
• Bring a one-page test plan you can hand to the operator. They will use it after you leave.
• Wear something professional. Track pants and a hoodie work in the office. They do not work at a client site.
• Show up half an hour early. The customer will appreciate it. You will use the time to check the network from the parking lot.
• Sit with the operator for at least 2 hours after install. Not the IT person, not the manager. The operator. They will tell you what is wrong with the UI in 5 minutes.
• Leave a small printed runbook with the customer. "If the dashboard is blank, try X. If the camera is offline, try Y. If neither works, call this number." The IT person will use it.
• Write a post-visit memo within 48 hours. What worked, what broke, what to ship in the next release, what to abandon.

What this taught me

The biggest lesson from three pilots was about empathy. I had been building the product for the persona on a sticky note in the office. After three visits, I was building it for actual humans I had met, whose names I knew, whose workflows I had watched.

That changes everything. You stop asking "is this feature elegant?" and start asking "would Anjali at the Masters Union security desk use this at 7am?" The answer is more often "no, simplify it" than I had thought.

Every engineer building enterprise or SMB software should do a customer install. It will reset your priorities about what matters.