Skip to main content
    Proof
    Aussie Plumbing — ad spend scaled 1.8× with enquiries up 2.1×, so each enquiry cost lessI-ELEC — a 231-page electrician website for Inner SydneyA plumbing lead on Google Ads: A$141 median, 15 accountsSLS Solicitors — cost per recorded Google Ads conversion down 58.48%Wilco Plumbing — a drains-first website, Sydney and NewcastleHow much should a trade business spend on marketing?State Choice Plumbing — a drains, hot water and gas websiteAussie Drains — a 600-page drain website for SydneyAn electrician lead on Google Ads: A$118 median, 7 accountsAussie Electrical — a 650-page electrical website for SydneyThe most efficient ways for a trade business to get leadsEOL Melbourne — click-to-enquiry rate up from 28% to 33.4%A cleaning lead on Google Ads: A$58 median, 14 accountsAlliance Plumbing — ad spend scaled 1.8× with enquiries up 2.1×, so each enquiry cost lessImpress Blinds — cost per recorded Google Ads conversion down 62.63%FixCare Property — cost per enquiry down 56.36%Rubbish Removal WA — cost per enquiry down 53.18%Floral Cakery — cost per enquiry down 49.82%ILLUMINATE Laser Emporium — cost per enquiry down 48.54%Sydney Fence Painting — cost per enquiry down 33.68%Alliance Plumbing — cost per enquiry down 29.6%Gridless Build Solutions — cost per enquiry down 29.16%FacilityWorx — cost per enquiry down 23.62%Cornerstone Roofing — cost per enquiry down 20.47%Council finance — budgeting and workforce designCouncil planning — clearer approvals and reportingCultural audiences — media strategy and creative conceptsCommunity participation — surveys, maps and project pagesPublic-sector research — survey design and analysisPublic art — site studies and visual conceptsRegional identity — visitor guides and wayfinding conceptsCouncil systems — integration and migration planningA pressure washing business — service-led search campaignsA pressure washing business — a clear enquiry journeyA carpet cleaner — Google Ads built around cleaning servicesA roofing company — campaigns for repairs and restorationA CCTV installer — campaigns for security enquiriesA fence painter — search campaigns for specific surfacesA maintenance business — live in 8 weeks, 3 stacks gone5.0 across every Google review$120M+ in media under management250+ active engagements across five countries

    Custom enterprise software Software you own, not software you rent.

    Custom enterprise platforms shaped around your workflows. We plan the integrations, hosting, source-code access and handover requirements with the people who will use and operate the software.

    Division 02 of five · Eight weeks from Excel, WhatsApp and paper job sheets to a live platform · FixCare, NSW · 2026

    Inside the stack

    Seven ways enterprise
    software goes wrong.

    None of these are exotic. They are what we find when an organisation asks us to look at what it is running, and not one of them appears in a vendor demonstration.

    • The product decides how you work

      Every off-the-shelf system carries an opinion about your process. Where it disagrees with you, you change — and the workaround becomes policy, then becomes the reason nobody can explain the process to a new starter.

    • A licence that renews itself

      Seat counts creep, list prices move, and the renewal lands three weeks before the deadline with no comparable alternative built. The decision gets made under time pressure every single time.

    • Integration debt nobody owns

      Nine systems, nine identity stores, nine roadmaps. Each integration is somebody's side project until it breaks, and then it is an incident. The cost never appears as a line item, so it never gets challenged.

    • The spreadsheet that runs the actual business

      There is always one. It holds the logic the software could not, it lives on one person's laptop, and it is quietly the largest operational risk in the organisation.

    • A demo environment nobody can break

      You are shown the happy path with clean data. The questions that matter — what happens at month end, at year end, on the day payroll and the finance cutover collide — get answered in a slide rather than in the product.

    • Bespoke built on something only one person knows

      Custom software written in an unusual framework by a small team is not an asset, it is a dependency on individuals. Mainstream, unexciting technology is what makes a platform supportable by whoever comes next.

    • No source, no keys, no exit

      Ask where the source code is held, who controls the encryption keys, and what a data export looks like. If those three answers are not in the agreement, the platform is not yours in any sense that matters.

    How we build

    Boring technology, owned outright.

    A platform is only an asset if somebody who has never met us can run it. That single test decides the stack, the hosting, the documentation and the contract terms — all of it, before any screen is drawn.

    • 8 wks

      greenfield to production

      A property maintenance platform — job intake, dispatch, customer portal, invoicing and admin console — built and live in eight weeks.

    • Plan

      finance workflows

      Budgeting, workforce and capital-planning concepts with clear approval steps and reporting requirements.

    • Connect

      systems and teams

      Integration and migration planning shaped around the records, workflows and services an organisation needs to keep running.

    • Export

      data access and handover

      Define usable export formats, documentation and ownership arrangements in the project scope.

    • Support

      operating requirements

      Agree monitoring, support responsibilities and availability requirements around the workload.

    • Recover

      continuity planning

      Set backup, recovery and testing requirements with the people responsible for operating the platform.

    So the interesting decisions go into your process, not into our tooling.

    Novel frameworks are somebody's hobby paid for out of your maintenance budget. We use mainstream tools deliberately, so the difficult thinking lands where it earns its keep: your chart of accounts, your approval chain, your award conditions, your service levels.

    It also makes the handover practical: agreed source-code access, administrative permissions and documentation written for the team responsible for operating the platform.

    Platform work and design approaches

    FixCare · NSW

    8

    Weeks from greenfield to live

    Replaced Excel, WhatsApp and paper job sheets entirely

    Council finance · design approach

    Plan

    Budgeting and workforce workflows

    Approval steps, forecasts and reporting designed together

    Council systems · design approach

    Connect

    Integration and migration planning

    A phased approach to connected information and services

    FixCare is a live platform example. Council finance and systems planning show our design capabilities.

    Eleven things happen on a platform build. Here they are, in order.

    This is the part most agency pages keep vague, and it is the part that decides whether you end up owning an asset or inheriting a dependency. So it is written down.

    1. Map what you actually run first

      Map the systems, integrations and spreadsheets in use, with their costs, owners and operational dependencies. That map helps the organisation decide what to keep, connect or replace.

    2. Draw the data model before the screens

      One auditable model the whole platform reads from, rather than a module per department stitched together later. This is the decision that cannot be reversed cheaply, so it gets made first and in the open.

    3. Build for the team that maintains it

      Choose a maintainable approach around the workload, integration needs and available support. Document the key decisions and give the operating team a clear way to understand and update the platform.

    4. Build the hardest module first

      Use an early prototype to test the most uncertain workflow. Agree its scope and acceptance criteria before committing to the next stage of the programme.

    5. Integrate two-way, not one-way

      Assess the interfaces and permissions available in the systems you are keeping, then design how records should move between them. Test those connections against the operational workflows they support.

    6. Put AI where it removes typing, not judgement

      Explore variance commentary, service-request triage, coding suggestions and questions over authorised records. Agree data handling and review requirements before use, with people approving changes that affect financial records.

    7. Rehearse every migration before it runs

      Every migration is rehearsed on a copy of the data before it touches a live system. On a finance platform an unrehearsed migration can reach a budget cycle, which is why none ship unrehearsed.

    8. Agree hosting and operating requirements

      Plan the hosting region, tenancy, access controls, backups and recovery requirements around the workload and the organisation’s data policies.

    9. Define ownership and exit arrangements

      Document source-code access, licensing, data exports and handover responsibilities in the agreement. Assess whether an escrow arrangement is appropriate for the project.

    10. Write the runbook for a stranger

      Deployment, backup, restore, key rotation, on-call escalation and the known rough edges, written for somebody who has never spoken to us. A handover that depends on a conversation is not a handover.

    11. Operate it, if you want us to

      Agree support responsibilities, monitoring, reporting and availability requirements. Prepare the access and documentation needed for your chosen operating team.

    How an engagement runs

    From the ecosystem audit to the runbook.

    1. Discover

      The ecosystem audit

      We map every system, integration and spreadsheet in scope, with its annual cost and its owner. You get that map whether or not you go ahead with us — it is useful on its own.

    2. Design

      The architecture

      Data model, integration surface, hosting topology, identity and access, backup and recovery targets. Written down and reviewed with your technical people before anything is built.

    3. Prototype

      A working prototype

      Test the most important assumptions in a scoped prototype, using approved sample data and agreed acceptance criteria.

    4. Sprints

      Build in modules

      Each module has its own acceptance window and its own review, and nothing reaches a live environment without a rehearsed migration.

    5. Go-live

      Access, documentation and handover

      Review the agreed source-code access, administrative permissions, exports and operating documentation with the people responsible for the platform.

    6. From there

      Operations or handover

      Put the agreed support and reporting arrangements into operation, or hand over to your chosen team with the documentation and access they need.

    Nothing is handed over without the source, the keys and a runbook written for somebody who has never met us.

    SoudCoh Compound™

    The two levers our platform team moves most.

    A platform that takes service requests lays the footing: each request recorded once, with where it came from. Every release and migration then follows the checks earlier builds taught us.

    • Footing

      Real-Enquiry Signal

      The number it moves: True cost per lead

      Where a platform takes bookings or service requests, each one is recorded where it happens, with its source.

      How Real-Enquiry Signal works
    • Engine

      The Carry

      The number it moves: Waste blocked before the first click

      Lessons from one build, like rehearsing migrations on copied data, become checks on the next one.

      How The Carry works

    Platforms and capabilities. Different operational needs.

    Explore council finance, participation and systems design approaches, alongside the live marketplace and property-maintenance platforms.

    Major Victorian council · Local government · Victoria

    Design approach

    Finance and budgeting, designed around council services.

    A design approach for bringing budgeting, workforce planning, forecasts and capital works into a clearer planning experience. We can build workflows that help finance teams review information, manage approvals and prepare reports.

    The design challenge

    Planning across disconnected information.

    Budget decisions draw on staffing, service delivery, capital works and financial records. Separate tools can make it difficult to understand changes and keep approvals moving.

    Our approach

    A shared view of the plan.

    Design the information model and approval steps around the council’s planning process, then develop modules that teams can review and test as the work progresses.

    What we can deliver

    • Budgeting and forecasting workflows
    • Workforce and service-planning views
    • Capital works and cash-flow planning
    • Approval steps and reporting templates
    • Data migration and integration planning
    • Acceptance criteria, documentation and handover

    Regional Victorian shire council · Local government · Victoria

    Design approach

    A practical approach to connected council systems.

    A capability model for reducing duplicated information across council operations. We can map existing systems, design shared workflows and plan a phased transition around the services and records that need to remain available.

    The design challenge

    Teams working across disconnected records.

    Property, finance, planning and service teams often need the same information in different contexts. Changing a system requires careful decisions about integrations, migration and daily operations.

    Our approach

    Define the connections before replacing the tools.

    Start with the systems and processes that are in use. Design the information model, test the most important workflows and sequence changes around the organisation’s priorities.

    What we can deliver

    • Systems and process mapping
    • Property, rates and finance workflow design
    • Planning, building and service-request journeys
    • People, procurement and asset-management modules
    • Integration and migration planning
    • Phased acceptance, training and handover

    Metropolitan Victorian council · Local government · Victoria

    Design approach

    Community participation with clear next steps.

    A design approach for consultation websites that help residents find projects, share views and follow what happens next. We can connect public participation tools with an officer workspace for reviewing responses and communicating outcomes.

    The design challenge

    Participation spread across separate channels.

    Residents need clear information and accessible ways to contribute. Officers need a practical way to organise responses, prepare updates and maintain the consultation record.

    Our approach

    One connected consultation journey.

    Bring project information, surveys, discussion, maps and updates together, with roles and review steps suited to the consultation process.

    What we can deliver

    • Public consultation and project pages
    • Surveys, polls, discussion and idea collection
    • Map-based feedback and event information
    • Officer review and reporting workspace
    • Accessibility and language requirements planning
    • Participation records and publishing workflows

    Msaha · Marketplace · Technology

    Live · Live · 2026

    AI-powered marketplace operations platform.

    A shared workspace for an Australian commercial-kitchen marketplace, helping the team manage vendors, listings and enquiries with an AI assistant for day-to-day work.

    3 → 1

    SaaS tools consolidated

    Live

    In production

    AI

    Embedded ops assistant

    Msaha · Live · 2026

    The problem

    Three SaaS tools, none of them the right shape.

    The operations team was switching between three disconnected tools to manage listings, enquiries and conversations, making it harder to see the full picture.

    Our approach

    Single-platform ops console with embedded AI.

    Replaced three SaaS tools with one workspace for vendors, listings and enquiries, plus an AI assistant the operations team uses every day.

    What we delivered

    • One workspace for the operations team
    • Vendor onboarding + listings management modules
    • Enquiries and customer conversations kept together
    • Embedded AI assistant for the ops team
    • Tied into the existing public-side marketplace

    FixCare · Property maintenance · NSW

    Live · Live · 2026

    Custom property maintenance platform — built in 8 weeks.

    End-to-end platform for a residential maintenance business: job intake, technician dispatch, customer portal, invoicing and an admin console — built and shipped to production in eight weeks.

    8 wks

    Greenfield to live

    3 tools

    Replaced

    Mobile

    Job access for tradies

    FixCare · Live · 2026

    The problem

    Excel + WhatsApp + paper job sheets.

    FixCare was running a growing residential maintenance business on Excel for jobs, WhatsApp for tradie comms, and paper for everything in between — invoicing was reconciled manually every week.

    Our approach

    End-to-end custom platform, eight weeks.

    One place to receive jobs, organise technicians, keep customers informed and manage invoices — built and shipped to production in eight weeks.

    What we delivered

    • Customer-side job intake + status portal
    • Mobile job details and photo capture for tradies
    • Admin console for the dispatch team
    • Invoices managed alongside the job
    • Replaced Excel + WhatsApp + paper job sheets entirely

    Before you brief anybody

    Here is what everybody asks first.

    FAQ

    Custom software, answered.

    Cost, timeline, contract, who owns the code, where the data lives, what happens when a build goes sideways, and what we do with AI.

    The first conversation is free and there is no deck.

    Talk to this division

    The estimate depends on the workflows, integrations, migration, hosting and support needed. We can compare a staged build with other options and show the ongoing operating assumptions alongside the initial scope.

    A focused platform can be in production in eight weeks — a property maintenance business went from Excel, WhatsApp and paper job sheets to a live platform with dispatch, a customer portal and automated invoicing in that time. Larger finance and ERP programmes need a schedule based on their integrations, migration and acceptance requirements.

    The agreement sets out the scope, review stages, support term and exit arrangements. We define data exports, source-code access and handover responsibilities before work begins so you can understand how the platform will be maintained.

    Ownership, source-code access and any third-party licensing are set out in the scope. We also agree administrative access, usable data exports and the documentation needed to operate or transfer the platform. Escrow can be considered where the project requires it.

    You hear it from us in the reporting rhythm, in plain English, with what we are changing. Modular, phased delivery exists so a module can be re-scoped, re-sequenced or stopped without taking the programme with it. If the honest answer is that a module is not worth building, we would rather say so than keep invoicing for it.

    A fixed cadence, good news or bad. Each report covers what shipped, what moved, what is at risk and what needs a decision from you — in the language you use about your own operation rather than in delivery jargon. You also have access to the working environment throughout, so you are never reading about software you have not seen.

    We plan maintenance, documentation and handover alongside the build. Your team can review the working software, the decisions behind it and the access needed to operate it. The agreement defines support, ownership, exports and transition arrangements.

    Hosting is designed around the workload and your data requirements. We can plan Australian hosting, appropriate tenancy and access controls, backup locations and recovery arrangements, with the selected services documented in the project scope.

    We can assess the interfaces and access available in your existing systems, then design the required connections. The plan identifies which records move, who owns them and how changes will be tested before an existing system is retired.

    We can explore commentary, triage, coding suggestions and questions over authorised records. The design needs clear data permissions, review steps and model-handling requirements. People retain approval over changes that affect financial records.

    Yes. Storefronts, checkout flows, subscription and member management, marketplace operations and the back-office consoles that run them are all in scope — one client's marketplace operations platform replaced three separate SaaS tools with a single console. The same terms apply: your source code, your data, sovereign hosting and a written exit.

    Often, yes. We start with a read of the code, the infrastructure and the data model, then come back with an honest assessment — including when the answer is that a rebuild costs less than the rescue. What we will not do is take on an unsupportable codebase and quietly discover that six months later, with you paying for the discovery.

    A platform build usually starts in one division and pulls in a second.

    Most engagements start in one division and pull in a second. All five divisions sit side by side on one page, if you would rather start there.

    Brief us on the platform

    Tell us what you run today and what it costs you. We map the ecosystem, price the ten-year view alongside the build, and tell you honestly if buying beats building.

    No pitch deck. A real conversation and a written map of what you are running.