JRIT Solutions

Technology as an operating business

JRIT Solutions was a full-service managed service provider I co-founded on Long Island, New York. We served small and mid-sized organizations that depended on their technology but had no internal IT team: medical offices, financial firms, and the businesses in between. It was my first experience owning the entire operating system of a technology business rather than one engineering slice of it. Designing infrastructure was the familiar part. Selling it, implementing it, supporting it, keeping the customer relationship healthy, managing vendors, and being the one accountable when something stopped working were not.

An acquisition that did not happen

The company began as a different plan. The original opportunity was to acquire an established MSP from an owner preparing to retire, inheriting its clients, contracts, and tooling in one step. I evaluated the business and chose not to complete the acquisition. Rather than let the idea go with it, I built an MSP independently with a fellow Marine Corps veteran I had worked alongside since 2014, without the inherited client base and without the inherited constraints. I still think of that decision as the first real act of judgment in the venture: the plan changed, the goal did not.

What we provided

The company's public offer, as its website put it, was to keep a client's technology accessible, reliable, and secure. Underneath the slogan sat a concrete set of outcomes. The core was managed operations: continuous device monitoring, endpoint and patch management, asset inventory and reporting, network management, and vendor and license management, so a client's environment was watched and maintained without anyone on their side having to think about it.

Around that core sat the cloud and infrastructure work I did most directly: designing and administering Microsoft Azure and AWS environments, Microsoft 365 and email, Active Directory, virtualization, and cloud migrations, plus the physical layer that small offices actually run on: network design, Wi-Fi, structured cabling, hardware installations, and office build-outs. Security ran through all of it, from security-conscious infrastructure design to access-control options for the premises themselves.

The rest was support: responsive help for users, remotely and on site, and proactive troubleshooting before a problem became an outage. The company also offered adjacent services such as website design and kept a network of partner firms for the work we did not do ourselves, so a client could bring us any technology problem and get a path to an answer.

Building both sides of the company

My role did not divide cleanly into technical and commercial. On the same day I could be designing an Azure environment, troubleshooting a client's network, visiting a site to install hardware, working through a quote with a vendor, preparing a proposal, or sitting with a customer to understand what their business actually needed from its technology. I sold the services, scoped and designed the solutions, implemented them, supported them, managed the vendor relationships behind them, and watched the budget on both sides of every engagement.

In a company that size there is no handoff. The person who promised the outcome was the person who delivered it and the person who answered when it failed. That is a demanding way to work, and it is also the fastest education I have had in what technology is for.

What running an MSP taught me

Technical elegance means very little if a system cannot be supported by the people and budget that exist. A design I admired but could not keep reliable for a client at a price they could afford was not a good design.

Reliability changes character when the customer calls you. An outage is not an availability figure; it is a medical office that cannot open its records or a firm that cannot reach its email, and the phone rings at you. That changed how I think about monitoring, redundancy, and the unglamorous discipline of patching and backups.

Architecture has economic consequences, and security has to coexist with usability and budget. Every choice about cloud, licensing, hardware, and access control showed up somewhere as a monthly cost, a support burden, or a frustrated user. Standardization and repeatable processes were what let a small team serve many environments well.

Most of all, a technology business is a set of systems that only partly concern technology: systems for customers, for work, for money, for vendors, for knowledge, and for day-to-day operations. Good engineering is necessary and nowhere near sufficient. That is the perspective I carry into the operating systems I build today.

Choosing the next path

JRIT Solutions did not become the company I originally imagined when I set out to buy one. In time I decided not to keep growing it as an independent business and joined forces with itiliti, carrying the operating experience, the client's perspective, and the systems knowledge into the next stage of my career. The lasting value of the venture was the operating perspective it gave me: responsibility for the complete system, from technology and security to customers, vendors, service delivery, business growth and the economics underneath it.