One documented client engagement and three products our founder built and ran himself. Each is labelled for what it is, so you can judge the evidence on its own terms.
Many consulting sites fill a case study page with anonymised stories about "a Melbourne manufacturer" or "a national retailer" that nobody can check. We do not do that. A case study is a claim about our work, and under the Australian Consumer Law it has to be true and supportable.
So every entry below carries one of two labels. Client engagement means work we delivered for a named client, documented in a published case study. Founder's own project means a product our founder designed, built and operated himself. Those projects show technical depth and production experience. They are not client endorsements.
Seymour Whyte is a Tier 1 infrastructure contractor in the VINCI group. Its national sustainability team was collecting emissions data from dozens of projects through personal spreadsheet templates, email attachments and SharePoint folders with no common structure. Each quarterly report meant weeks of chasing, consolidating and converting units by hand.
The solution was built on tools the business already owned: one standardised Excel template with validation built in, a SharePoint folder structure replicated for every project, an overnight process that consolidates submissions and applies Australian Government NGER emission factors, and a Power BI dashboard with corporate, regional, project and data quality views. The data quality view shows which projects have not submitted, so regional managers see the gaps without anyone sending reminder emails.
Delivery ran over four weeks, from discovery through template design, the consolidation build and dashboard training, followed by documentation, knowledge transfer to internal IT and 30 days of post-implementation support. The case study reports the system was built in 2022 and is still in use, and sets out the before and after measures in full.
This pattern applies well beyond construction. Any business where reporting data arrives as spreadsheets from many sources, whether for finance, safety, emissions or operations, has the same problem. Climate disclosure is one place it is now urgent; see our posts on AASB S2 for Group 2 entities and the Safeguard Mechanism. Because the solution ran on SharePoint, the same permissions questions in our Copilot readiness work apply to reporting sites like these.
Products our founder built and ran himself. Each page carries a transparency note. They show how we design, build and operate AI systems in production.
A multi-agent pipeline that reads utility bills from many suppliers and extracts usage, billing periods and meter details for carbon reporting. Separate stages classify, read, extract, validate and normalise each document, then keep an audit trail back to the source. The lesson that carries into client work: in document automation, being able to show where a number came from matters as much as extraction accuracy.
Read the project pageA self-hosted investigation tool for support teams. It runs local models through Ollama in a Docker container, connects to Jira, Redmine, Git and SQL or MongoDB databases, and indexes documentation and past incidents to suggest likely causes. Nothing is sent to an external AI service. It showed that useful on-premise AI can run on an ordinary server with quantised models.
Read the project pageBefore the current Solve8, our founder built a workforce management platform for Australian field service businesses, covering rostering, time tracking, mobile check-in and Fair Work documentation. It grew from one plumbing customer to more than 1,500 active users, and it is still running. It is the source of our practical experience with production incidents, technical debt and Xero and MYOB integrations.
Read the project pageTaken together, they cover the problems most of our engagements start from. Reporting data that arrives in inconsistent spreadsheets. Documents that someone retypes into another system. Information that cannot be sent to a public AI service. Systems such as Xero, MYOB, Jira and SharePoint that do not talk to each other.
They do not prove what AI will do with your data, your staff and your systems. Nobody's case study can. That is why our engagements begin with a scoping conversation and, where the risk justifies it, a bounded proof of concept on your own data before a full build. If you are still deciding where AI fits at all, our AI strategy work starts earlier, and our guide on choosing an AI consultancy lists the questions worth asking any provider, us included.
Our principal consultant also brings 18 years on projects for BHP, Rio Tinto and Senex Energy, gained while working with previous consulting employers. These companies are not Solve8 clients, and that work is not presented here as Solve8 case studies. It is the background behind our integration and data sovereignty advice. More about the team is on our about page.
Book a 30-minute scoping call. Tell us where the manual work, the reporting delays or the data risk sits, and we will tell you honestly whether we are the right fit. Engagement options are on our pricing page.