How we build custom software for Australian businesses
We design and build custom software in Australia and mobile apps for Australian businesses. An experienced Australian software and mobile team with 20+ years of development experience. We take meetings and calls from Melbourne. Tell us about the project. Some work is clear enough to quote a build from there. When it is not, a two-week discovery gives you a spec and a fixed-price quote.
Discovery
What discovery is
A software discovery, sometimes called a discovery phase or discovery workshop, is a short, paid piece of work that turns a fuzzy project into a spec, a sketched path, and a fixed-price build quote. See What is a software discovery, and what does it cost? on the FAQ.
When discovery is needed, versus quoting from a call, is on When do we need a software discovery, and when can you quote from a call?.
Fixed price. Two weeks. We map the workflow, the tools you already use if any, and a first version that can ship. That can be custom software development or mobile app development for iOS and Android. You receive:
- A written spec: pages, data, integrations, and what is out of scope
- A clickable or sketched path through the first version
- A fixed-price build quote
You keep the spec even if you hire someone else. That is the point of paying for discovery. Completing discovery does not oblige you to hire us for the build. The spec, the path through the first version, and the quote are yours.
Next step
Start with a call.
We take meetings and calls. If the work is a custom software or mobile build, tell us about it and we will say whether a quote or a two-week discovery is the honest next step.
Starting from an RFP or a blank page
Some buyers arrive with a formal RFP. Others arrive with a problem and a pile of notes. Both are fine. Cena Advisory does not need a perfect brief to start a conversation. If you already have an RFP, send it and we will say what is clear, what is missing, and whether a fixed quote or a short discovery is the honest next step. If you do not have an RFP, we usually start with a call and, when the work needs it, a two-week discovery that produces a written scope you keep even if you hire someone else.
If you are writing an RFP (request for proposal) for software development, keep it honest: the problem, the users, the systems you already pay for, and what must ship in the first version. Cena Advisory does not sell RFP or proposal templates, and a quote from us is a clear first-version scope with a fixed price. When the brief is still fuzzy, a two-week discovery produces a written scope and a fixed-price build quote you keep even if you hire someone else.
A long RFP does not replace knowing what is in and out of the first version. Discovery, fixed price versus time and materials, and what happens when scope changes are covered on this page and the FAQ. Tell us about the project when you want that conversation on a real job.
Fixed-price discovery and builds
Cena Advisory quotes discovery and builds as fixed-price, fixed-scope work once the scope is clear. Time and materials can suit research-heavy or open-ended work, but it needs a cap and a written list of what is in and out. The longer answer is on the FAQ. What happens when the scope changes is on When scope changes on a fixed-price build.
That written list of what is in and out of the first version is the statement of work (SOW). At Cena Advisory it is the discovery spec and the fixed-price scope: pages, data, integrations, and what stays out. The slice is done when it passes that list. Acceptance criteria are the per-item checks, and user acceptance testing (UAT) is your team running them on working software. When the engagement ends, handoff is the repository and the source code you already own from a paid build, plus a clear path through what shipped. The buyer question below covers those terms, and When scope changes on a fixed-price build covers how the list is changed.
When scope changes on a fixed-price build
Fixed price means fixed scope. The written list of what is in and out is the contract for that number. If you need something new, we stop and write the change down: what is added, what moves out, and what the new fixed price is, before that work starts. That written stop-and-rewrite step is our change request process on a fixed-price build: nothing new starts until the added work, anything moved out, and the new fixed price are on the page. We do not quietly burn hours against the old number, and we do not invent a percentage buffer on the website.
When the list grows without a new price, that is scope creep. The written change request is how we stop it: the change is agreed on the page before anyone builds it, and fixed price still means fixed scope for that slice. The buyer question below covers scope creep and change requests.
A change request on a fixed-price slice stays a written in/out change. Later slices are new fixed-price jobs, which is how we keep incremental or phased delivery honest without an open-ended retainer.
Time and materials can suit research-heavy work, but it still needs a clear cap and a written in/out list. Ask any studio, including us, what happens when the scope changes before you sign. The longer comparison of fixed price versus time and materials is on the FAQ. Tell us about the project when you want that conversation on a real job.
First version, not a slide deck
An MVP here is a first version that real users can run, not a slide deck. It is the smallest product that proves the workflow, with a clear list of what is out of scope.
A prototype or proof of concept (POC) is different. A clickable sketch or throwaway demo can help a conversation, but it is not a first version you can put in front of staff or customers. A wireframe or mockup is a sketch of screens; we may sketch a path in discovery, but that sketch is not the product. A pilot sits closer to an MVP: a limited first run with real users in one team or site, still with a written out-of-scope list. The buyer question below separates those terms.
After a call, or after a two-week discovery, we size an honest first version for MVP software development or a mobile app. Once it ships, delivery is staged: we keep improving what people already use, and the next slice is a new fixed-price job once the first one is in use. The discovery spec and each fixed-price scope set what a slice includes, and When scope changes on a fixed-price build covers how a later slice is written. The longer MVP definition sits on the FAQ. Tell us about the project when you want that conversation on a real job.
Build
Then the build
Fixed scope from the spec, or from a quote after the first conversation. You own the source code we write for a paid engagement, including the repository. Clients keep the repository from a paid engagement. The longer ownership answer is on the FAQ. That is how contractor work in Australia should land. Weekly working software, not a big reveal at the end.
When a build ends, knowledge transfer means walking your team through what shipped, how to run it, and where the in/out list lives, not a slide deck that replaces the repository. Avoiding vendor lock-in starts earlier: you hold the repository, and you should hold the cloud and app-store accounts that would trap you if the relationship ended. Longer ownership answers sit on the FAQ. Tell us about the project when you want that conversation on a real job.
The people who run discovery are the people who build. Who you will meet is on the About page.
Fit
Who we work with
Australian businesses that need custom software or a mobile app. That includes a first product, custom business software, and work that sits with tools you already run. We are based in Melbourne and we work across the country. We take meetings and calls.
Published examples of this process include a retail inventory app for a retailer with several shops, a logistics operations dashboard, and a healthcare booking app.
Who you will meet is on About. When you are ready, tell us about the project on the Contact page.
Questions
Buyer questions
What is an MVP versus a prototype or POC?
An MVP here is a first version real users can run, with a written out-of-scope list. A prototype or proof of concept (POC) is usually a clickable sketch or throwaway demo built to test an idea. A wireframe or mockup is a sketch of screens, useful for planning but not something people can work in. A pilot is a limited first run with real users in one team or site, so it is closer to an MVP than to a demo. After the first version, work is usually both iterative (improving what people already use) and incremental (buying the next fixed-price slice). Read First version, not a slide deck above, or the longer answer on the FAQ. Tell us about the project.
What is a statement of work, and do you use acceptance criteria or UAT?
A statement of work here is the written scope for a fixed-price slice: what is in, what is out, and what "done" means. It is not the same as a statement of requirements, which lists what the product must do; the statement of work is the engagement document for that slice. Acceptance criteria are the checks on each item in the list. QA (quality assurance) is us checking the build against the list before handoff; UAT (user acceptance testing) is your people confirming the same list on working software. Discovery produces a spec you keep, and source code from a paid engagement is yours, including the repository. Read Starting from an RFP or a blank page and Then the build above. Tell us about the project.
What is scope creep, and how do you handle a change request?
Scope creep, sometimes called feature creep, is when the written list of what is in grows without a new fixed price. A change request is the written update: what is added, what moves out, and the new number, before that work starts. Fixed-price slices stay fixed until that list is rewritten. Read When scope changes on a fixed-price build above. Tell us about the project.
What is knowledge transfer, and how do you avoid vendor lock-in?
Knowledge transfer here means handing over the working product: the repository you already own from a paid build, plus a clear path through what shipped and what stayed out of scope. Vendor lock-in is what happens when the studio keeps the repo or the cloud logins you cannot recover. Cena Advisory writes code you own; ask any studio, including us, who holds the repository and the cloud accounts before you sign. Read Then the build above, plus Who owns the source code? and Who should own the repository, cloud, and app store accounts?. Tell us about the project.
Start here
Tell us about the project.
We take calls and meetings with Australian business owners. If you have a real custom software or mobile build, we will talk it through.