How OpsFlow Went From a Conversation to a Live SaaS in 4 School Districts

The best software products I know of didn't start with a pitch deck or a market size TAM slide. They started with a person who understood a specific problem deeply — and a moment where someone said out loud: there has to be a better way to do this.

OpsFlow started exactly that way. Not with a business plan. With a conversation.

The Conversation

I had a relationship with someone who worked inside a school district. Not an IT director, not a superintendent — someone in operations, in the weeds of how facilities actually get managed day to day. They were describing how maintenance requests worked at their district: paper forms, shared spreadsheets, email threads that went nowhere, work orders that fell through the cracks.

A pipe bursts. Someone fills out a form. The form goes to a supervisor. The supervisor emails a technician. The technician doesn't see the email until Tuesday. Nobody knows what's actually been addressed, what's pending, what parts are needed, what it's all costing.

This wasn't a complaint. It was just a description of how things worked. But I heard it as an engineer: this is a solved problem. Everywhere except here.

The best vertical SaaS opportunities aren't hidden. They're described out loud every day by people who've just accepted the pain as normal.

What Existing Software Got Wrong

Before writing a line of code, I looked at what existed. There are enterprise facility management platforms — big ones, well-funded ones. But they're built for large commercial real estate companies, hospital networks, corporate campuses. The pricing starts at levels that would consume a school district's entire maintenance budget. The implementation requires months and a dedicated consultant.

For K-12 school districts — which in the US average under 2,000 students — these products are functionally unavailable. Not technically. Economically and operationally. The districts that could most benefit from better systems are exactly the ones that can't afford or resource the existing solutions.

That gap is where OpsFlow lives.

The Decision to Build

I've been building software for 20+ years. I knew the scope of what a real enterprise SaaS requires — not a simple CRUD app, but a multi-tenant system with role-based permissions, real-time communications, mobile access, billing, and the kind of reliability that an institution depends on. I wasn't naive about what I was signing up for.

What I had was: deep engineering experience, a specific industry contact who could validate assumptions, and a clear problem with a market that was demonstrably underserved. That combination is rare. When it shows up, you build.

Stack Choices and Why

I chose Blazor WebAssembly for the frontend, ASP.NET Core 10 for the API, and .NET MAUI for the mobile app. This is a deliberate choice that I'll write about in more depth separately, but the short version: for an enterprise SaaS with complex permission structures, real-time requirements, and a mobile app that needs to work offline, the .NET ecosystem is the most productive and reliable stack I know. Full type safety top to bottom. No context switching between languages. One team, one toolchain.

Azure for infrastructure. SignalR for real-time notifications. Stripe for billing. Azure Key Vault for secrets. Firebase for mobile push. Each decision was made for production reliability, not demo elegance.

From First District to Four

The first customer — Pike County Schools — came directly from that original relationship. I built the MVP with their specific workflows in mind, got it in front of their operations team, and iterated quickly on the feedback. The goal wasn't to build a perfect product. It was to build a working one that solved the core problem better than what they had, which was nothing.

Word travels fast in smaller districts. They talk to each other. They attend the same conferences. A district administrator who sees a peer using a tool that actually works — that's how you grow in an institutional market. Estil County came next, then Metcalfe County. The fourth district came from a direct outreach based on OpsFlow's growing reputation in the region.

We're now on an annual plan model, building toward a statewide footprint.

What I Would Tell a Founder in the Same Position

If you work in an industry or have a close relationship with someone who does — and you keep hearing about the same operational problems — that's a signal worth taking seriously. Most people hear those complaints and move on. Engineers hear them and start designing systems.

• The relationship is the moat, at least early on. Your first customer doesn't come from a landing page.
• Build for production from day one. The temptation to cut corners early creates compounding technical debt that will cost you twice the time later.
• Let the problem define the scope, not the other way around. Don't build features because they're interesting. Build what the customer is actually blocked on.
• Institutional markets move slowly — but they're sticky. Once a district or a hospital system or a manufacturing firm adopts your tool, they don't switch.

OpsFlow is not finished. No good software product ever is. But it's real, it's in production, and it's making the jobs of real people easier every day. That's the only metric that matters at this stage.