Amplify: custom software at a fixed price

If a product on the market does 80% of the job and the missing 20% is not where you compete, buy the product. Custom software earns its cost when the process is your advantage, or when no product fits the way you actually work. We would rather point you at the right tool than sell you a build you did not need.

Software makes an existing process faster and harder to change. If a workflow only exists because two systems were never joined up, or because nobody agreed who approves what, building it in code sets the mess in concrete. Fix or delete the process first; the build is usually smaller and cheaper afterwards.

A fixed price needs a fixed scope — that is the trade. If requirements are still moving because the business has not decided what it wants, no honest fixed quote exists, and any number you are given is padded for the risk. The cheaper path is a scoping engagement, or a prototype to settle the open questions first.

A properly scoped build does not compress past a point without something being given up, and what gets given up is usually testing. If the deadline is immovable and real, the honest options are a narrower first release, or a prototype now and the full build after — not the same scope promised faster.

We do not — that is what the scoping step is for. The price comes after a written requirements document covering functionality, technical approach and the boundaries of scope, not from a conversation. Anyone quoting a fixed price off a first meeting is either guessing or padding, and both cost you. The document is what makes the number honest, and you keep it either way.

Agreed scope is fixed at the agreed price. New scope is quoted as new scope, in writing, before it is built — so a change is a decision you make with a number in front of you rather than a surprise on an invoice. Being strict about that boundary is what lets us hold the original price at all.

Amplify projects typically start around $100,000 and scale with scope. The range is wide because it depends on how many systems the software has to talk to and how clean that data is — integration is usually the larger half of a build. Smaller, well-defined projects are scoped and quoted directly; complex ones go through a fuller requirements process first. You see the number before anything starts.

Defects in what we built, fixed at no cost for twelve months after launch. It covers the software not doing what the requirements document said it would. It is not a change window for new features, and it is not a hosting or support contract — those are scoped separately if you want them. The warranty exists because a fixed price means nothing if the thing breaks a month later.

You do, outright — the codebase, the repository, the IP. No licence fee, no ongoing dependency on us to keep it running, and it is documented well enough that another team could take it over. We would rather earn the next phase by being useful than by being the only ones who understand it.

Yes, and it is common. We work as a delivery partner alongside your team, as a specialist resource on the parts they do not want to own, or as the full build team — whichever fits. Your people know where the real constraints are, so the scoping work is better when they are in it.

Often, yes, and it is worth being clear-eyed about it. We review what exists first and tell you honestly whether it is worth continuing or cheaper to rebuild — sometimes the existing code is a solid foundation, sometimes finishing it costs more than starting again. Either way you get that assessment in writing, with the reasoning, before committing to anything.

When the scope is still moving. A fixed price is only honest against a fixed scope, so if the requirements are still being argued out, start with a Scoping Workshop and buy the build afterwards. Do not buy custom either when an off-the-shelf product genuinely covers the job — paying a monthly fee for something that already works beats owning a custom version of it. Custom earns its place when the process is specific to how you make money, when the tools you have force manual workarounds, or when your data has to move between systems that were never designed to talk.

Amplify builds typically take 2 to 12 months. Where you land depends on scope, how many systems the software has to talk to, and how quickly decisions get made on your side. The timeline is written into the scope alongside the fixed price, and a 12-month warranty starts at launch.

In your own Australian cloud account, not ours. Access is set per role and logged, data is encrypted in transit and at rest, and security testing is part of the build rather than an extra. Hosting and security are written into the requirements document, so they are priced in from day one.

Then the build has failed, however good the code is. That is why we put early screens in front of your real customers before the build starts and design around the one job they come for. If they will not use it, you find out in week two, not at launch.

Fast, if the first release does one job well. We scope the smallest version that real users can work with, ship it, and build the rest on what they actually do. That first release is also the proof investors ask for: people using it, and the numbers to show it.

Not when it does one job you already pay for by hand. A claims tool or a tracking portal is judged on hours saved and errors cut, and you see those numbers within weeks of launch. If the case does not stack up in the requirements document, we will tell you before you spend a dollar on the build.

Often, if the first build is scoped to the one job that pays back fastest. That might be a claims tool that cuts rework or a portal that ends the tracking calls. You see the fixed number before you commit, and the next piece only gets built once the first one earns its keep.