EMVALUE / Website & app services
Apps that start small and prove themselves
We develop apps for Australian small businesses and startups, beginning with a prototype that can be tested. We agree a useful first version before building and releasing in phases. The platform, testing, release support and maintenance are assessed and set out in a written proposal, with English and Chinese communication and mainly online collaboration.
Who this is for
- Businesses with a clear, repeated task that customers or team members need to complete, rather than a request for an app without a defined use.
- Small teams that want to test the proposed flow before deciding how much of the product belongs in the first version.
- Owners comparing a mobile-friendly website, an existing tool and a custom app for a specific business problem.
The scope
What we agree in the scope
- Discussion of the problem, users and repeat-use scenarios to decide whether an app is a suitable approach.
- A testable prototype and a defined first-version scope, with review points before further development.
- Assessment of iOS, Android or a web app, based on the agreed use rather than a platform chosen in advance.
- A written plan for development phases, testing, release responsibilities, account access and code handover.
Scope separately
- Every future feature in the first release. Later work is scoped and agreed separately.
- Testing, store submission support or ongoing maintenance without a specific agreement covering them.
- A platform or release commitment before the proposed flow and requirements have been assessed.
Decide whether an app is needed
Not every business problem needs an app. We look at how often people will use it and what they need to do. An existing tool or a mobile-friendly website may be enough; a custom app makes sense when it solves a clear, repeat-use problem.
Start with the action a person needs to take, how often it happens and the information involved. If a website explains the service and handles the required interaction, that may be sufficient. If an existing tool already solves the task, consider it before commissioning custom development.
A prototype before a larger build
A prototype makes the proposed flow concrete enough to test. Review what users need to see and do before adding the rest of the feature list. The first version should have a clearly described purpose and boundary, so a new request can be recognised as a change in scope.
We assess the platform after discussing that flow. iOS, Android and web apps have different release arrangements; the proposal states which approach is being built and what testing and publication support it covers. Maintenance and later development are separately agreed rather than left implicit.
How we work
- 1
Understand the job
We discuss your business, audience, existing tools, budget and the problem you want to solve.
- 2
Agree the scope
You receive a written proposal covering the work, deliverables, schedule, costs and payment stages.
- 3
Design, build, review
Review layouts and working previews at agreed milestones. We confirm any change in scope before proceeding.
- 4
Launch & hand over
We check the agreed flows, help you launch and hand over accounts and guidance. Ongoing support is agreed with you.
Written scope and costs
- 01
App projects are quoted in writing after the problem, prototype and first-version boundaries are discussed. Platform choices, features and connections affect the work involved. The proposal separates development, testing, release support and maintenance, and explains the payment stages. Account and code ownership are written into the agreement. Later features are confirmed before extra work begins, so the first version remains a scope you can review.
Working together across cities
We work online with businesses across Australia and overseas. If you'd prefer to meet in person, we can arrange it in Sydney, Melbourne or Perth.
Questions before you start
Do I need an app or a website?
Not always. We look at how often people will use it and what they need to do. An existing tool or a mobile-friendly website may be enough; a custom app makes sense when it solves a clear, repeat-use problem.
iOS, Android or a web app?
We assess this after understanding the users and the flow. The proposal names the platform and defines its development and release scope. A platform choice is not a promise that every possible device or distribution route is included.
What belongs in the first version?
The useful flow agreed after the prototype review. We define its features, review milestones and boundaries in writing. Requests beyond those boundaries are discussed as further work, allowing you to consider their costs before extending the project.
Who owns the code and accounts?
Project-specific code ownership, third-party licences, service accounts and handover conditions are stated in the agreement before development. Ask about access and future maintenance at that point so the delivery arrangements match the way you plan to run the app.
Discuss the work you need
Describe the repeated task you want the app to support and who would use it. If you have an initial idea or flow, include it. We can discuss a prototype, the first useful version and the work to quote.
Last updated: 2026-10-08