How Oasis Pavers & Pools built a system that fit the way its team worked

Oasis Pavers & Pools is a family business that has built custom pools and paver work around St. Petersburg, Florida, for twenty years. Owner Brian Godden described a team of twenty-five people, fifteen of them project managers, and an average job around $85,000. When he contacted Byte Bot, the office was using a partly completed system whose reports he found difficult to rely on.

Our first job was to understand how the office used it. A lead record, a contract, and a payment request were parts of the same job, but different people were responsible for moving each one forward.

The earlier software projects

Brian had worked with three developers on earlier versions of the office system. He said none had visited the office. One rewrite had been quoted at four weeks and took a year and a half. Describing two and a half years and about a thousand hours of work, he told us on our first call, “it’s functional, but it’s not recording that accurately.”

The company’s COO at the time was also managing the software work. She described spending hours each week explaining the business to developers and testing what came back. When something did not fit, she would ask them how it should work. She said the response was often that the change fell outside the scope.

Brian described a pattern in which individual requests were implemented without enough consideration of how a change affected other people’s tasks and records. His concern was how those features fitted together across the office.

Spreadsheets and paper contracts

Brian described entering each lead twice, once into a color-coded spreadsheet and once into the system, so the office could compare the records. “I used to love Excel,” he said, “until I ended up getting big enough to have thirty-two Excel spreadsheets to accomplish the same task.”

Reception checked flood zones on the FEMA website and assembled the disclaimers Oasis used for each location and type of work. The same disclaimer fields had to be rebuilt in Dropbox for each contract. Contracts went out through a separate signing tool and were marked signed by hand afterward. The COO said she compared the system’s quarterly reports with the paper records and found differences.

In our September interview, Brian walked through an earlier paper-contract process. Reception assembled the required documents into a folder, the customer came to the office to sign, and reception scanned the signed pages back into a PDF. The deposit was another step, still to be completed. Moving the folder from reception to accounts was also how people knew it was their turn to act. If that notification was missed, work such as starting the permitting process could be missed too. The paperwork carried both the records and the instructions to the next person.

Brian had also tried to buy an existing product. He said he had spent at least forty hours evaluating one platform, but found it overly complex for Oasis’s day-to-day work. Configuring it to fit the business would have taken more effort than he considered worthwhile. More recently, he had paid a consultant $2,500 to find a product he could rent monthly and leave if necessary. According to Brian, she had not found one that fit Oasis’s work.

The first calls, a demo, and an office visit

We started with two long calls in December with Brian, his COO, and Thommi from accounts. The COO walked us through the old system, screen by screen. We wrote down how Oasis moved a job from the first lead through contracts and payment, and who was responsible at each step. Brian marked up those notes so we could check our understanding.

We used the recordings from those calls to build a working demo before Oasis signed the build contract. A few weeks into the build, Brian described what seeing it had meant to him. “You guys basically let me drive the car before I got my checkbook out.”

When we spoke after launch, Brian returned to that moment. “That demo was key.” He had been advised to start with a small task and evaluate the result first, but said the conversations and demo convinced him to proceed with the larger build.

Once the build was under way, both Byte Bot founders and Cameron, the engineer who built most of it, spent two days in the Oasis office. We sat with the receptionist, watched the project managers work live leads, and asked people which parts of their work took time or caused difficulty.

Brian still spent time explaining Oasis’s processes and reviewing the system as it took shape. He had worried that another rewrite would require someone who knew the business to manage the project full time. He said the office visit helped reduce the time he needed to spend guiding the rebuild compared with the previous attempt, though it still required a substantial commitment from him.

Building and testing the system

The price was fixed, with a deposit at signing. Development was split into six milestones after kickoff, each with its deliverables written down, and each invoiced only after Brian accepted it.

Ten days after kickoff, Oasis decided to focus the system on the office. We removed crew scheduling from scope and reassigned the estimated development time to other office work.

During development, we shared early versions with the people who would use the system, knowing there was still substantial work ahead. We wanted staff to try the workflow, tell us where it did or did not fit, and help shape what we built next. We wanted that involvement to improve the system and build support for the switch before launch.

As Brian put it, “if you try to give us everything that we wanted day one, it wouldn’t have been everything that we wanted.”

In June, we built a permit-tracking feature that the Oasis team did not want. We had scoped it incorrectly and discarded two weeks of development.

We also needed to be clear about what was ready to try and what was still being developed. Brian recalled being told that some functions and data were not yet ready, and that there were hiccups in how those expectations were understood. Hunter acknowledged that we could have explained the state of each version more clearly up front.

Between reviews, Brian said the team explained which concern it was working on and discussed whether another item could wait until the following week. Later in the interview, Hunter distinguished acknowledging a concern from reporting that the fix was complete. Brian agreed that knowing Cameron had seen a concern made it easier to wait for the fix.

Leads, contracts, and payments in the new system

Oasis combines custom pools and hardscape in one job. Its project managers are also its salespeople, and the records of their work affect their pay. The system needed to keep leads, contracts, and commission information connected as jobs progressed, changed, or were cancelled.

The system automatically assembles a contract from the job details, using the municipality, flood zone, and type of work to add the appropriate documents and disclaimers. Signature fields are already positioned in the templates, ready for staff to review and send.

Contract signing and payment requests are linked to those job records. Staff can prepare a contract for signing on a tablet, follow its status, and request a milestone payment through the QuickBooks connection. Staff record payments or the system matches them with QuickBooks records, with unclear matches left for review. Payment requests and received payments have separate states, so sending an invoice does not mark it as paid.

Brian said a previous signing service had increased its price to about $1,000 a month. He wanted to avoid depending on a service he could not readily leave. We included a signing integration alongside Dropbox Sign, so staff could prepare documents and follow their signing status from the office system.

The recreated workflow below uses sample names and amounts to show the record structure. A pool agreement and a later signed change belong to one job; a driveway quote remains separate.

Preparing for the August launch

The contract had set June 29 as the launch date. The QuickBooks connection took longer than planned. Oasis used QuickBooks for invoicing and payments, so the office needed that connection working before switching systems. It was still being fixed in the last week of July. The build exceeded our estimated hours; the agreed fixed price did not increase.

Before launch, Brian’s team spent three half-days in training and two more days trying to find problems in the system. On the Friday before a planned Monday launch, he wrote that he needed more confidence in its readiness. We reviewed the remaining concerns together and agreed to delay the switch.

Cameron sent a line-by-line status of the open items and closed about sixty over the next three days. The following week, the migration was rerun and checked against the old system’s records. The office began using the new system on Monday, August 10, six weeks after the date in the contract.

The first weeks in the office

By the September 4 interview, Brian reported that project managers were using the system in their daily work. Leads, estimates, contracts, change orders, and payment requests ran through it.

Before the rebuild, staff walked from office to office to pass on updates and start the next step. Three weeks after launch, Brian described those updates arriving as alerts. “I keep my alerts on, man. Contract signed, deposit received.” The next person could act on the update without waiting for someone to bring them the news.

In the September interview, Brian explained why he had expected resistance. People had to learn the new system while still doing their current jobs. He credited involving project managers, accounting, and reception throughout development, letting them try different parts and compare them with the old system.

“I think everybody was really excited … they were all included.”