Product Design & Development

From problem to production.

Discovery, design, engineering, QA and deployment in one team — whether you are taking a validated idea to market or turning a process your business runs on spreadsheets into software.

Two very different conversations end up needing the same capability. We have written both below — start with the one that sounds like you.

If you are taking an idea to market

You have validated that people want this. Perhaps you have sold it before it exists, or you have run the process manually for a year and know exactly where it breaks. What you need now is a product that real customers can use, built well enough to grow on but not so elaborately that you run out of runway proving the point.

• Product discovery, positioning and scope definition
• User research and journey mapping
• UX and interface design, prototyped before it is built
• Technical architecture chosen for where you are, not where you hope to be
• MVP engineering — web, mobile or SaaS
• AI integration where it genuinely improves the product
• QA, accessibility and performance work
• Cloud deployment, monitoring and support after launch

If you are an established business with a process problem

You are not launching a startup. You have a business that works, and a process inside it that has outgrown the spreadsheet, the shared inbox and the off-the-shelf tool everybody works around. The software you need is not generic — it should be designed around the way your business actually operates, including the parts that are unusual.

• Client information is spread across email, spreadsheets and a chat app
• Someone spends hours a week chasing staff for updates
• The monthly report is rebuilt by hand every time
• Enquiries are missed because nothing is tracked in one place
• Compliance evidence is gathered in a panic before an audit
• Your off-the-shelf system does 70% of the job and blocks the rest
• Approvals depend on one person and their inbox
• Two teams keep separate versions of the same data

These rarely need more staff. They usually need a system.

What we typically build

How we deliver

1. Discovery
→
2. Solution outline
→
3. Fixed scope
→
4. Design
→
5. Build
→
6. QA
→
7. Launch
→
8. Support

You get the solution outline before any commitment, and the scope is fixed before any build starts. Changes after that are handled as variations, priced and agreed — not absorbed silently and discovered at the end.

1. 1Discovery — What the product or process must achieve, who uses it, what it integrates with, and what success would look like.
2. 2Solution outline — A written view of the approach, suggested scope and indicative plan. Free, and yours to take elsewhere.
3. 3Design — Journeys, then interface, prototyped and reviewed before engineering starts.
4. 4Architecture — Data model, integrations, hosting and the decisions that are expensive to reverse later.
5. 5Build — Delivered in increments you can see and respond to, not revealed at the end.
6. 6QA — Functional, cross-device, accessibility and performance testing, with automation where it earns its keep.
7. 7Launch — Deployment, monitoring, handover and documentation.
8. 8Support — Monitoring, updates, security patching and continuing development against a roadmap.

We do not just build software. We run it.

We do not only build software for clients. Ausvanta is our own compliance and operations platform for Australian NDIS providers — rostering, GPS time tracking, incident management, claiming and audit evidence. We designed it, built it, and continue to operate it for paying customers in a regulated sector. That means releases, uptime, support load and production incidents are our problem too, not just a handover document. See Ausvanta.

Who we usually do this for

Australian organisations of roughly 20 to 500 staff — professional services, healthcare and care providers, logistics and transport, recruitment, education and training, financial services, property and e-commerce — alongside founders with a validated idea and a realistic budget. We are equally comfortable with a first product and with an internal system that has to work on Monday.

Where this sits in our services

• UI/UX Design — research, journeys, prototypes and interface design
• Custom Software Development — web platforms, portals, SaaS and integrations
• Mobile App Development — iOS, Android and cross-platform builds
• Quality Assurance — functional, accessibility and automated testing
• Cloud & DevOps — hosting, deployment pipelines and monitoring
• AI Workflow Automation — if the real problem is a process rather than a product

Questions we get asked

What is an MVP, and how do you decide what goes in it?

A minimum viable product is the smallest version that lets real users do the whole job end to end — not a demo, and not a feature list cut in half. We work backwards from the one outcome the product must deliver, keep everything on the critical path to that outcome, and defer everything else. The test we apply is whether someone could rely on it for real work. If not, it is a prototype, and it will not tell you what you need to know.

How long does it take to build a first version?

For a focused MVP with a clear scope, typically three to five months from discovery to launch, depending on integrations and how much design research is needed. Internal operational tools are often faster because the users are down the hall and the process already exists. The largest variable is rarely engineering — it is how quickly decisions get made and how complicated the systems we need to integrate with turn out to be.

Do we own the code?

Yes. On full payment, ownership of the custom work built for you passes to you, along with the repository, infrastructure and documentation. We retain our own pre-existing tools and libraries and licence them to you as part of the deliverable. You are not locked into us to keep the product running, and we will hand over cleanly if you take it in-house or elsewhere.

How much product discovery do we actually need?

Enough to stop you building the wrong thing, and no more. For an internal process the answer is often a week of watching how the work really happens. For a new market-facing product it usually means user interviews, a competitive read and a clickable prototype before code. We would rather spend two weeks finding out a feature is unnecessary than three months building it.

Should AI be part of our product?

Sometimes, and less often than the current conversation suggests. AI earns its place where the work is genuinely language-shaped or pattern-shaped — reading documents, drafting, classifying, summarising, recommending. For most of what a product does, ordinary software is faster, cheaper, deterministic and easier to support. We will tell you which parts of your product would actually benefit.

What happens after launch?

Software is not finished at launch; it is only in production. We offer ongoing support covering monitoring, incident response, dependency and security updates, and continuing development against a roadmap. Some clients keep us on indefinitely, others use a handover period to bring it in-house. Both are fine, and the choice should be yours, not a consequence of how the code was written.

Already have a system that has become hard to change? That is a different job — see Software Rescue & Reengineering →