Custom software built around how your operation actually runs
Most operations should buy software rather than build it. We spend the first part of every engagement testing whether yours is genuinely the exception, then build only the parts that have to be custom.
What is custom software development?
Custom Software Development is the design and engineering of an application built for one organisation's processes rather than configured from a packaged product. It covers discovery, architecture, build, testing and documented handover. It suits Australian businesses whose core operation no longer fits off-the-shelf tools and who need to own the resulting code.
Get a fixed written quote- Typical timeline
- 16 to 32 weeks
- What drives cost
- The number of distinct user roles and their permissions, the number of systems that must be integrated, the state of the data you are migrating.
- Best for
- Operations that packaged products cannot model without permanent workarounds
- You own
- The source code, the infrastructure accounts and every piece of documentation
- Built with
- Structured discovery, documented architecture, automated tests, staged handover
Your handover
Build versus buy, decided before anyone writes code
The honest version of this decision is not a philosophical one. It is arithmetic. Take the packaged product that comes closest, list every requirement it cannot meet, and put a number against each gap in hours of manual work per month. Then price the licences, the implementation, the connectors and the internal admin time over five years. Compare that against a build plus its hosting and maintenance. In a decent number of cases the packaged product wins, and we will tell you so in writing.
- 01Discovery pack with domain model and process maps
- 02Written architecture note including rejected options
- 03Source code in a repository owned by your organisation
- 04Automated test suite and continuous integration pipeline
- 05Infrastructure defined as code in Australian regions
- 06Data migration with reconciliation evidence
- Integration connectors with documented field ownership
- Administrator and end user documentation
- Recorded deployment, rollback and support walkthroughs
The most common shape of custom software development we recommend is a hybrid
Where custom wins is rarely a single dramatic feature. It is usually four or five mismatches that each look tolerable alone and are corrosive together: a workflow that has to run in a different order, a pricing rule the product cannot express, an approval chain with a legal step, and a report the business runs weekly that currently takes someone two days. The most common shape of custom software development we recommend is a hybrid. Keep the accounting package, keep the payroll system, and build the operational layer in the middle that nobody sells because it is specific to you.
- Requirements the shortlisted product cannot meet, each costed in hours per month
- Licence, implementation and connector costs projected over five years
- The workarounds your team already runs in spreadsheets beside the current tool
- Which systems must stay because finance or compliance depend on them
- The smallest custom scope that removes the expensive gaps
A fortnightly review with the people who will actually operate the thing, not only the people funding it.
What discovery has to produce before the first sprint
Discovery is not a workshop and a mood board. It ends with artefacts a different engineering team could build from. We map the process as it actually runs, including the informal steps nobody documented, because those are where the exceptions live and exceptions are what make software expensive. We write the domain model, name the entities the way your staff name them, and define the states each record can be in and who may move it between them.
The rest of the answer
We also write down what the system will not do. A scope with clear exclusions is far more useful than one that only lists inclusions, because it makes the later conversation about a new request a simple one rather than an argument. By the end of discovery you have a domain model, a data migration plan, an integration inventory with the systems you already run, a risk list with the two or three items that could genuinely derail the schedule, and an architecture note explaining the choices and the ones we rejected. If that package tells you the build is a bad idea, discovery has paid for itself.
How the engagement runs
How a custom software project runs from discovery to handover
We deliver in vertical slices rather than horizontal layers. A slice is a complete piece of function that someone can use, database through to interface, so you are looking at working software from the first few weeks instead of waiting for a big reveal. This matters commercially as well as technically, because it means the highest value part of the system can go into real use while the rest is still being built.
- 01DiscoveryProcess mapping, domain model, integration inventory, migration plan and a written risk list
- 02ArchitectureData model, service boundaries, hosting design, environment plan and the security controls that apply
- 03FoundationsRepository, pipelines, automated testing, staging and a deployment path used from week one rather than invented at the end
- 04Vertical slicesThe highest value workflows built end-to-end and put in front of real users
- 05IntegrationsConnections to accounting, payroll, inventory or whatever holds the truth today, with the ownership of each field agreed first
- 06Migration and parallel runningLegacy data moved, reconciled by record count and value, then both systems run side by side for an agreed period
- 07HandoverDocumentation, recorded walkthroughs, a support window and access transferred into your accounts
Two decisions on your side that keep the project moving
The pattern that keeps projects on schedule is boring and reliable. One decision maker on your side. A nominated subject matter expert per area who can answer a question within a day. A fortnightly review with the people who will actually operate the thing, not only the people funding it.
Where your data lives and who can reach it
For Australian organisations the practical questions are which region the data sits in, who has administrative access, and what happens in a breach. We default to Australian cloud regions in Sydney or Melbourne for production data unless you have a reason to choose otherwise, and we write the choice into the architecture note so it can be shown to a client, an auditor or a procurement team without a scramble.
The rest of the answer
Handling personal information brings the Privacy Act 1988 and the Australian Privacy Principles into the design rather than the compliance review. That means collecting only the fields you can justify, defining retention and deletion instead of keeping everything forever, logging access to sensitive records, and having a notifiable data breach process that names a person rather than a department. If you work in health, disability or financial services, the requirements go further and we scope them at architecture stage alongside the broader controls covered in our security work. Retrofitting audit logging into a live system is one of the more miserable pieces of work in this trade.
Handover, documentation and the bus factor
The test of custom software development is not launch day. It is whether a competent developer who has never met us can take the repository, understand it in a week and safely ship a change in the second week. We build for that from the start, because an agency that is structurally difficult to replace has an incentive we would rather not have.
Infrastructure is defined as code so the environment can be rebuilt rather than remembered
In practice that means a readme that actually runs, environment variables documented with their purpose, architecture decision records explaining why the awkward choices were made, a seeded local environment so a new developer is productive on day one, and recorded walkthroughs of the deployment and rollback process. Infrastructure is defined as code so the environment can be rebuilt rather than remembered. Accounts for hosting, error tracking and any third party service are opened in your name with your billing details, and The accounts are yours, and our access is a permission you grant and can take back. Plenty of clients stay with us afterwards for ongoing work, and that is a decision we would like them to make freely.
When custom software is the wrong answer
If your process is genuinely standard, custom software development is an expensive way to end up with a worse version of a product that already exists. Accounting, payroll, general purpose CRM and document storage are all solved problems, and the vendors have spent a decade on edge cases you have not thought of yet. If your requirement list reads like a feature comparison of three existing products, buy one.
Software makes a bad process faster and much harder to change
It is also the wrong answer when the underlying process is broken. Software makes a bad process faster and much harder to change. Fix the process on paper first. Similarly, if the pain is repetitive handoffs between systems you are otherwise happy with, the cheaper fix is usually workflow automation rather than a new platform, and if the pain is reporting, it is often a proper reporting layer over the data you already have. When the real need is a customer facing interface over existing systems, that is web application development and it is a smaller job. We would rather scope the small version and be asked back than sell the large one first.
How we scope it
Four ways to scope your Custom Software Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Discovery build
A scoped build with the architecture settled first
Fixed written quote, agreed before work starts
- Discovery pack with domain model and process maps
- Written architecture note including rejected options
- Source code in a repository owned by your organisation
Product build
A working product your customers or staff use daily
Fixed written quote, agreed before work starts
- Everything in Discovery build
- Automated test suite and continuous integration pipeline
- Infrastructure defined as code in Australian regions
- Data migration with reconciliation evidence
Platform build
A platform with SSO, audit trails and a security review
Fixed written quote, agreed before work starts
- Everything in Product build
- Integration connectors with documented field ownership
- Administrator and end user documentation
- Recorded deployment, rollback and support walkthroughs
Product care
A named engineer, a roadmap and real service levels
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- A roadmap you set, worked through each month
- Dependency patching, monitoring and incident response
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Working with us
Can you build software that has to satisfy an audit or a funding body?
Yes, and it needs to be designed in from the start. NDIS providers, registered training organisations and health services generally need immutable audit trails, evidence of who approved what and when, retention rules and exportable records in a form the auditor accepts. We ask for the actual audit criteria during discovery rather than guessing, and design the data model so the report is a query instead of a fortnight of collation.
What support do you provide once it is live?
A defect window is included after go live, during which anything that does not match the agreed specification is fixed at no charge. Beyond that most clients take a support arrangement covering monitoring, dependency patching and a monthly block of development time, since a system in daily use always generates improvements. Running it with your own team is equally fine, and the documentation is written on that assumption.
Detail and edge cases
How long does a custom software project take?
Most run 16 to 32 weeks from discovery to handover, though the first usable slice is normally in front of staff within about six weeks. What moves the number is the count of integrations, how clean the legacy data is, and how quickly your subject matter experts can answer questions. We scope discovery separately so you get a firm estimate before committing to the full build.
What drives the cost of building custom software?
Four things dominate: the number of distinct user roles and their permissions, the number of systems that must be integrated, the state of the data you are migrating, and whether the operating environment carries compliance obligations. Feature count matters less than people expect. We work through those in discovery and then issue a fixed written quote for the build, so the figure only changes if the scope does.
Who owns the intellectual property and the code?
You do. The repository sits in your organisation, the copyright in the bespoke code is assigned to you in the contract, and infrastructure accounts are opened in your business name with your billing details. Any open-source components are listed with their licences so your legal team can review them. Nothing we build is held back as a proprietary layer that keeps you tied to us.
What happens if we want another developer to take over?
That should be straightforward, and we build for it deliberately. Your new team gets the repository, the architecture decision records, a local environment that runs from a single command, deployment recordings and a handover call with our engineers. We do not charge an exit fee. If a partner cannot be replaced without a transition project, the software was not documented properly.
Related services
Start with discovery, not a build contract
Tell us what your operation does and where the current tools give out. We reply within one business day, and any proposal is a fixed written quote with the scope and the exclusions written down.