# Turning a Homegrown Lead Tool Into a SaaS Opportunity

Gault Family Companies had an aging lead system, deep home-services expertise, and a chance to modernize internal software into a product for businesses like theirs.

Published: June 1, 2026
Tags: Case Study, Internal Tools, Product Engineering

Canonical URL: https://michaelrispoli.com/blog/gault-family-lead-management-system/

Gault Family Companies is a local oil, gas, and home-services delivery company with a very real software story.

Like a lot of long-running businesses, they had built and collected a large amount of software over time. Some of it was homegrown. Some of it came from third-party tools. Some of it worked because a few people knew where the bodies were buried. The company had a small software team supporting a large operational footprint, and the stack was starting to show its age.

One of those homegrown tools was lead management.

Replacing it with a generic tool was on the table. So was integrating more deeply into systems like HubSpot and other internal platforms. But that would not have solved the deeper problem. Gault was not just trying to track leads. They were trying to modernize how software was built, deployed, integrated, and maintained inside the business.

They were also sitting on a product idea.

For years, they had talked about building a SaaS product for home-services companies like theirs. A product that could manage leads with the domain awareness generic CRMs rarely have. The lead-management rebuild became a good place to test that thesis. Gault knew the business. My role as fractional CPTO, alongside my team, was to help turn that expertise into product strategy, architecture, and working software.

The first hard problem was the customer record.

In a lot of software, a customer is a person or an account. In home services, that is not enough. The real center of gravity is often the home address. Even that is too simple, because an address may contain multiple dwellings in the case of apartment buildings or multifamily properties.

Then the contact model gets complicated. Sometimes the contact is the owner. Sometimes it is a tenant. Sometimes it is a loved one or caregiver. Sometimes the person calling is not the person receiving service. If the software treats all of those as the same thing, the business pays for that abstraction later.

Lead sources were just as important. Leads did not only come from sales people or web forms. They came from boots-on-the-ground service people who saw real opportunities in the field. Those leads had to be delegated differently depending on the team, the brand inside the company, and the kind of work involved.

That is the kind of detail generic CRM thinking usually flattens.

We worked through it in a forward-deployed way: in the office, with engineers, stakeholders, and sales people. The job was not to disappear into a requirements document and return with software. The job was to sit close enough to the business to see how the work actually moved.

The product had to do two things at once. It had to serve Gault's immediate operational needs, and it had to avoid becoming so Gault-specific that it could never be deployed into another home-services company. That balance is hard. Too generic and the product loses the domain value. Too specific and the SaaS opportunity disappears.

The technical choices followed that same principle.

We chose Ruby on Rails for the core solution because Gault needed durability more than novelty. They had experimented with newer JavaScript frameworks, but the turnover rate of frontend tooling was moving faster than the company's internal software maintenance rhythm. Rails gave the team a stable, traditional mental model: the server owns the application, renders HTML, models the domain, and exposes clear endpoints.

That did not mean the interface had to feel old. Hotwire and Turbo gave the product modern interactivity without forcing the team into a complex frontend stack that would be harder to maintain over time. The result could feel fast and current while still being built on a framework with a long shelf life.

The modernization mattered beyond the screens.

Gault was used to older integration patterns, like reading from a read-only Microsoft SQL database on an on-prem machine to generate reports. That kind of architecture can work for a long time, but it also hardens into a fragile way of thinking about data access.

The new system moved toward modern integration primitives. Data would be exposed through proper REST API endpoints. Systems could sync through webhooks. The code would live under version control. The test suite would protect behavior. CI/CD would make deployment a normal part of the development process instead of a special event.

That is a bigger shift than swapping one lead tool for another.

It is the difference between a tool that only solves today's workflow and a product foundation that can support a new business line.

For founders, this is the lesson: the best SaaS ideas often come from companies that have lived the workflow long enough to know where generic tools fail. But domain expertise is not enough by itself. You still need product discipline. You need to decide which details are essential, which are accidental, and which technical choices will still make sense when the first version has to be maintained by a real team.

A good lead-management system is not a table of prospects. For a home-services business, it is a model of places, dwellings, people, field activity, brands, teams, delegation, and follow-through.

Once the software understands that, it stops being an internal replacement project and starts looking like a product.