ViewR - solo engineer in stealth

The company

ViewR was a stealth surveillance startup. Founder was an IIT Delhi grad with a few years in computer vision and an idea about office and campus security. The bet was that medium-size organizations (50 to 500 employees, a few hundred entries per day) wanted face-recognition-based access tracking but did not want to be a customer of a big enterprise vendor. We were going to be cheaper, faster to deploy, and better at the things those customers actually used.

I was the only engineer. The founder did sales, product, customer development. I did everything else from architecture to deploys to on-site installs.

Why solo worked (and where it did not)

Solo engineering is a strange role for a junior. The upside is that every system is yours. The downside is that every system is yours. There is no one to review your PR, no one to bounce a question off when the camera does not show up on the network, no one to cover the on-call when you are sick.

What made it work for 6 months -

• Clear scope from the founder. He could write a spec in one Notion doc that told me exactly what the next demo needed.
• Buy versus build was always "buy". I never wrote a face recognition model. I never wrote a video codec. I never wrote an auth system from scratch.
• The customer base was small. Three pilots, then more if they signed. The blast radius of any bug was small.

What did not work -

• Code review. I had no one to review my code. I tried to ask the founder, but reviewing 500 lines of TypeScript is not a CEO's job. I started using Linter rules aggressively, writing tests for anything tricky, and reading my own diffs the next morning before merging.
• On-call. I was on-call 24/7 for 6 months. That is not sustainable. We never had a true outage because the deployments were small, but I never fully unplugged either.
• Architecture decisions. I made decisions that were reasonable at the time and would not survive scale. I knew it, the founder knew it, we shipped anyway because the alternative was not shipping. That is the right call when you have three pilots. It would have been the wrong call at thirty.

The architecture

The constraints shaped the architecture.

• The customer's IT team will not let us install Linux servers on their network. We need to run on Windows, on a regular desktop, with a one-click installer.
• Cameras are IP cameras from a dozen vendors with no standard API. We need a layer that abstracts the differences.
• Face recognition has to be accurate enough that an enterprise security manager trusts it. We are not building the model.
• The customer ops team has to be able to use the UI with no training beyond a 15-minute walkthrough.

That gave me Electron for the desktop, AWS Rekognition for vision, ONVIF over RTSP for cameras, and a small Node backend in AWS for the parts that needed to be centralized.

Electron desktop

Electron got criticism but it was the right tool. The customer's IT person could double-click an installer and have it running in a minute. Auto-updates worked. Background process kept the cameras connected and the AWS calls flowing.

Heavy work like frame decoding used FFmpeg as a child process, not native bindings. This let me ship a build that worked on any Windows machine without compilation pain.

AWS Rekognition

I did not want to build a face recognition model. The market is full of vendors who have spent more time on this than I would in 6 months. Rekognition's Collections API was the right shape - enroll a face, get back an embedding, search later by embedding similarity. The cost was a few cents per thousand operations, well below our pricing.

The work I did on top of Rekognition - de-duplication of multiple detections of the same face in a 5-second window, watchlist matching, ranking of unknown faces by frequency (so the security manager could enroll the regulars), and confidence thresholding tuned per customer.

ONVIF and RTSP

This is where I spent the most time and the most pain. ONVIF is a "standard" the way "standard" works in industrial protocols - in theory every camera supports it, in practice every camera supports a different subset with different bugs. I ended up with vendor-specific shims for the three brands we encountered most.

PTZ control had its own complexity. The customer wanted operators to be able to click a thumbnail of a face in the dashboard and have the camera physically zoom in on the location. That meant mapping a face's bounding box in the camera frame back to PTZ coordinates, which is geometry I had not done since school.

The three pilots

Masters Union

Business school in Gurgaon. They wanted attendance tracking for classes (face recognition at room entry was less friction than a card swipe) and unauthorized entry alerts at after-hours doors. We installed 6 cameras across 2 buildings, enrolled about 400 student faces over 2 days, ran for a month.

What went well - attendance accuracy was around 94 percent, which beat their previous card system because students used to swipe each other in. What went wrong - the after-hours alerts had too many false positives because cleaning staff did not get enrolled. We fixed it by adding a "staff" enrollment category.

Giva

Jewellery brand. They wanted security in their experience centers - high-value inventory, so unusual visitor behavior was a real concern. We installed in two flagship stores. Watchlist for known returners (the brand had a list of past shoplifters from industry sources).

What went well - the watchlist hit twice in the first week, and store managers loved the alert UX. What went wrong - the cameras in one store were behind a captive portal that blocked our cloud calls, took half a day to debug because the symptom was "the app is slow" not "the network is blocking AWS".

Third pilot

I will not name them. Similar shape, enterprise office building, mostly successful, the customer wanted features we did not have (visitor management workflows) and the deal did not convert.

What going on site taught me

I had built the dashboard on my laptop, in a quiet room, on a fast network, with my own face being recognized over and over. Then I sat next to a security guard at Masters Union at 7am, watched her try to use the dashboard with one hand while waving students through with the other, and realized half my UI was useless.

Specific things I changed after on-site -

• The "review unknown faces" workflow went from 4 clicks to 1 click.
• Alert sounds got distinct tones for different alert types so the operator could tell without looking.
• The watchlist match dialog became a single big screen with the face crop, the location, and a "acknowledge" button, not a small modal with details.
• The dashboard auto-refreshed instead of requiring a manual refresh, because nobody clicks refresh.

I would not have gotten any of that from a Zoom demo.

What I would do differently

Two things.

First, I would have written end-to-end tests for the camera-to-AWS pipeline earlier. I had unit tests on the embedding logic but I had no end-to-end test that proved "camera frame in, dashboard alert out". Every release was manually verified, which slowed me down and let bugs sneak in.

Second, I would have negotiated for a second engineer at month 3, not month 6 (when I left for Binocs). The pace was sustainable for 3 months. By month 5 I was burning out, and the founder would have been better off with two of me at half the cost.

What this taught me

Going solo as a junior is a forcing function. You learn to make decisions because no one else will. You learn to buy because you cannot build everything. You learn to ship because no one is going to ship for you.

It is also lonely and you should not do it for more than 6 months without a teammate. The teamwork muscles atrophy. The code review habit atrophies. The "is this a good idea" muscle gets confused with the "do I want to do this" muscle.

I am glad I did it. I would recommend it to any junior who wants to learn how to be the engineer in the room. I would also recommend they leave at the 6-month mark and join a team again, like I did.