The products on the market almost fit, and the workarounds have become a job of their own. Or the system the last developer built still runs the business, nobody can change it, and everyone’s nervous to touch it.
I write software, from small internal tools up to full web applications: the code that connects one system to the next, software that lets an AI assistant do useful work in your own systems, and software that collects data from equipment in the field. I come to it from years of running servers, networks and security, including five years as infrastructure manager for a global cyber security company, so what I build is designed to run securely and keep running, not just to work on the day it’s shown off.
Software doesn’t need a site visit, so this is the work I do for businesses anywhere in Australia, not only in the Hills.
Browser-based apps for your staff or your customers, that work on a phone as well as at a desk. Sign-in tied to the accounts you already have, an audit trail of who changed what, and updates that install themselves.
Stock, listings, bookings, jobs, schedules: the system that replaces the spreadsheet and the whiteboard, with details captured automatically wherever they can be, so nobody types them in.
Code that connects systems never designed to talk to each other: accounting, email marketing, e-learning, marketplaces, booking feeds, Microsoft 365 and Windows servers. More on the system integration page.
Connectors that let an AI assistant look things up and make changes in your wiki, stock list or job system, within limits you set: read-only until you say otherwise, a preview of every change, and a confirmation before anything is deleted. More under practical AI.
Software that watches things for you: equipment at a remote site, a supplier’s website, your backups, the link between two offices. It reports in, keeps its data through a dropped connection, and sends an alert when something needs a person.
Small field devices, sensors, radios and GPS, read directly and streamed to a dashboard or a map in real time. Useful anywhere the thing you need to know about is out on the property, not on a screen.
The system the last developer left behind. I get it building from source again, review it for security problems, fix what’s unsafe without breaking what people rely on, and write the documentation that was never written.
Admin consoles, automation and reporting for the systems IT people look after: Windows servers, device setup, patching, backups. The same jobs done the same way every time, with a record of what happened.
The parts of software nobody sees are the parts that decide whether it lasts. This is how every job is done, small or large.
Secrets kept out of the code, sign-in with only the access each person needs, everything a visitor sends checked before it’s used, and a record of who did what. Years of locking down servers and networks shape how the software is written.
I plan where it will live, how it’s deployed, how it’s backed up, and what happens when something it depends on goes down. Software that falls over at 2am isn’t finished.
Automated tests on the logic that would hurt if it broke, and checks against the real systems it talks to, not only against a mock-up of them.
A dry run and a preview before anything changes in bulk, a guard in front of anything that can’t be undone, and a backup taken before a migration starts.
Every change is built, checked and released by an automated pipeline, so an update is routine rather than an event, and going back to the previous version is a known step.
A plan before the first line of code, notes as it goes, and documentation at handover. The code lives in a repository you control, written so another developer could pick it up.
Chosen for each job, not out of habit. The simplest thing that’s reliable usually wins.
Some of what I build is published as open source under Leahy & Co, so you can read the code and see how I work before you hire me.
A free chat about what the software needs to do, and what it’s costing you not to have it.
Where it isn’t clear the job can be done, a short feasibility check first: tested against the real systems involved, with a written go or no-go before you commit to a build.
A written quote for a first version that’s useful on its own, small enough to be in use quickly.
Built in steps you can try as it goes, tested, and released through an automated pipeline.
Handover: the code in a repository you control, the documentation, and notes another developer could follow.
A network of medical practices
16 websites on one shared server had been compromised, one after another. I cleaned out the backdoors and rebuilt the server so every site is walled off from the rest, with the whole setup kept in version control.
A network of medical practices
A booking system other developers built years earlier, still running a network of practices every day. I took it over, found and fixed its security problems, and got its source building again, without breaking anything people relied on.
A small business
Customers, contacts, suppliers, a product catalogue and years of quotes moved from an old CRM to a new one, with every link kept and every quote total checked against the old system.
Leahy & Co’s own
A free, open-source web console for Windows Deployment Services: images, devices and drivers in a browser, and a live view of every network install. Published on GitHub.
Leahy & Co’s own
A connector that lets an AI assistant search, read and edit a company wiki, with guard rails that stop it damaging the pages people rely on. In daily use.
Leahy & Co’s own
Every BuiltSite website runs on a hosting platform I built and run: changes go live in minutes, the servers are locked down, and nothing is open to the internet.
Refurbished computer sales
Stock and listings for selling refurbished computers: each machine’s specs read from the hardware, a numbered label on every item, and listings ready to paste into eBay and Facebook Marketplace.
Two holiday houses
A direct booking page that reads its calendar straight from Airbnb, so guests only ever see dates that are really free.
Sometimes, and if one fits I’ll say so before writing any code. Custom software makes sense when your way of working is the point, when the products on the market fight it, or when one would cost more and still not fit.
Yes. I’ll get it building from source, review its security, fix what’s unsafe without breaking what people rely on, and write the documentation that’s missing. Then you decide what happens next, with a clear picture of what you’ve got.
For software, yes. It doesn’t need a site visit, so I work with businesses anywhere in Australia, by video call, email and a shared repository.
When a phone app genuinely beats a web app, yes, for Android. Most of the time a web app that works well on a phone is quicker to build, cheaper to change, and works on iPhones too, so that’s usually where I’d start.
The code and the notes are handed over at the end of the job, in a repository you control.
Wherever suits the job: on your own server or computers, in a cloud account in your name, or inside Microsoft 365. I’ll recommend the simplest option that’s reliable and secure.
Get in touch and I’ll quote the change. Because it’s documented and tested, changes are routine, and another developer could make them too.
A free chat about the problem, then a written quote before any work starts.
