Three engagements from the current practice.

Summary

A Tasmanian general aviation operator approaching fifty years of continuous operation — flight training, charter, scheduled regional flights, wilderness scenic tourism, university-partnered pilot training — running out of their own aerodrome near Hobart across a thirteen-aircraft mixed fleet. I've been building and sustaining their custom operations stack for over a decade.

Context

Aviation at this shape runs on compliance, tight rostering, and accurate weight-and-balance calculations across every flight. Commercial charter, pilot flight training, a university-accredited aviation degree pathway, regulated scheduled services, and wilderness tourism each drag their own obligations. The spreadsheet-and-paperwork baseline didn't scale as the charter, flight-school, and tourism sides of the business grew in parallel. No general-purpose product was going to fit the operational surface and the Australian aviation and vocational-education compliance obligations simultaneously.

What was built

• Flight operations module

  Duty rosters, weights and balance, pilot endorsements, scheduling. Wisej 3 on .NET 7 for the desktop-web surface; Blazor WASM on .NET 9 for newer modules.

• Mobile training app

  Originally Xamarin.iOS; since evolved into modern Blazor WASM.

• Training and compliance module

  Course management, fee schedules, AVETMISS reporting for Australian vocational-education obligations.

• Integrations

  Operational email, safety-critical weather feeds, finance, SMS, payments, online travel agents, aeronautical data, and higher-education compliance — every external system the business depends on, flowing through one platform. Microsoft Graph, Gmail, BloomSky, Xero, ClickSend, Stripe, Viator, Rezdy, GetYourGuide, NAIPS WCF, and TCSI/HEIMS underneath.

• Scale

  Built to operate at the scale and with the safeguards a multi-modal aviation business needs. 56,110 flights, 1,375 students, and 38,731 lessons through the platform — with property-level PII encryption, soft-delete across all entities, a MongoDB audit trail, and three parallel UI generations coexisting deliberately. 322,000 lines of C# across 866 files underneath.

Outcome

A decade-old custom platform still shipping new features. Three successive UI architectures have layered in without a rewrite — the older modules keep working while the new ones go in beside them. Operations, training, compliance, and tourism bookings all flow through the same stack.

Summary

A Tasmanian-owned managed IT services provider approaching thirty years of operation — around twenty-five staff across two offices, a mixed client book spanning corporate, small-business, and not-for-profit, from a state-level sporting franchise to a statewide aged-care group. Nineteen external vendor billing systems needed to reconcile into Jiwa each month and stay in step with Halo PSA for ticketing. I built the plugins, the feeds, and the reconciliation loop.

Context

An MSP's economics depend on accurate pass-through billing. Each vendor — Kaseya, FortiEDR, Microsoft 365, Leap, Kaseya VSA, TasNetworks, Veeam, Crayon, Cloudian storage, several telecoms — ships usage and licence data in its own format on its own cadence. The baseline was a monthly spreadsheet reconciliation exercise. The cost was visibility, speed at month-end, and tickets drifting out of sync with billing.

What was built

• Jiwa plugins

  For recurring billing renewals and debtor maintenance.

• Nineteen external billing feed integrations

  Each vendor's feed normalised to the internal model; invoice lines generated per client per month.

• Halo PSA bi-directional integration

  Tickets, clients, and billing stay in step across the two systems.

• Toner and print usage tracking

  Consumables billed from actual device telemetry, not estimates.

Outcome

Nineteen vendor feeds reconcile into a single Jiwa-driven monthly invoice across the full client book. Halo PSA stays in sync; support tickets and billed hours no longer drift apart. Reconciliation is verified to the cent.

Summary

A Tasmanian-owned industrial-trade supplier of nearly four decades — industrial and hospitality gases, PPE, workwear, power tools, abrasives, height-safety gear — running three branches across Hobart, Launceston, and Burnie, ISO 9001 certified, supplying fabrication, construction, and manufacturing clients statewide. Their Jiwa ERP needed to carry customer-specific pricing matrices, default-supplier automation, a gas-supplier data feed, and daily multi-branch sales reporting. Still active.

Context

A mid-market distribution business at this shape runs on pricing rules that look simple from a distance and aren't. Every customer sits in a pricing band. Every branch has its own stock reality. Every product category has a default supplier the sales team can override but usually doesn't need to. The reporting has to reflect daily sales across three branches, reconciled against supplier-side data for the major gas partnership. Standard Jiwa covered part of it; the custom surface covered the rest.

What was built

• Twenty-seven Jiwa plugins

  Spanning pricing matrices, default-supplier logic, and the operational UI injections the sales floor and back office use every day.

• Twenty-eight SQL scripts

  Covering reporting, reconciliation, and data-quality audits across the three-branch footprint.

• Gas-supplier integration

  Keeping product, pricing, and availability data in step with the external partner's feed.

• Daily sales reporting

  Branch, customer, and product-category breakdowns delivered overnight rather than rebuilt at month-end.

• SQL Agent job suite

  Handling the overnight reconciliation, report generation, and data-integrity checks.

Outcome

Pricing consistency across three branches. Default-supplier selection made automatic, with manual override where it's needed. Month-end reporting becomes a daily delta, not a rebuild. The engagement is still active — plugin and reporting work has continued through 2025.