SiteOwl: the software the security industry was missing

The situation

Joseph Ndesandjo had run a security integration business for more than a decade: a company that installs and maintains cameras, access control, and other security systems for its customers. Every change, repair, or handover meant digging through spreadsheets, PDFs, vendor documents, and paper printouts. Other integrators struggled with the same problem, and nothing on the market solved it well.

He and his business analyst had researched the market and saw a clear business opportunity. They knew the industry inside out and needed someone who could turn their knowledge into a product: bring in the right people, lead the work, and make sure it all held up. In March 2017, I joined as the third person on the team to do exactly that.

What I did

From idea to first customer

I started with the product, not the technology: discussions with the founder on what customers needed most, what could wait, and what it would cost to build and run the product. That gave us a first roadmap to plan the technology and the team around. At its heart was a building’s floor plan with every security device on it, for the people who plan, install, and service them.

Then I turned to the technology. The platform was aimed at enterprise customers, so it had to handle complex logic and large volumes of data reliably. With limited funding, we wanted a contracted team to build it instead of hiring in-house. Both meant choosing robustness over raw development speed from the start: Java and PostgreSQL on AWS, with a web app in Angular. Mature frameworks and a clear architecture let experienced developers build it well without relying on expensive specialists.

I wrote the brief for the development team and compared proposals from five or six vendors. We chose Cygnet, a development company in India. They weren’t the cheapest, but they took quality assurance seriously, which I’d seen many vendors treat as an afterthought. We started small: a lead back-end developer, a front-end developer, and part-time QA and design.

In November 2017, SiteOwl went live with its first customer, a US college campus. The founder’s security integration company ran it for the campus and gradually moved other projects onto the platform as well. From then on, feedback from real users informed our priorities.

A team and process built to last

Over the years the team grew to up to 15 people: developers for the web app and three mobile apps, QA, a designer, and a DevOps freelancer, plus specialists for short projects. Most came through Cygnet, but we treated them as SiteOwl’s own team. We supported each person’s professional growth, and once a year, SiteOwl paid for a team outing: a long weekend of sightseeing, activities, and team dinners. People stayed close to four years on average.

I set up the process on two levels. At the product level, the leadership team and I agreed what to build, how, and roughly in what order, and defined the detailed requirements. At the development level, I turned each requirement into technical tasks, and the team delivered them in two-week sprints. We planned each sprint with 20% to spare for urgent needs and filled it with smaller tasks when nothing urgent came up. That let us deliver a release at the end of each sprint, 25 times a year.

We used the time zones to our advantage. An urgent issue reported during the US day reached me in Singapore in my morning, when I could still connect with the US team. By the time the team in India started work, I had investigated and planned the change, and it was often live before the US team was back at work.

With this process in place, all of it took me 10 to 15 hours a week: leadership meetings, specifications, guiding the team, and planning ahead on tech.

Growing up: from one server to enterprise customers

SiteOwl started on a single AWS virtual machine, with deployment scripts run by hand. As the product matured and the customer base grew, we increasingly automated deployments and moved to Docker and later Kubernetes. With multiple instances of everything running, the platform could respond to load, survive a server going down, and upgrade seamlessly, achieving 99.95% availability each year.

Scaling brought other challenges. When customers with very large projects ran their reports once a quarter, the load slowed the server down for everyone. We optimized reporting and moved it into a separate cloud function, where it could scale independently without affecting anyone else.

The code had to keep up as well. The web app had started on Angular 4 and we had upgraded it in steps, but much of its fundamental structure still followed patterns from the first few years. In 2023, we decided to bring in an Angular expert for two months to train our team and help us modernize everything to Angular 15. He reviewed our code, suggested changes, and wrote sample code tailored to our app. Our front-end team did the hands-on work, guided by his reviews and pairing sessions, and the knowledge stayed with them.

As SiteOwl moved toward larger customers, SOC 2 became a priority in late 2022. SiteOwl’s Chief Product Officer and I worked on it together, with him owning the organizational side and me the technical side. On my side, that meant tightening the AWS infrastructure, turning recovery plans into rehearsed playbooks, and working with the penetration testers. We had the SOC 2 Type 1 report after six months and Type 2 later that year.

Handing over to a full-time CTO

Larger customers also expected to meet their vendors’ leadership in person. SiteOwl needed a full-time CTO in the US. They offered me the role, but I chose to stay fractional and help them hire instead: I wrote the technical side of the brief and interviewed the leading candidate, who came recommended through their network and stood well above the other options.

He started in April 2023 and took over step by step with my full support. He focused on customers and the long-term strategy, while I stayed on as engineering manager, running the team for another two years until 2025.

Outcome

Over eight years, SiteOwl grew from its first customer to more than 3,000 customers, including college campuses, nationwide retail chains, and the integrators who install their security systems. The platform kept up: 25 releases a year, 99.95% availability, and a SOC 2 report renewed every year. When I left, SiteOwl had a full-time CTO and a team that had worked together for years.

In August 2025, seven months after I left, ASSA ABLOY acquired SiteOwl, describing it as “a leading cloud-based platform that modernizes physical security lifecycle management.”

Lessons

What worked

A robust, conventional stack and a partner strong on QA paid off for eight years: the team could build reliably, and the platform held up as it grew. Treating the contractor team as our own kept people for years, and with them the knowledge of a complex system. A steady release rhythm with room for the unexpected let us keep our promises to customers.

What I’d do differently

I’d consider existing tools more seriously before building our own. The floor plan is the clearest example. Early on we looked at Leaflet, an open-source map library that also handles custom maps such as SiteOwl’s floor plans. We decided it was more complex than we needed and built our own instead. Over the years we added devices grouped onto other devices, connections between them, and distance measurements, much of which Leaflet would have given us out of the box. Our floor plan became one of the hardest parts to maintain. Leaflet would have needed customizing, but that would have cost far less than the maintenance did. We underestimated how complex our own needs would become, and we should have looked at it again as our features grew.

I’d also put greater focus on automated testing, and start sooner. Our manual QA was strong, but our automated end-to-end tests never became reliable. In each run of 100 tests, two or three would fail, and different ones each time. When we started automating, the system was already large, and tracking down why tests sometimes failed despite correct behavior was hard. Today I’d automate well-understood parts early and make those tests stable right away. Building on a reliable base is easier, and you see immediately when something breaks.