Services · Custom software development
Software for the part of your operation no app fits.
Production systems, fulfilment integrations, storefront customisers and internal tools, for ecommerce businesses doing $1M–$50M. Fixed scope, a number agreed before we start, and you own the code from day one.
The specification is a separate paid piece of work. That is what makes the build price fixed.
Price to start
A$5,000 – A$8,000
- Then
- Build A$25,000 – A$60,000, quoted as one number
- Duration
- 6–12 weeks, depending on systems touched
- You own
- The repository, the infrastructure and the data
The problem
The spreadsheet is the system, and everyone knows it.
Most ecommerce businesses at this size are running at least one genuinely important process outside their software. A production schedule in a shared sheet. A purchasing model one person owns. A reconciliation that happens on Thursdays because that is when somebody has time. It works, until the person is away, or the volume doubles, or a formula quietly breaks and nobody notices for a month.
The reason it stays that way is not laziness. It is that the process is specific to how you operate, and the apps on the market are built for the average of everyone. Adopting one means changing the thing that makes you different, so you keep the sheet, and the sheet keeps growing.
The other half of the problem is that custom software has a bad reputation, and it earned it. Projects scoped while being built. Agencies who own the repository. Systems on a stack nobody else recognises, which means the maintenance quote only ever comes from one place. If you have been burned, the caution is rational and we are not going to argue you out of it.
What changes the maths is doing the scoping as a separate, paid piece of work first, and being honest about the cases where an existing product is the better answer. Both of those are cheaper for you and less profitable for us, which is roughly how you can tell they are meant.
Build or buy
Most of what you are considering should not be built.
This is the test we apply during the diagnostic, before anyone quotes a build. It regularly removes more items from the list than it adds.
| The situation | What we'd usually say | Verdict |
|---|---|---|
| The process is standard for your industry | Buy. An app does it, it is maintained by someone else, and it is cheaper. | Off-the-shelf |
| The process is standard but the data is split across systems | Usually integrate rather than build. Connect what exists before replacing it. | Integration |
| The process is how you actually compete | Build. This is the case where an app forces you to work like everyone else. | Custom |
| The process only exists because a tool can't do it | Neither. Remove the process. The diagnostic finds several of these each time. | Delete |
| Someone maintains it in a spreadsheet by hand | Build, usually small. Highest payback item on most lists. | Custom |
How each candidate gets sorted
- The process is standard for your industry
- VerdictOff-the-shelf
- What we'd usually sayBuy. An app does it, it is maintained by someone else, and it is cheaper.
- The process is standard but the data is split across systems
- VerdictIntegration
- What we'd usually sayUsually integrate rather than build. Connect what exists before replacing it.
- The process is how you actually compete
- VerdictCustom
- What we'd usually sayBuild. This is the case where an app forces you to work like everyone else.
- The process only exists because a tool can't do it
- VerdictDelete
- What we'd usually sayNeither. Remove the process. The diagnostic finds several of these each time.
- Someone maintains it in a spreadsheet by hand
- VerdictCustom
- What we'd usually sayBuild, usually small. Highest payback item on most lists.
Off-the-shelf software has improved considerably. A well-configured standard stack beats a mediocre custom build every time, and we would rather say so early.
What we build
Six kinds of system, all of them operational.
We do not build marketing sites, mobile apps or marketplaces. This is the whole list, and it is the list because it is what we have run ourselves.
Production and operations systems
Order intake through artwork, scheduling, the floor, quality checks and despatch, in one system rather than four spreadsheets and a Slack channel. This is the one we know best, because we built it for our own business first and it still runs there across multiple locations.
Fulfilment and 3PL integration
Wiring the warehouse to the storefront so that Shopify, the pick line and the courier agree on what state an order is in, including the unhappy paths: split shipments, partial cancellations, failed scans, returns that arrive before the RMA does.
Storefront customisers and configurators
Product personalisation that produces something the production floor can actually use — print-ready artwork written straight into the queue, not a screenshot a designer has to rebuild. The hard part is never the front end; it is the file that comes out the other side.
Internal tools nobody sells
The screens your team would build if they could: a merchandising view over a large catalogue, a purchasing signal, a reconciliation console, a returns triage board. Small, specific, and usually the fastest payback in a build because they replace a spreadsheet somebody maintains by hand.
A data layer that agrees with itself
One place where orders, inventory, fulfilment events and costs are reconciled and dated, so reporting stops being an argument. Often the unglamorous prerequisite for everything else on this list, and often the item we recommend doing first.
Integrations between things that won't talk
The supplier who sends a CSV by email. The finance system with an API from 2011. The machine on the floor that writes a log file. Most operations have two or three of these and they are where the manual work quietly accumulates.
How it runs
Five stages. You can stop after any of them.
| Stage | What happens | Duration | Price |
|---|---|---|---|
| 1. Diagnostic | Baseline, reconciliation map and a ranked order of work. | 2–3 weeks | A$5,000 – A$8,000 |
| 2. Scope and quote | A written specification and a single number. Nothing starts before you have both. | About a week | Included |
| 3. Build | Working software in your environment every fortnight, not a reveal at the end. | 6–12 weeks | A$25,000 – A$60,000 |
| 4. Handover | Documentation, access, and your team using it while we are still there. | Within the build | Included |
| 5. Ownership | Optional. A named owner for monitoring, fixes and small changes. | Rolling | A$2,000 – A$8,000 / mo |
Custom software engagement — stages and pricing, in Australian dollars, excluding GST
- 1. Diagnostic
- PriceA$5,000 – A$8,000
- What happensBaseline, reconciliation map and a ranked order of work.
- Duration2–3 weeks
- 2. Scope and quote
- PriceIncluded
- What happensA written specification and a single number. Nothing starts before you have both.
- DurationAbout a week
- 3. Build
- PriceA$25,000 – A$60,000
- What happensWorking software in your environment every fortnight, not a reveal at the end.
- Duration6–12 weeks
- 4. Handover
- PriceIncluded
- What happensDocumentation, access, and your team using it while we are still there.
- DurationWithin the build
- 5. Ownership
- PriceA$2,000 – A$8,000 / mo
- What happensOptional. A named owner for monitoring, fixes and small changes.
- DurationRolling
Qualifying
Who this is for, and who it isn’t.
This is for you if
- You are doing $1M–$50M and a core part of the operation runs in a spreadsheet somebody maintains by hand.
- You have looked for an app and either none fits, or the ones that fit want you to change how you operate.
- The process in question is part of how you compete, not a commodity everyone runs the same way.
- You want a fixed number before starting, and you want to own the result.
- You have someone internally who can answer questions about how the operation really works.
This is not for you if
- An existing app covers it. We will tell you this in the diagnostic and it happens often.
- You want the cheapest possible build. Cheap development is genuinely cheap now, and for a well-specified job it is a reasonable way to buy.
- You want developers by the month to work through someone else's roadmap. We take a defined problem and finish it.
- The requirements will be discovered while building. Fixed scope needs a scope; that is what the diagnostic produces.
- You need a mobile app, a marketplace, a game, or anything outside ecommerce operations. Outside that we are just another firm with opinions.
Questions
What people ask before booking.
Eight of them, in the words we would use on the call.
The test is whether the process is how you compete or just something you have to do. Commodity processes should be bought — an app does it, someone else maintains it, and it costs less. Processes that are actually your operating advantage are where an off-the-shelf tool starts forcing you to work like everyone else. The diagnostic sorts your list into build, buy, integrate and delete, with the reason written next to each one.
Yes. Fixed-scope work is quoted as a single number before anything starts, and it does not move unless you change the scope in writing. That is possible because the diagnostic comes first — most cost overruns in this industry are the bill for scoping a project while building it.
You do, from day one, and it is in the agreement rather than a favour granted on the way out. That includes the repository, the infrastructure configuration and the data. We build on standard infrastructure specifically so your next developer can pick it up without needing us in the room.
Deliberately boring and widely known: TypeScript, Next.js, Postgres via Supabase, Shopify's Admin API where the storefront is involved, standard hosting. The point of that list is that any competent developer recognises all of it. A clever stack is a liability for a business that is not a software company.
Fair, and we will not pretend otherwise — it is the most common objection we hear and it is usually justified. We reduce it by building on infrastructure your next developer will recognise, writing the documentation as part of delivery and keeping the operational runbooks beside the code. If you would rather buy something off the shelf, we will tell you.
You can. The build is staged so there is working software in your environment every fortnight rather than one reveal at the end. If you stop, you keep what has been delivered, running, with the code and the documentation. There is no version of this where leaving is punished.
Often, and it usually goes well when the boundary is clear — we take a defined system, they keep theirs, and the interface between them is written down. What we do not do is join a team as extra hands on someone else's roadmap. That is staff augmentation and there are firms who are better at it than us.
Six to twelve weeks after the diagnostic and the written scope, depending on how many systems it touches and how clean the data is. Data quality is the variable that moves timelines most, which is why the diagnostic looks at it before anyone quotes.
Next step
Start with the diagnostic.
It produces the specification a fixed price depends on — and, on a good number of items, the recommendation not to build at all.
Ace takes these calls. Not a salesperson, because there isn’t one.