Building my own software for my painting business

By Theodore Vairaktaris

I didn’t set out to build software. I just wanted my painting business to stop being a disaster.

I’m a second-generation painter. I grew up around job sites; the smell of fresh paint, the hum of spray machines, radios playing somewhere in the background while people worked. Painting wasn’t something I stumbled into later in life. It was simply the environment I grew up in.

As a kid I’d tag along with my dad to jobs. At the time I didn’t think much about it. It was just normal life: ladders leaning against walls, drop sheets everywhere, half-empty coffee cups sitting on window sills while people argued about which color the client had actually approved.

What you notice when you grow up around trades is that the work itself is only part of the job. The painting might take a week, but everything around it can take months: quoting the work, meeting the client, organising the crew, ordering materials, scheduling around other trades, chasing payments, fixing problems when something inevitably goes sideways.

The job site is the visible part of the business. Everything else is the invisible machinery behind it.

When I eventually stepped into running more of the business myself, I assumed the hardest part would be the painting; managing crews, delivering quality work, keeping clients happy. But very quickly it became obvious that the real challenge wasn’t the trade. It was the management.

Quiet Chaos

From the outside, our business probably looked like it was running well enough. Work was coming in, jobs were getting completed, and clients were generally happy. But from the inside, it often felt like organised chaos.

My days became a blur of quoting work, visiting sites, managing crews, answering calls, and dealing with whatever unexpected problem had decided to appear that afternoon. One day you’re pricing a new project; the next you’re standing on a job site trying to understand why work that was supposed to take four days is suddenly stretching into its second week.

Sometimes the numbers at the end of the month looked healthy. Other times they didn’t quite make sense, and I couldn’t always explain why. Cash flow had a habit of surprising us.

Jobs that looked profitable when we priced them sometimes ended up delivering thinner margins than expected. Labour hours drifted, materials crept up, and a client would add “just one more thing” that somehow turned into half a day of extra work.

None of these things seemed dramatic on their own, but together they quietly chipped away at profitability. And the frustrating part was that by the time I realized it, the job was already finished.

Spreadsheet Hell

I remember one project where we were convinced we’d priced it perfectly. The numbers looked great in the quote, the labour hours made sense, and the materials were straightforward. Three weeks later the job was done and everyone moved on.

Months after that, when we finally sat down to look properly at the numbers, it turned out the margin had almost disappeared. No single mistake caused it. The hours had just drifted. An extra hour here, a half day there, a few unexpected trips to the supplier. Nothing dramatic, but enough to quietly erode the profit.

And the frustrating thing was that we hadn’t seen any of it happening while the job was actually running.

That’s when I started realizing something important. The problem wasn’t that we weren’t working hard enough. The problem was that we didn’t have visibility.

Like most contractors, my first instinct was to try and fix this with tools. Spreadsheets became my solution.

At first they were simple. A basic sheet for tracking quotes, another for jobs, another for costs. Over time they multiplied. New tabs appeared, formulas got more complicated, and some spreadsheets had ten different sheets inside them, each doing something slightly different.

I remember opening one of them months later and thinking, “I have absolutely no idea how this formula works anymore.”

But it stayed there because removing it felt risky.

Spreadsheets slowly turned into a kind of fragile ecosystem. Touch the wrong cell and something unexpected might break.

Around the same time, I started experimenting with different quoting and project management systems. On paper they looked impressive: clean dashboards, organised reports, promises of “full visibility.”

But after a few months of using them, I started noticing a pattern. They organised information, but they didn’t help me understand my business.

Quoting software helped produce a professional quote, but once the job started the quote effectively disappeared. Job management software helped track tasks, but it didn’t connect those tasks back to the assumptions we’d made when pricing the work. Accounting software told us what had already happened financially, but by the time the numbers appeared the job was long finished.

Each system worked well enough on its own, but none of them spoke the same language.

Information lived in separate worlds–quoting in one place, job management in another, financial reporting somewhere else again. If you wanted to understand the full picture of a project, you had to mentally stitch everything together yourself.

Which meant the most important insights often came far too late.

Building Software

For a long time I assumed the solution was better discipline. Maybe if I updated the spreadsheets more consistently, or if the team tracked hours more carefully, everything would eventually make sense.

But eventually I realised something uncomfortable. The problem wasn’t just how I was running the business. The problem was the tools themselves.

Most software used by contractors isn’t built by people who’ve actually run contracting businesses. It’s either adapted from accounting platforms or designed by teams that have never stood on a job site trying to understand why labor hours suddenly blow out halfway through a project.

Construction businesses don’t operate in neat, predictable flows. They’re messy. Weather changes things, clients change their minds, and other trades run late. Suddenly your perfectly planned schedule is no longer perfect.

Software designed in a boardroom doesn’t always reflect that reality.

So contractors end up doing what we did: stitching together multiple systems just to keep the business moving. Each one works independently, but together they create confusion.

What I really wanted wasn’t another tool. I wanted clarity. I wanted to open something and quickly understand what was happening across the business; which jobs were healthy, which ones were drifting, where the hours were actually going, and whether the assumptions we made during quoting were still holding up once the work began.

That’s when a slightly ridiculous thought started forming: What if we built something ourselves?

At first the idea felt unrealistic. I wasn’t a software developer. My background was painting houses, managing crews, and figuring out why a client’s “off-white” looked suspiciously beige once it hit the wall.

Software development felt like a completely different universe.

But the frustrations kept stacking up, and eventually curiosity got the better of me.

I started sketching ideas. Nothing fancy, just rough diagrams of how information might flow if everything actually connected.

What if the quote didn’t disappear once a job started? What if it became the foundation of the project? What if the labour hours being tracked on site could be compared against the hours we’d originally estimated? What if scheduling, costing, and forecasting all lived in the same system?

At the time these ideas felt almost embarrassingly simple. But surprisingly, none of the tools we were using worked that way.

Eventually I started speaking with developers, and that was its own strange experience. Suddenly I was explaining painting business problems to people who had never been near a job site.

They talked about databases and architecture. I talked about labor drift, crew efficiency, and paint coverage rates. There were moments where it felt like we were speaking completely different languages.

But slowly things started to connect.

The first versions of the system were rough. Sometimes painfully rough. Buttons didn’t behave properly, pages loaded slowly, and certain features worked one day and broke the next. There were moments where I wondered if the whole thing had been a terrible idea.

But even in those early versions, something interesting started happening. For the first time, we could actually see our business more clearly. Quotes flowed directly into jobs. Jobs flowed into schedules. Schedules flowed into forecasts. Instead of re-entering information over and over again, the story of a project simply continued as the work progressed.

And that’s when the real value started appearing. We could see labor drifting while the job was still running. We could spot projects heading off course before they were finished.

Slowly, the surprises at the end of the month started disappearing.

Looking back, it still feels strange that this eventually turned into a software platform called PaintProjex. That was never the plan.

The goal was much simpler. I just wanted to run a better painting business: one with clearer information, better margins, and fewer unpleasant surprises hiding in the numbers.

Tradespeople deserve tools that reflect how their businesses actually operate. Because behind every contracting business is someone doing exactly what I was doing for years: trying to build something steady for their team, their family, and their future.

And if better systems can remove even a small amount of the chaos along the way, that feels like a worthwhile thing to build.

Theo Vairaktaris is the managing director of the Usher Group, one of Australia’s leading painting companies.