Build or buy a web app?

Off-the-shelf wins when your process looks like everyone else's. Custom wins when the process is the thing you are good at, and bending it to fit a product would cost you the advantage. Most businesses need both, and the useful work is deciding which is which before anyone builds anything.

It depends almost entirely on scope, and scope is what a discovery or scoping workshop exists to pin down. What we can say is that the first version should be the smallest one worth using, so you learn from real use before committing to the rest.

Software that people rely on needs someone responsible for it — security patches, dependency updates, and the changes that come from real use. That is a support arrangement, not an afterthought, and it should be agreed before launch rather than after the first incident.

Yes. The codebase and the IP are yours, documented and handed over. You should be able to take it to another team without asking anyone's permission.

A web app where the work happens at a desk or on a tablet and you want one codebase and instant updates. A mobile app where you need the camera, offline use, or a home-screen icon people tap every day. Plenty of operations want a web app for the office and a mobile app for the field, and the two share the same backend.

That is usually the point of building one. The app reads from and writes to your existing systems through their APIs so there is one copy of the truth and no rekeying. Where a system has no usable API, that constraint is found during scoping — it changes the approach, and it is much cheaper to know up front.

The cost of a web app is driven by scope and integration, not by the number of screens. Each workflow adds rules, roles and edge cases to design and test, and each system it connects to, such as Xero, MYOB or your ERP, adds an interface that has to be built, secured and kept working. Customer-facing features like accounts, billing and multiple tenants add more again. Data migration from the spreadsheet or old system is the cost most often missed, because the data is always messier than anyone expects. Scoping prices all of this up front, and an Amplify build then runs at a fixed price against that scope, so a change in scope is a decision you make rather than a bill you receive.

A web app stays secure when access, data and patching are designed in from the start rather than tested for at the end. Roles decide who sees what, every change is logged, data is encrypted in transit and at rest, and hosting can sit in an Australian region where your data needs to stay onshore. The build should follow the OWASP Top 10, and hosting and patching should line up with the Australian Cyber Security Centre's Essential Eight. Accessibility deserves the same care: screens and forms built to WCAG 2.2 AA work for everyone on your team. After launch, security patches and dependency updates run on an agreed schedule, so a known weakness is fixed in days rather than found after an incident.

Starting small is the safest way to build a web app, and usually the cheapest. The first version should replace one workflow for one team, such as job intake or approvals, and reach production with real users within weeks. That version tells you what the next one needs far better than another round of planning does. Where you need to test an idea before committing a full budget, an Ignite proof of concept runs at a fixed price with a fixed scope. Because the code is yours from day one, starting small never locks you in: you can extend it with us, take it to another team, or stop if the evidence says so.