SERVICE · API INTEGRATION
Systems analysts who code. 70+ integrations in production for WesHealth, Wesfarmers, Homes NSW, and Infinity Fire.
Most operational pain in mid-market businesses is not a product problem. It is a plumbing problem. This page lays out how we think about integration and middleware, the architecture we deploy, and what it costs to get there.
If you run more than three core systems (billing, CRM, inventory, a booking engine, a POS) you have an integration problem whether you have named it or not. The question is only whether you are paying for it in staff hours, bad data, or lost customers.
The most common shape of that problem is integration sprawl. A business buys Shopify because Shopify is the right tool for retail. It buys Xero because Xero is the right tool for accounting. It buys Zenoti or Mindbody because that is the right tool for bookings. None of those decisions are wrong. The error is assuming that the integrations between them will be solved by an add-on, a Zapier, or a quarterly export. They will not, because the gap between systems is where your specific business logic lives.
Every organisation passes through a threshold where the cost of not having a proper integration layer exceeds the cost of building one. Most find out the hard way. A launch that stalls because two systems cannot agree on a customer ID. A compliance audit that fails because nobody can reconstruct a transaction. A Monday morning where the weekly report is wrong and nobody knows which system to trust.
The honest moment most consultancies skip: middleware is overkill below a threshold. If you run one CRM and one accounting tool with light volumes, you do not need an event bus. You need a Zap, or possibly a CSV. We will tell you that directly. The point at which custom middleware pays back is roughly four or more connected systems, sustained transaction volume above a few hundred per day, or compliance requirements that demand an audit trail. Below that line the SaaS connectors are usually fine. Above it, they break in ways that cost you sleep.
The thesis of this page is simple. For most operations above that threshold, the right answer is not another SaaS tool. It is a thin, owned, event-driven middleware layer that treats your existing systems as peers and gives you one consistent view of what is actually happening in the business.
If that sounds like the problem you are trying to solve, call us on 0431 000 062 or start a conversation below.
You probably do not need middleware because a vendor told you so. You need it when you start recognising yourself in the following patterns.
DIAGNOSTIC
If you recognise three or more of the above, the business case for middleware is already paid for. The question shifts from whether to build it, to how.
Every integration we ship sits on top of the same three-layer pattern. It is not novel. It is what every mature engineering team ends up with. Most operators never get the chance to see it laid out plainly.
Source systems → Paladine middleware → Destination systems. Inputs like Shopify, Stripe, Google Sheets, and Gmail emit events. The middleware processes them. Destinations like Xero, Klaviyo, your internal database, and Slack receive the right data in the right shape at the right time.
Below is what sits inside the middleware layer. None of it is exotic. All of it is necessary, and skipping any one piece is how integrations go from “working” to “production-ready” to actually robust at scale.
Every state change in any connected system fires a typed event. The bus stores it durably. Downstream handlers subscribe to the events they care about. Nothing is tightly coupled. No system has a direct dependency on any other system’s uptime. When Xero is down for two hours, your Shopify orders queue up and replay when Xero is back. No data is lost.
Network blips and vendor outages are not exceptional. They are routine. Every handler we write can safely process the same event twice. A retry is never destructive. A replay is never dangerous. This is the difference between a system that survives Monday morning and a system that ruins it.
Source systems do not speak the same language as destination systems. A customer in Shopify is not shaped like a customer in Xero. An order in WooCommerce uses different identifiers than an invoice in MYOB. The transformation layer is where the translation happens. It is also where most off-the-shelf connectors quietly cut corners, hard-coding mappings that break the moment your business rules evolve. We treat it as a first-class piece of the architecture, with explicit schemas, version control, and tests against real production payloads.
Sometimes events fail in ways the system cannot recover from on its own. A payload that does not match the expected schema. A destination returning a permission error. A timeout that exceeds the retry budget. These events go to a dead letter queue where they wait for human review. They are not silently dropped, which is the failure mode of almost every brittle integration we have rebuilt. Nothing is lost. Someone gets paged. The bug gets fixed.
Every event, every transformation, every retry is logged. When the auditor asks what happened on 14 March at 3:47pm, you open a dashboard and show them. When a customer disputes a charge, you reconstruct the entire flow in under a minute.
We instrument every handler with structured logs, metrics, and traces from day one. When something goes wrong, you do not have to wait for us to add logging before you can investigate. The integrations we ship come with a dashboard showing event volumes, processing latency, error rates, and queue depth. If you have an in-house engineering team, they can hook these metrics into the alerting they already use.
We structure every engagement one of three ways. All three assume you own the source code and the cloud account at the end. None of them include hidden retainers, account managers, or scoping fees disguised as discovery.
Not sure which shape fits? That is what the discovery call is for. Call 02 8964 5333 or book a time below.
Three recent projects. Named clients. Real metrics. Read the full write-ups or reach out if you want to talk to one of them directly. Most are happy to take a call.
No account managers. No offshore team you never meet. You work directly with the two engineers who will build the thing. The first conversation is run by an engineer, not a salesperson. The last conversation is run by the same engineer.
Nicolas Wendell
MANAGING DIRECTOR
Nicolas has been building custom software since leaving school, bringing a lifelong passion for development to every project. Before founding Paladine Systems, he ran his own video game studio and earned multiple accolades in network engineering. Known as a driving force in the custom software world, Nicolas combines deep technical expertise with visionary leadership – guiding Paladine in delivering innovative, enterprise-grade solutions.
Mark Morcom
SENIOR SYSTEMS ENGINEER
Mark is a young prodigy in software development, bringing 5 years of experience to Paladine. Equally at home on the front end and back end, he crafts clean, scalable solutions that power complex applications. Mark’s sharp problem-solving skills and passion for innovation make him a driving force behind Paladine’s most advanced projects.
We do not do nine-month integration programmes. We ship in slices, each one earning its keep before the next starts. A typical first engagement runs four to six weeks and produces a live production integration.
The cadence is built around weekly demos. By the end of week one you have seen the architecture, agreed the scope, and watched the first integration call go through to staging. By the end of week two there is a working version in your environment. The remaining time is hardening, edge cases, monitoring, and handover. There is no big-bang launch at the end. By the time we cut over to production, the integration has already been working for two or three weeks under your supervision.
If your integration is more complex than one source and one destination, the timeline extends. We will tell you exactly how much in week one. No surprises, no scope creep, no surcharges hidden in the maintenance retainer.
Fig 01: Event-driven middleware, deterministic handlers, observable by design.
A single integration runs four to six weeks from kickoff to production. A multi-system Nexus deployment runs eight to 12 weeks. We will give you a fixed-scope quote and a fixed timeline at the end of discovery, not before. Discovery itself takes one to two weeks and is paid as part of the engagement, not invoiced separately.
Yes. Custom integrations are built on Symfony in your cloud account, in a repository you own. Any competent dev team can maintain what we build. For Nexus-hosted solutions, the platform is ours but your data and your business logic are yours. No lock-in either way. If you ever want to take everything in-house, we hand it over with documentation.
Yes. We have built integrations against Xero, MYOB, QuickBooks, Stripe, Stripe Connect, Shopify, Shopify Plus, WooCommerce, Zenoti, Dear Systems, Cin7, Salesforce, HubSpot, Klaviyo, Mailchimp, Homes NSW, Uptick, and many more. If your system has an API or a webhook, we can integrate with it. If it does not, we can usually work around it with a small adapter or a scheduled task.
You get a phone call from us. We monitor the APIs we integrate with, subscribe to vendor changelogs, and run regression suites against staging endpoints. The Run With Us retainer covers schema changes. Vendors break things. We fix them before you notice.
Secrets in a managed vault, not in code. TLS everywhere. Role-based access on every endpoint. Audit logs on every action. Production access requires hardware multi-factor authentication. We have shipped integrations subject to government security review and we treat every project to that standard. We are happy to send our security posture document on request.
Two options. Pay per incident at standard hourly rates, which works fine for low-volume integrations that rarely need attention. Or take a Run With Us retainer (from $6,500 per month) that covers 24/7 monitoring, on-call response, continuous additions, security patching, and a quarterly architecture review.
Polling is what you do when you have no other choice. It wastes API calls, it lags reality by however often you poll, and it makes failure modes harder to reason about because nothing happens at the moment something changes. Event-driven is what you do when the source system supports webhooks, which most modern SaaS does. Polling is a fallback we use for legacy systems and we are honest about its trade-offs.
Call us on 02 8964 5333 or use the form below to book a discovery call. The first conversation is free and is run by an engineer, not a salesperson. We will tell you whether middleware is the right answer for your situation. Sometimes the right answer is something simpler, and we will say so.
