From first conversation to handover.
A project starts with a conversation and a separately agreed discovery step. The proposal then sets the scope, deliverables and approval points before building begins.
When you get in touch
- 1We read your message and let you know whether a call makes sense.
- 2You speak directly with the person who would lead the design and build.
- 3If we can help, we explain the next step and what it involves. If we can't, we'll say so.
The route
Five stages. Your approval at every gate.
Select a stage to see what happens there.
What happens at each stage, and what you receive.
From discovery on, no stage starts until the one before it is signed off.
| Ref | Stage | What happens | You receive | Your decision |
|---|---|---|---|---|
| 01 | Conversation We learn what you want to fix, who uses it and what good looks like. You receive An honest view on fit Your decision Whether to go further | We learn what you want to fix, who uses it and what good looks like. | An honest view on fit | Whether to go further |
| 02 | Discovery A structured look at your tasks, systems and the rules that apply to you. You receive A map of how your work moves, and what should stay with a person Your decision What must stay human | A structured look at your tasks, systems and the rules that apply to you. | A map of how your work moves, and what should stay with a person | What must stay human |
| 03 | Written proposal Scope, assumptions, exclusions, cost and timing, written down. You receive A written proposal with a fixed price for each build stage Your decision Approve, change or decline | Scope, assumptions, exclusions, cost and timing, written down. | A written proposal with a fixed price for each build stage | Approve, change or decline |
| 04 | Build in stages Working software built in stages, and reviewed with you at the end of each one. You receive What each stage delivers, as set out in the proposal Your decision Sign off each stage | Working software built in stages, and reviewed with you at the end of each one. | What each stage delivers, as set out in the proposal | Sign off each stage |
| 05 | Handover or ongoing support Code, documentation and access handed over to you, or we look after the system for you. You receive Code, a runbook and access, or a support agreement Your decision Accept the handover or the support terms | Code, documentation and access handed over to you, or we look after the system for you. | Code, a runbook and access, or a support agreement | Accept the handover or the support terms |
How cost and timing are set.
Every project is quoted in writing after discovery, once we both understand the work. These are the things that move it.
Discovery fixes the scope. Discovery is a separately agreed first step. Its findings set the scope, and the build is quoted against that scope.
- Systems to connectFrom oneto many
- Condition of your dataFrom cleanto scattered
- People and roles using itFrom a fewto many
- Rules that applyFrom generalto regulated
- Build or extendFrom extendto new
- After launchFrom handoverto we run it
Nothing on this page is a commitment as to time. Scope, sequence and cost are set out in a written proposal specific to your project.
Who decides, and what happens when things change.
You stay in control of scope and spend. We tell you when something affects either.
Approvals
You sign off at every gate
The proposal, each build stage and the handover all need your written approval before the next step starts.
Changes
Changes are agreed in writing
If priorities shift, we describe the change and its effect on scope, cost and timing, and you decide before it goes ahead.
Visibility
You see progress at each stage
Each build stage ends with a deliverable you can review before you sign it off, as set out in the proposal.
What you'll need to prepare.
You don't need to prepare anything before the first call. We'll ask for each of these during discovery, when it's needed.
- Someone who can make decisionsUsually the owner or manager responsible for the work being changed.
- The people who do the workA short conversation with them usually tells us more than the documents do.
- Examples of the workSample forms, emails, reports or spreadsheets, with names and other identifying details removed. We'll tell you which parts we need.
- A list of the systems you useAccounting, email, CRM, scheduling, anything else the work touches.
- Access, when it's neededGranted through each system's own invite or permission settings, never by sharing a password.
Every permission is recorded, scoped and removed when it's no longer needed.
When we need access to one of your systems, we ask for the smallest permission that does the job, granted through the system's own invite or permission settings. Each grant goes on a register you can see.
| System | Access | Granted by | Why | Status |
|---|---|---|---|---|
Accounting
| Read-only adviser invite | Business owner | Build stage 1: map invoice data | Revoked |
Email / Microsoft 365
| Guest access, one shared mailbox | IT administrator | Build stage 2: route enquiries | Active |
Hosting
| Deploy role, one project | IT administrator | Build stage 2: release changes | Expires at handover |
Example rows only.
You know where your data goes
Before discovery starts, your agreement names every service that stores or processes your information and the country it's in, including any overseas. You decide what to share.
Passwords never travel by form or email
Access is granted through your own systems.
Access ends when the work does
At handover every permission on the register is revoked, or kept only if you ask us to run the system.
AI with a person in charge
Where AI tools help draft or sort information, a person reviews the result before it's sent to you or relied on. Some of these tools are run by a provider that processes information overseas, so we use them on your information only with your written consent.
How to recognise a genuine request from us. We will never ask for a password. If a request from us looks unusual, email hello@redrocksystems.com.au before you click anything.
After launch, you choose.
You can take the system in-house or have us look after it, and you can change your mind later.
Handover
What you receive to run the system yourself.
- Source code and ownership as agreed in the proposal
- A runbook your team can follow
- Access transferred to you, and ours revoked
- A walkthrough with the people who'll use it
Ongoing support
We look after the system on the terms in your support agreement.
- Fixes, and monitoring as set out in your support agreement
- Changes you ask for when your process or the rules you work under change, as set out in your support agreement
- For AI agents, a person reviews the exceptions they raise, within limits you set
Questions people ask before the first call.
Do I have to commit to anything on the first call?
No. The first conversation is about whether we're the right fit. Nothing goes ahead until you agree to it in writing: discovery first, then the proposal for the build.
Why is discovery a separate step?
Because quoting a build before anyone understands the work is guessing. Discovery gives you a map of how your work moves and a scope to quote against, and you're under no obligation to go ahead with us afterwards.
How long will it take and what will it cost?
It depends on the things listed under how cost and timing are set. Both are set out in the written proposal once discovery is done, and any change is agreed in writing first.
Will you need access to our systems?
Discovery usually works from screen shares and examples you send, and any access needs your written agreement first. A build usually needs some access. We ask for the smallest permission needed, through the system's own invite or permission settings, record it on a register and remove it when the work ends. We never ask for passwords.
Will this replace my staff?
We report on tasks, never on named individuals. What you do with any time saved is your decision, and any change to someone's role should follow your own HR or legal advice.
Do you work in our industry?
We take on work in any industry, including ones our site doesn't list. Every engagement starts by learning how your business works and the rules that apply to it.
Who owns what you build?
Ownership of the code is set out in the written proposal, before any build starts.
What if we want to take it to someone else later?
The terms for that are set out in your written proposal. A handover includes the code, a runbook and access, as agreed in the proposal.
Start at stage one.
A short conversation to work out whether we're the right fit.
When we're not the right fit
If an off-the-shelf product already does what you need, we'll point you to it. If the problem is a process rather than software, we'll say that too.