Engagements
Three acts. Every engagement.
Most clients come to us with a problem, not a brief. Every engagement maps to one of three acts — wherever you are in the journey, there is a structured starting point. You do not need to start at Act 1.
Act 1
Understand your operation
1
Act 1
Map what needs to be built
2
Act 1
Agree on the plan
3
Act 2
Build and set up on site
4
Act 2
Make sure it works
5
Act 2
Train your team and hand over
6
Act 3
Keep it running
7
Phase 1
Understand
Before any money goes into a build, you need to know how your operation actually works — not the brief, the reality — and whether technology is the right answer at all. That is what Act 1 delivers.
Discovery Sprint
We do not take a brief and design to spec. We spend time in the operation — talking to the people who run it, visiting the sites where it happens, and looking at the systems already in place. We are trying to understand not just what you want, but what the operation actually needs.
What you walk away with
- Requirements specification — what the operation needs, in plain language, no longer held in one person's head
- Site assessment report — what we found on the ground, including the workarounds and constraints the brief never mentions
- Constraints and assumptions register — every dependency that shapes the solution, surfaced before a build, not halfway through one
- Feasibility assessment — whether technology is the right answer, and what kind. If the answer is no, we say so here — not after the build
Typically two to four weeks, scoped to your operation.
Two reassurances, both genuine
The honest-verdict guarantee
A Sprint that concludes you shouldn't build is still a successful Sprint. You're paying for a straight answer, not a sales pitch.
Fixed fee, with scope protection
If we underestimate work that was within the agreed scope, we absorb it — you never get a surprise invoice for our misjudgement.
Proof
For Air Environment, the knowledge and systems that ran a critical operation were trapped in a single person. We turned that into a detailed breakdown and a workflow map — the operation, finally on paper and readable by the people who depend on it. Breaking the system down so different people could understand it delivered real value on its own, before any technology was built.
Phase 2 · Act 1
Solution Design
Phase 2 translates what we learned in Phase 1 into a concrete design. Not a finished product — a clear definition of what the solution needs to look like, how it will work, and what it will take to build it.
This phase does not include any development, installation, or deployment. Its only purpose is to produce a design good enough to plan and price from.
How it works
Target-state design — We define what the operation should look like after the build: architecture, data flows, integrations, automation logic, and security requirements.
Specification — Hardware, software, and infrastructure requirements defined in full. Integration interfaces specified — what connects to what, and how. Assumptions, risks, and external dependencies documented.
Review and sign-off — You review and approve the design. Nothing moves to Phase 3 without written confirmation that the design reflects what you need.
What you walk away with
- Solution design document — the proposed future-state system in full, written to a level you can review and challenge
- System architecture diagrams — components, data flows, and integrations visualised, not described
- Hardware, software, and infrastructure specifications — everything defined before procurement begins
- Integration interface specifications — what connects to what, and how
- Indicative bill of materials and implementation roadmap — how the build will be sequenced
Typically one to two weeks, depending on system complexity.
Two reassurances, both genuine
Design only — no build commitment required
You can commission a Solution Design independently. It stands on its own and gives you something to review, challenge, or take to a second opinion before committing to a build.
Phase 2 closes on your approval
We do not proceed to planning without written approval. That approval confirms two things: the design accurately reflects what you need, and it is sound enough to plan and build from.
Phase 3 · Act 1
Project Plan
Phase 3 is where the design becomes a commitment. We take what was agreed in Phase 2 and work out exactly how it will be delivered — the sequence, the resources, the risks, and the governance.
This phase does not involve building anything. Its purpose is to ensure that when the build starts, both parties know what they are committing to.
How it works
Schedule and resources — Set the project timeline, confirm resource allocation, and sort procurement and site access.
Risk planning — Map every risk with a response, so the things that derail builds are owned before they happen.
Plan approval — You approve the plan. Nothing moves into Act 2 until you are confident in what is being built, when, and at what cost.
What you walk away with
- Project plan — delivery sequence, milestones, and resource allocation agreed in writing before the build starts
- Risk register — every risk identified, rated, and with agreed mitigations, so the things that derail builds are owned before they happen
- Governance and communication plan — how decisions get made, how progress gets reported, and what no surprises actually means in practice
- Confirmed readiness criteria for Phase 4 — a defined, agreed picture of what implementation readiness looks like
Typically one week, scoped with you after Solution Design is complete.
Two reassurances, both genuine
Nothing starts until this gate is passed
Phase 3 closes when both parties have reviewed and signed off on the plan. Resources are confirmed, risks are understood, and both parties agree on what implementation readiness looks like.
Fixed fee, with scope protection
If we underestimate work that was within the agreed scope, we absorb it — you never get a surprise invoice for our misjudgement.
Phases 4–6
Build
Act 2 is where we build. Hardware, software, automation — or all three. The scope comes from what we learned in Act 1. We build for the environment it will actually operate in, and we hand it over in a way your team can genuinely own.
Before you commit to the full build
Field Prototype
Before committing to a Production Platform, prove the approach works in the conditions it will actually operate in. Not a lab demo — a working version in your real environment, tested against real constraints.
- Tested in your actual environment — conditions and all
- A clear go / no-go decision before full investment
- Early identification of the dependencies nobody thinks about until they break
- Pre-tested before it goes to site — on-site commissioning is validation, not the first time something is switched on
The full build
Production Platform
The complete system — designed, built, installed, validated, and handed over. Not just something that works at launch. Something your team can run, change, and recover without calling us.
- Installed, configured system — in the real environment, not a lab, with full integration into what you already run
- Documentation written as we build — for the people who will maintain it, not the people who built it
- Runbooks for common scenarios and known failure modes, so your team knows what to do before something goes wrong
- Training until your team can operate, diagnose, and change the system without calling us
- A signed handover certificate — not just a delivery
Documentation is not an afterthought. It is built alongside the system, written for the person who will maintain it — not the person who built it.
Devices
Signals and control
Field
Constraints and context
Ops layer
Policy and lifecycle
People
Decisions and response
Phase 7
Own
Act 3 is where most firms disappear. We stay. Operational decay does not stop at handover — systems drift, requirements change, people leave. Act 3 is the commitment to keep the system running and genuinely owned as the operation around it changes.
Operations Retainer
This is not a helpdesk. We monitor proactively, flag issues before they become visible problems, and keep the system evolving with your operation instead of quietly degrading away from it.
- A named point of contact at Slash Tech — not a ticketing system
- Proactive monitoring — we tell you before something breaks, not after
- Monthly reporting on system health and work completed
- Scheduled maintenance — planned, not reactive
- Ongoing evolution as your operation grows
Continuity over time
Stabilize and document operational behavior
Reduce drift and refine rollout policy
Evolve safely without losing context
Who this is for.
A good fit if you
- Have a system that needs to run reliably in the field — software, hardware, or both
- Have moved past the prototype stage and need something real
- Are responsible for operations and need things to keep working
- Are building something that needs to last more than twelve months
Probably not the right fit if you
- You need something built and handed over with no intention of maintaining it
- Your primary criteria is lowest cost and fastest delivery above everything else
- There is no one in your organisation who will be responsible for the system after we leave
Not sure which act you're in? That's what the Fit Call is for.
You do not need a polished brief. Tell us about one part of your operation on a free 25-minute Fit Call, and we will tell you honestly which act makes sense to start from — or whether you need us yet at all.