I’ve been in maintenance and construction my entire working career. I started as a plumbing apprentice, spent years in the regulated world of airport and industrial maintenance, and eventually landed in multifamily. Honestly, that’s where I found my people.
Going from airline work to apartments was a culture shock and a technology shock. On the airline side, everything we did was tracked — from using a screw to replacing a filter. Multifamily was closer to “something’s broken, fix it,” and often nobody was tracking the work except the one resident it affected and me.
Technology moved. Most property management systems eventually bolted on something for maintenance, because operators were tired of spreadsheets and email, and deals were getting lost without a maintenance story. I lived that version in the field. Resident tickets came through a mobile app. Managers printed them and handed them to technicians. We went and took care of it.
Then came make-ready boards, parts, inspections, preventative checklists — all bolted on because customers demanded it, not because anyone designed a maintenance product from the work outward. Those of us in the field could feel it. It was glaring.
My airline experience sat at one end of the technology spectrum. Multifamily tools sat at the other. As my career advanced, the gap got clearer. And here’s the news for maintenance teams in the field: the pain you feel on site, your corporate teams feel too. The tools in market just don’t work well for anyone.
About ten years ago I started taking notes on what worked and what didn’t. I started mapping what a real multifamily maintenance system should do. Tickets, make-ready, PMs, and inspections were the obvious pieces. Some tools even tracked parts, somewhat.
Then, as a regional for a development company, I added notes on how development and acquisition should land for operations. Then compliance. Every building in the country sits under national and local code in one way or another. Elevators get inspected and need certificates. Why is that still a mad dash when a site has turnover? The technology to track it exists.
Those notes, and hundreds more, pointed at one idea: one connected record for the property. The bolted-on approach couldn’t get there. In the rush to acquire and wire things in, most big PMS maintenance layers lost the ability for everything to talk. When Jim does a PM in Unit 101 and five days later there’s an A/C call for the same unit, and the filter never got changed during that PM — that’s ownership money wasted and a missed resident experience. Why doesn’t the system surface that?
I say this with respect to ownership groups: owners are not living in the day-to-day who-did-what. They need the 10,000-foot view. They usually don’t see the missed filter until Unit 101 doesn’t renew after a hot summer day with no A/C. By then you can’t recover it.
Why don’t current maintenance solutions surface that view in real time — that Jim needs coaching on PMs because X, Y, and Z already happened? Because most of them simply can’t. The data never lived in one place.
That brings me to why FixGrid, and why now.
For years the blocker wasn’t the idea. It was the paywall of development. Getting even a basic product built used to cost millions. In 2022–2023, AI tools changed how I could turn years of notes into a real framework. The plan could work — on paper.
Building the actual software was still the wall. In 2024–2025 I started seeing headlines about vibe coding and founders shipping products. Curiosity got me. I went looking.
In 2025 I learned the hard way that vibe coding is not software development. First attempt: tickets that fell apart when make-ready came next. Second attempt: the same wall on inspections. So I did what every maintenance professional does. I learned. Hundreds of hours reading, researching, and figuring out how a tool goes from idea to something that can actually run in production.
The answer for me was agentic coding — directing the work, deciding what ships, keeping quality and security in the loop — not typing “build me an app” and hoping. Once I understood that, FixGrid stopped being only an idea. It became a matter of time.
The other hard problem was product shape, not code.
Everything a tech needs has to live on the ticket. I did not want people jumping app to app, module to module, to do the job. Packing that onto one surface looked impossible. We got most of the way there: almost everything a tech needs now lives on the ticket.
Diagnostics was the other beast. I put myself through a 200-plus question interview over months so the guidance on a ticket would sound like a maintenance guy, not a chatbot. I used Claude to interview me across categories and subcategories: what it could be, how I’d handle it from experience, the safety issues, and how far a tech should take it before they call their manager. That interview did not become the product. It pulled the knowledge out of my head so we could encode it. A person confirms what gets filed. A person still decides.
So why FixGrid, and why now?
FixGrid exists because maintenance teams deserve tools that work for them — not tools they have to work around. I learned how to build the hard way. The ideas became a system of record for the property. Field first. One connected record. Built for the people who do the work, and for the people who buy the tools those people have to live in.