Sydney software studio

Software that delivers real value.

We build web and mobile products, wire AI into the work your team already does, and stay on after launch. We also ship our own product, so we know what it costs to get one right.

See the work
Based in
Sydney, Australia
Our own product
CACXI: AI receptionist for trades
Talk to a person
+61 406 104 350

Our own product

CACXI answers the phone so you don't have to.

Tradies lose jobs to voicemail. CACXI picks up every call around the clock, books the job, and texts the customer a reminder, then writes it into the calendar the business already uses. It runs on Australian trade businesses today.

  • 24/7 call answering, in a voice that sounds like the business
  • Books jobs and syncs both ways with Google Calendar
  • SMS reminders, website chat, and an optional dedicated number
The CACXI booking flow on a phone beside its dashboard, showing a week of jobs already booked in.

See how we work

A short walk through how a project runs, from the first call to handover.

Video slot: intro 1920 × 1080 · MP4 (H.264) + a poster frame

What we build

Four kinds of AI work

Most engagements are one of these. The interesting ones run across two.

01

Voice

Agents that answer the phone

Real-time voice that holds a conversation, works out what the caller wants, and writes the result into the systems already running the business. We run one in production for Australian trade operators: telephony, turn-taking, and a tool call into a live calendar.

How the voice stack works

02

Automate

AI wired into work you already do

Quoting that drafts itself. Inboxes that get triaged. Documents that extract their own fields. We start from a process you already run, automate the part that eats hours, and leave the rest alone.

Where automation pays off

03

Knowledge

Assistants that answer from your data

A model that has read your documentation, your catalogue and your past jobs, and answers from those rather than from the internet. Retrieval first, generation second, with the source attached so any answer can be checked.

How retrieval works

DocsChunksVector DBAnswer+ sourceQuery
04

Devices

AI and connected equipment

Connected equipment produces a constant stream of readings that mostly nobody reads. We build the layer that collects it, decides what matters, and acts, routing into the systems and the people already handling the work. The same engineering as everything above, pointed at hardware.

What device work involves

EquipmentGatewayModelAction

Engineering

How we build AI systems

The distance between a demo and something a business can depend on is mostly what happens when the model is wrong.

InputRetrievalModelToolsGuardrailsObservability: every turn logged, every failure traceable InputRetrievalModelToolsGuardrailsObservabilityevery turn logged
Retrieval first
The model answers from your documents, your catalogue and your history, not from whatever it absorbed in training. The source travels with the answer so it can be checked.
Tools, not chat
The useful part is the model calling into systems that already run the business: look up the customer, check the slot, write the booking back.
Explicit guardrails
Boundaries on what it will attempt, and a refusal path when a request falls outside them. Answering “I don't know” is a feature, not a gap.
A plan for wrong
Every system gets a fallback and a hand-off to a person. The model is never the only thing standing between a customer and an answer.
Logged end to end
Every turn recorded and inspectable. When something misfires you can see which step failed instead of guessing at the model.

Tools we use

  • Next.jsNext.js
  • ReactReact
  • WordPressWordPress
  • WebflowWebflow
  • SwiftSwift
  • AndroidAndroid
  • n8nn8n
  • OpenClawOpenClaw
  • LangChainLangChain
  • GrokGrok
  • Google CloudGoogle Cloud
  • LighthouseLighthouse

How a project starts

No lock-in before anyone understands the problem.

  1. 01

    A call

    Half an hour. You describe the problem; we tell you honestly whether it's one we should take, and what usually goes wrong with work like it.

  2. 02

    Scope in writing

    What we'd build, in what order, and what it costs. Written down before anyone commits, so you can take it to someone else if you want to.

  3. 03

    Build in the open

    You see working software early and often, not a slide deck at the halfway mark. You own the code and the accounts throughout.

  4. 04

    Stay on

    Software rots without maintenance. We keep the things we build patched, monitored and updated for as long as you want us there.

Got something that needs building?

Tell us what's not working. We'll tell you whether we're the right people for it.