Why We Open-Source Some of Our Tools (And Keep Others Private)

There's a question we get asked surprisingly often, usually by other developers but sometimes by clients too: "Why do you give some of your tools away for free?" It's a fair question. We spend real time building these things. We could keep everything behind closed doors, charge for access, and treat our entire codebase as a trade secret. That's what most businesses do.

But we don't. Some of what we build, we share openly — the source code, the implementation details, the architecture decisions. And some of it, we keep private. Not because we're being inconsistent, but because we've thought carefully about which is which, and why.

What we share openly

Let's start with what we give away, because it's the part that seems to confuse people.

Voice dictation

Our voice dictation system is a push-to-talk dictation tool we built for clinical note-taking. It runs on macOS and Windows, uses local speech-to-text, and pastes transcribed text directly into whatever application you're working in. We use it every day in the practice.

Why share the approach? Because voice dictation is a universal problem. Dentists need it, lawyers need it, GPs need it, anyone who writes notes while their hands are busy needs it. The existing options are either expensive (Dragon Medical at $1,500+ per seat), cloud-dependent, or both. We built something better for our own use.

A developer in Berlin who uses local dictation to dictate code comments was never going to be our client. A physiotherapist in Perth who uses it for session notes might be — but they'll remember the company that shared a genuinely useful approach for free. That's a relationship, even if it never becomes a contract.

Technical blog posts with real implementation details

We write about how we build things. Not vague thought leadership pieces about "the future of AI" — actual implementation details. How we automated our email inbox. How we run AI locally on a Mac Studio. How our orchestration patterns work. We share the architecture, the decisions, and sometimes the code.

This might seem like handing our competitors a playbook. It's not, and we'll explain why shortly.

Architecture patterns and approaches

The broad strokes of how we design systems — our framework for separating decision-making from execution, our approach to local AI infrastructure, our patterns for integrating with practice management software — we share all of this openly. The "how" of building AI tools is not a secret. It's well-documented in research papers, open-source repositories, and technical blogs across the industry.

The value isn't in knowing the pattern. It's in applying it to a specific business, with specific constraints, in a specific context. That's the part that can't be copied from a blog post.

What we keep private

Not everything is shared, and it's worth being transparent about what stays behind the curtain and why.

Client-specific integrations

When we build something for a client, it's theirs. The integration between their practice management system and their AI tools, the custom workflows we design for their specific operations, the way their data flows through their systems — that's private by default. It's built for one business, it reflects that business's unique needs, and it belongs to them. We've written before about why custom-built AI differs fundamentally from off-the-shelf tools, and ownership is a big part of that story.

Our internal orchestration layer

We share the patterns, but not the specific glue that connects everything in our own systems. The orchestration layer — the part that decides which AI model to call, when to escalate, how to handle edge cases, how to route information between services — represents years of refinement. It's the difference between knowing that you need a conductor for an orchestra and actually being able to conduct one.

Proprietary prompts and training data

Every prompt we've written has been tested, revised, broken, fixed, and refined through real-world use. The prompt that classifies incoming emails with 98% accuracy didn't start at 98%. It started at 70% and got better through hundreds of iterations, each one informed by a real misclassification in a real inbox. That accumulated knowledge — knowing that "please find attached" in an email from a pathology lab means something completely different than the same phrase from a stationery supplier — is genuinely hard-won. We keep it.

How we decide: four questions

We don't agonise over every decision. We've distilled it down to four questions, asked in order:

1. Does sharing this hurt our competitive advantage? If no, share it. Most of what we build doesn't derive its value from secrecy. Our dictation system isn't valuable because nobody else knows how to build a dictation app. It's valuable because it works well and it's free. Sharing it doesn't diminish that.

2. Does sharing this build our reputation? If yes, share it. Every technical blog post, every open-source tool, every architecture discussion we publish is a demonstration of competence. It's proof that we actually build things, not just talk about building things. In a market full of AI consultancies who can't show their work, showing your work is a significant differentiator.

3. Is this useful to people who will never be our clients? If yes, share it. A developer in Hamburg using our dictation approach isn't a lost customer — they were never going to hire an Australian AI consultancy to automate their dental practice. But they might mention us to someone who will. Or they might find a bug we missed. Or they might build something interesting on top of what we've made. None of that happens if we keep the tool locked away.

4. Is this deeply integrated with our specific systems? If yes, keep it private. Not out of secrecy for its own sake, but because context-dependent code is useless without the context. Our email classification prompts won't work for your business. Our orchestration layer assumes our infrastructure. Sharing it wouldn't help anyone, and it would expose the specifics of how our systems work internally.

Why generosity is good business

There's a cynical way to read all of this: we share things strategically to attract clients. That's not untrue, but it's not the whole picture either. The deeper reason is philosophical.

Open-source builds trust. When a potential client can read our code, see how we think about problems, and verify that we actually build what we claim to build, the sales conversation is different. We're not asking them to take our word for it. The work is right there. In an industry where plenty of companies talk a big game about AI but couldn't show you a single line of code, transparency is its own credential.

It demonstrates competence through abundance. If we can afford to give our dictation system away, what does that say about the tools we build that we don't give away? It signals depth. It says: this is the stuff we consider table stakes, the baseline, the thing we'll hand out for free. Imagine what we build when we're actually trying.

It creates community, even a small one. People use our tools. They find bugs. They suggest improvements. They ask questions that force us to think more clearly about what we've built. That feedback loop makes everything better — including the private tools, because the lessons transfer.

It attracts the kind of people we want to work with. Clients who value transparency and knowledge-sharing tend to be better clients. They're collaborative, they give honest feedback, and they understand that building good software is iterative. The blog posts and open-source tools act as a filter — they attract people who think the way we think.

The key insight

Here's the thing that makes this whole approach work: our value isn't in the code. It never has been.

Our value is in understanding your specific business — your workflows, your bottlenecks, your staff's habits, your patients' expectations — and building exactly what you need. That's not something you can download from GitHub. It's not in a blog post. It's not in an architecture diagram. It's in the conversation where you tell us that your front desk spends forty minutes every morning sorting through emails, and we design a system that does it in thirty seconds with 98% accuracy.

The code is the easy part. Knowing what to build, and for whom, and why — that's the hard part. And it can't be open-sourced, because it's different for every single client.

As we've looked at where AI is heading for Australian businesses, one thing has become clear: the companies that will thrive aren't the ones hoarding information. They're the ones who understand that knowledge shared is trust earned, and trust is what turns a curious visitor into a long-term client.

We'll keep sharing what we can. We'll keep building what we must. And if you're wondering what we could build specifically for your business — the private, custom, nobody-else-has-this kind of tools — we'd love to have that conversation.