Building software around a business no template fits

Oasis Pavers and Pools has built custom pools and paver work around St. Petersburg, Florida, for twenty years. It is a family business with twenty-five people, fifteen of them project managers, and an average job around $85,000. By the time owner Brian Godden called us, he had been through three developers. A half-finished system sat in the office, and nobody trusted its numbers.

Software for a business like Oasis has to fit the way the office actually runs. A template can cover the common parts. It struggles when the unusual parts all sit on the same path through the business. This story shows what that meant for Oasis, including the parts we got wrong.

Why had three developers already failed?

Brian’s previous developers were not bad engineers. None had spent time in the office, so they built the features they were asked for without seeing the work around those features. One rewrite was quoted at four weeks and took a year and a half. After two and a half years and about a thousand hours, the system worked, but Brian could not count on the numbers coming out of it.

The company’s COO at the time had quietly become its software project manager. She spent hours each week explaining the business to developers and testing what came back. When something did not fit, the answer was often that it was outside the scope.

Brian saw a larger problem. A developer would make one requested feature work without asking what happened before it or what depended on it afterward. Nobody was looking at the whole path.

What was the office doing to cope?

Every lead was typed twice, once into a color-coded spreadsheet and once into the system, because neither copy could be trusted on its own. Brian had once loved Excel. By then, the company had thirty-two spreadsheets doing pieces of the same job.

The receptionist looked up flood zones by hand. A pool contract in Florida needs different disclaimers based on the location, so she checked the federal flood map and rebuilt the required fields for each contract. Signed contracts went through a separate signing service and were marked signed by hand. At the end of a quarter, the office compared system reports with paper records and found differences.

Brian had tried to buy his way out of this. He spent at least forty hours evaluating a large off-the-shelf platform and decided it asked the business to work in the wrong shape. He later paid a consultant $2,500 to find a product he could rent and leave when he wanted. She could not find one that fit.

What did we learn before writing code?

We started with two long calls with Brian, his COO, and Thommi from accounts. The team walked us through the old system screen by screen. We wrote down how the company made money, who did what, and where a job changed hands. Brian marked up those notes until we could explain the business back to him in plain language.

We then built a working demo from those conversations before asking Oasis to sign a build contract. Brian later said it felt like being allowed to drive a car before getting out his checkbook. That demo did not prove we could deliver the whole system. It gave him something concrete to question before he made the larger decision.

During the build, both Byte Bot founders and Cameron, the engineer doing most of the work, spent two days in the Oasis office. We sat with the receptionist, watched project managers work live leads, and asked which parts of the afternoon they dreaded. Seeing the work made dependencies visible that a feature list had hidden.

How did the milestones make progress visible?

The build had a fixed price and a deposit at signing. After kickoff, the work was divided into six milestones with written deliverables. Oasis was invoiced for a milestone only after Brian had seen and accepted it.

That structure mattered when the plan changed. Ten days after kickoff, Oasis decided the system should run the office rather than the jobsite. We removed crew scheduling from scope and put the saved time into work the office needed more. The decision was visible before months of development accumulated behind it.

The milestones did not prevent mistakes. They made the mistakes easier to name and assign.

What did the finished workflow do?

Oasis combines custom pools and hardscape in one job, while much of the industry’s software treats them as separate businesses. Its project managers are also its salespeople. They own a job from the first lead through payment, and their individual numbers affect how they are paid.

We brought that existing process into one office system. The related job records and their next steps now stay connected.

Project managers keep their leads, contracts, and commission context together. A hurricane cancellation stays in the record but does not distort the closure rate.

Contract signing became part of the office workflow through a signing integration. The custom work addressed what was costing the receptionist time: reusable disclaimer templates, signature fields placed once, and rules that attach the right set to each contract. Staff could prepare the documents and follow their status from the same system.

Where did the build go wrong?

In June, we built a permit-tracking feature, showed it to the Oasis team, and learned they did not want it. That was our scoping mistake. We discarded two weeks of work at our cost.

The accounting connection also took longer than planned. Every Oasis invoice and payment runs through QuickBooks, so that connection had to be reliable before launch. It was still being fixed in the last week of July, and the build ran past the hours we had estimated. The fixed price meant those extra hours stayed on our side.

Brian’s team spent three half-days in training and two more days trying to break the system. On the Friday before the planned launch, he said he needed full confidence before Monday. We worked through the remaining concerns with him and agreed together to delay the launch. Cameron sent a line-by-line status for every open item, closed about sixty items over the next three days, and reran the migration the following week until it matched the old system one to one.

What changed after launch?

Before launch, Brian described an office where people walked from room to room to trigger the next step. After training, he said the new system let them stay with their own work while the status changes moved between them.

A week after launch, he reported thumbs up across the office. Three weeks in, Brian said the project managers had been less resistant to changing systems than he expected. He credited their involvement throughout development. He said the team liked seeing alerts when a contract was signed or a deposit arrived because the next task could begin without somebody carrying the news.

There are limits to that result. Reports were still being tuned against the project managers’ spreadsheets, and the team continued to send us things they found. We do not attach a return percentage to the work. Too many parts of the business were moving at once to separate the software’s effect from everything else.

The useful conclusion is narrower. The system has run the Oasis office since August 10, 2026. Leads, estimates, contracts, change orders, and payment requests move through it. The office can see each handoff, and the rules that once lived in a few people’s heads now have a place in the workflow.

If you are considering a similar build, ask to see the work milestone by milestone. Ask what the firm told its last client not to build. Ask what went wrong, who paid for it, and how everyone knew the system was ready to use. Those answers tell you more than a polished feature list.