The service
Software engineering
The web, mobile and platform builds a business runs on, shipped and then run by the engineers who wrote them.
Compare
Custom software or off-the-shelf: the criteria that decide it.
Buy for standard needs; build where the process is your differentiator, generic tools force double-handling, or audit obligations reach the architecture.
Option A
Custom software
Option B
Off-the-shelf SaaS
Software engineering
Overview
Build or buy is usually the first significant technology decision a business faces. The criteria here are the ones we apply to our own builds.
Why the answer is usually buy
Most of the time the answer is buy. Off-the-shelf products are faster to adopt, cheaper for standard needs, and maintained by someone else. Custom software wins in specific, nameable situations: when the process is your differentiator, when generic tools force double-handling, when data control and audit obligations reach into the architecture itself, or when the tool is becoming the business.
Black Shard builds and operates production software for clients who had those reasons.
Side by side.
| Dimension | Custom software | Off-the-shelf SaaS |
|---|---|---|
| Time to start | Slower by nature. Even a tightly scoped build needs a brief, a design pass, and a first working slice. Fixed-scope work is briefed and dated before it starts, but nothing ships on day one. | Immediate by comparison. Sign up, configure, import your data. For a standard need this speed is decisive, and no build can compete with it. |
| Fit to process | Exact. The system is shaped to how you work: your intake, your approvals and your registers. | Approximate. You adopt the vendor's model of the work. For a standard process that model is usually good enough. For a differentiated one, you bend the process to fit the tool and lose the edge. |
| Cost shape over time | Front-loaded. The build is scoped and priced before work starts; after launch, the costs are hosting and maintenance you control. No per-seat pricing. | Low then compounding. Cheap to adopt, then per-seat and per-module fees that grow with headcount for as long as you use it. For a standard need, years of subscription still usually cost less than a build. |
| Integration depth | As deep as the work demands. A custom system can sit over the tools you keep and close the gaps between them: the checks, the approval gates and the audit trail a generic tool leaves out. | Bounded by the vendor's API. Mainstream pairings work well. Anything off the beaten path becomes CSV exports and re-keying, which is double-handling with a subscription attached. |
| Data control and residency | Designed in. Workloads hosted in Azure Australian regions, with tenancy, retention, and access modelled on your obligations. | The vendor's call. Many handle Australian residency well; some do not. Confirm where the data sits, who can reach it, and what crosses borders before you sign. |
| Security accountability | Concentrated. The team that built the system secures it: threat modelling from the first design session, least-privilege access, audit trails you can inspect. One party answers for the outcome. | Inherited. You take on the vendor's posture, staffing, and breach history. Their assurance reaches you as documents: independent assessments, audit reports, a sub-processor list. |
| Evolution | Continuous. Software under an ongoing engagement changes when the workflow does, and the roadmap is yours. GRM LAW is one example. The firm operates from the portal. We ship to it weekly under an ongoing engagement. | The vendor's roadmap. Your feature request queues behind every other customer's. Acquisitions, pivots, and product sunsets happen on their schedule, and you migrate on it too. |
Time to start
Custom software
Slower by nature. Even a tightly scoped build needs a brief, a design pass, and a first working slice. Fixed-scope work is briefed and dated before it starts, but nothing ships on day one.
Off-the-shelf SaaS
Immediate by comparison. Sign up, configure, import your data. For a standard need this speed is decisive, and no build can compete with it.
Fit to process
Custom software
Exact. The system is shaped to how you work: your intake, your approvals and your registers.
Off-the-shelf SaaS
Approximate. You adopt the vendor's model of the work. For a standard process that model is usually good enough. For a differentiated one, you bend the process to fit the tool and lose the edge.
Cost shape over time
Custom software
Front-loaded. The build is scoped and priced before work starts; after launch, the costs are hosting and maintenance you control. No per-seat pricing.
Off-the-shelf SaaS
Low then compounding. Cheap to adopt, then per-seat and per-module fees that grow with headcount for as long as you use it. For a standard need, years of subscription still usually cost less than a build.
Integration depth
Custom software
As deep as the work demands. A custom system can sit over the tools you keep and close the gaps between them: the checks, the approval gates and the audit trail a generic tool leaves out.
Off-the-shelf SaaS
Bounded by the vendor's API. Mainstream pairings work well. Anything off the beaten path becomes CSV exports and re-keying, which is double-handling with a subscription attached.
Data control and residency
Custom software
Designed in. Workloads hosted in Azure Australian regions, with tenancy, retention, and access modelled on your obligations.
Off-the-shelf SaaS
The vendor's call. Many handle Australian residency well; some do not. Confirm where the data sits, who can reach it, and what crosses borders before you sign.
Security accountability
Custom software
Concentrated. The team that built the system secures it: threat modelling from the first design session, least-privilege access, audit trails you can inspect. One party answers for the outcome.
Off-the-shelf SaaS
Inherited. You take on the vendor's posture, staffing, and breach history. Their assurance reaches you as documents: independent assessments, audit reports, a sub-processor list.
Evolution
Custom software
Continuous. Software under an ongoing engagement changes when the workflow does, and the roadmap is yours. GRM LAW is one example. The firm operates from the portal. We ship to it weekly under an ongoing engagement.
Off-the-shelf SaaS
The vendor's roadmap. Your feature request queues behind every other customer's. Acquisitions, pivots, and product sunsets happen on their schedule, and you migrate on it too.
When each is right.
Custom software
When custom software wins
- The process is the differentiator.
- Off-the-shelf forces double-handling.
- Data, residency, or audit obligations outrun configuration.
- The tool is becoming the business.
- No vendor covers the work.
When custom software wins, in full
The process is the differentiator. If the way you run intake, deal flow, or compliance is why clients choose you, a generic tool makes you run it the way every competitor does.
Off-the-shelf forces double-handling. When staff re-key the same matter or client into two systems, the subscription is the smaller cost. A custom layer over the tools you keep removes the re-keying instead of adding a third silo.
Data, residency, or audit obligations outrun configuration. When an obligation reaches actor, action, and before and after state on every change, it sits in the architecture.
The tool is becoming the business. When the software is what your clients pay for, you need to own it. Among the production systems we build, host and secure is Aurii, the clinical app for private hospital specialists, live on iOS, Android and the web.
No vendor covers the work. If your method has no product category, no vendor is building one on your schedule.
Off-the-shelf SaaS
When off-the-shelf is simply right
- The need is standard. Accounting, payroll, email, documents, calendars, video calls: these are solved problems with mature products behind them.
- Compliance logic lives in the product.
- The process is still forming.
- The value is the network.
- A mainstream tool fits with light configuration.
When off-the-shelf is simply right, in full
Compliance logic lives in the product. Payroll and tax rules change constantly, and the established products encode the changes as they land. A bespoke rebuild of that logic is a standing liability.
The process is still forming. If you have not run the workflow manually for long enough to know its shape, a subscription you can cancel is the cheapest way to learn. Build after the process proves itself.
The value is the network. Electronic signatures, payments, conferencing: the worth sits in the counterparties and the compliance regime already on the platform.
A mainstream tool fits with light configuration. If a standard CRM covers your pipeline once configured, take the win. A custom build has to clear a high bar over a configured product.
In depth
The detail behind the decision.
Why the default is buy
A build is an asset with a lifetime. Someone has to patch it, monitor it, back it up, and answer for it when it breaks. Every feature is code someone maintains and a surface someone can attack.
Our build-or-buy rule
So the decision rule we apply in our own builds is narrow. Buy for every standard need. Build only where the software touches the thing that makes the business different, and compare that build against a well-configured off-the-shelf alternative.
How do you know the process is the differentiator?
Most businesses overestimate how special their process is. The test is commercial: if a competitor adopted your workflow tomorrow, would clients notice? Standard sales pipelines, standard bookkeeping, and standard support queues fail that test, and they should be bought. The conflicts-and-compliance workflow a law firm runs its matters through every day usually passes it.
Regulatory perimeters and double-handling
A workflow that passes is worth building into a portal over the practice system the firm already runs, keeping the process exactly as the firm runs it.
Regulatory perimeters produce the same answer by a different route. A financial services licence reaches into the data model itself: what is retained, who acted, what changed, before and after state on every change. Generic tools let you configure fields. They do not let you make the audit trail machine-enforced, and a structural obligation needs software built around it.
The third trigger is quieter: double-handling. When a team keys the same client into the practice system and the spreadsheet beside it, or exports CSVs every Friday to assemble the report no tool produces, the off-the-shelf stack has stopped saving money. The subscription line appears on the invoice. The labour it fails to remove appears nowhere, and counting both usually settles the question.
How a Black Shard build runs
If the answer is build, the engagement is legible: the workflows covered, the integrations, the environments, and the tenancy model are all scoped before work starts. Threat modelling happens in the first design session. Workloads hosted in Azure Australian regions, under least-privilege access, with the audit trail built in.
Defined builds and ongoing engagements
Delivery is either a defined build with a brief and a delivery date, or an ongoing engineering engagement where the product continues to evolve after launch. Stone Leaf Capital is one example. We ship to the portal under an ongoing engagement, structured around the firm's AFSL perimeter and retention obligations. Delivered across Australia, remotely as standard and on site where the scope needs it.
Questions, answered.
Is custom software more secure than off-the-shelf SaaS?
Not automatically. A major SaaS vendor employs more security engineers than most Australian businesses ever will. What custom software changes is accountability and inspectability: the builder answers for the design, and you can read the audit trail. We build secure-by-design, with threat modelling before a line is written and least-privilege architecture throughout.
What does custom software cost?
No range is published; scope decides it. The drivers are the workflows covered, the integrations, the number of environments, and the tenancy model; a defined build is agreed with a brief and delivery date before work starts. The comparison is build price against years of per-seat fees plus the cost of the double-handling the subscription leaves in place.
Can custom software work alongside the SaaS we already use?
Often that is the right architecture. Keep the practice system or the accounting package, build the layer over it that carries the workflow it does not, and integrate the two through their published APIs. The audit trail can then be enforced on every state change.
When should we replace an off-the-shelf tool with a custom build?
When the workarounds become the job. The signals are consistent: staff maintaining spreadsheets beside the tool, weekly CSV exports to build the report it cannot produce, the same data keyed into two systems, or an audit obligation the tool cannot evidence. If none of those are present, keep the subscription.
Should a new business ever build custom software?
Mostly no. Buy nearly everything and spend the build budget on the single system that makes the business different. The rest of a young company's stack should be bought, configured, and left alone.
