Web App Development

Yes. CodeFish Studio is an Adelaide software studio, and the people who scope your web app are the people who build it. We work with businesses across Australia: workshops can run in person in Adelaide or online, and the build runs the same way either way.

Yes, outright. The codebase, the repository, all of it. No licence fees, no ongoing dependency on CodeFish to keep things running. If you want us to stay involved after launch we offer ongoing support, but it is never a condition of delivery.

Yes. We regularly inherit codebases and extend them. Before we commit to a price we do a technical health review so we both understand what we are working with. If what exists is too problematic to build on, we will tell you that upfront.

Yes. Integration work is a core part of what we do — CRMs, ERPs, third-party APIs, internal databases. We scope integration requirements from the start so nothing is treated as an afterthought at the end of the project.

Fixed price, scoped upfront. We produce a requirements document that defines exactly what is being built, then quote from it. For smaller projects with a clear brief we can move straight to a quote. For larger or more complex builds we run a scoping workshop first.

Straightforward internal tools typically run six to twelve weeks. Production-grade customer-facing platforms typically run three to six months depending on scope. Every quote includes a realistic timeline based on the actual work, not a generic estimate.

You need a clear picture of the problem, not a finished specification. Bring the spreadsheets, forms or tools the app will replace, a list of who will use it and what each role needs to do, and the systems it has to talk to, such as Xero, MYOB or your CRM. Examples of reports or screens people already rely on help too. If the requirement is still fuzzy, a short scoping engagement turns it into a requirements document we can price from. If it is already clear and small, we can often quote after one or two conversations.

Changes are expected, and they go through a simple change request rather than quietly growing the scope. When you see the app in a sprint review and want something different, we write down what changes, what it does to the price and timeline, and you approve it before the work starts. A swap of equal size can often be traded within the price, because something else comes out. Anything that adds work is priced on its own, so the original fixed price stays fixed and you always know what you are paying for and why.

Defects in what we built are covered for the first year under the warranty. Beyond that, support is a monthly arrangement agreed before launch, sized to how much the app does and how much it will change. It covers security patches, dependency and hosting updates, monitoring, and a set amount of time for small improvements. Hosting, on AWS or Vercel for example, sits in an account you own. If you would rather run it yourselves, the documentation and code handover mean your team or another developer can take it over.

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.

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.

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.

Security is decided at the architecture stage, not bolted on before launch. That means access control and permissions designed around your actual roles, encryption in transit and at rest, secrets kept out of the codebase, and dependencies patched through the warranty period. Hosting can sit in Australian regions where your obligations or contracts require it. If your organisation has specific standards to meet, bring them to the scoping conversation and we will design to them and document how each one is met — and tell you plainly if something is outside what we can commit to.