About Slash Tech
We started because we kept seeing the same problem.
Technology built, handed over, and then quietly breaking down. Nobody planned for what happens after launch. We built Slash Tech to do something about that.
The belief
We build for whoever inherits this in three years.
Most technology companies optimise for launch day. The demo looks good. The handover happens. Then the team moves on and the system is someone else's problem. We think that's the wrong way to build anything that matters. So we don't do it.
Ownership changes how you build
Knowing we'll be responsible for something in three years makes us build it differently today. Better documentation. Clearer dependencies. No shortcuts that only the builder understands.
Systems outlast the people who build them
What we build has to work when the original team has moved on — because it always does. We design for the operator who inherits it, not just the engineer who commissions it.
If it can't be managed, it isn't finished
We don't consider a project done until someone other than the builder can operate, change, and recover it. That's the bar we build to.
Why we started.
We kept seeing organisations invest in technology that looked right on paper — and then struggle once it was actually in use. Not because the technology was bad. Because nobody designed it for the operation it was meant to serve.
We built Slash Tech to do something about that. It is not the easiest way to run a technology business. It is the right way.
Learning over time
Stage 1
Early projects showed us what breaks when the build team walks away
Stage 2
Field work revealed the dependencies nobody had documented
Stage 3
Running systems over time taught us what "reliable" actually means
How we think.
Real conditions before clean solutions
We visit sites before we design. We understand how the operation actually works before we propose anything. The environment shapes the solution — not the other way around.
If it can't be managed, it isn't finished
We do not consider a project done until the people who depend on it can run it, fix it, and change it — without calling us.
Ownership changes how you build
Knowing we will be responsible for something in three years changes every decision we make in year one. That is the standard we hold ourselves to.
Systems outlast the people who build them
What we build has to work when the original team has moved on. That means knowledge lives in the system — not in someone's head.
Visibility only matters if it leads to action
A dashboard that shows you a problem but cannot help you fix it is not useful. We build for the action, not just the visibility.
The team.
We work across the full picture — hardware, software, and the field. Real systems do not fit neatly into one discipline, and neither do we.
- Experience across hardware, software, and on-site operations
- People who understand whole systems, not just individual components
- Built to stay with a project — not just ship it
Founder
Jayben Bertrand
Jayben leads projects from the first site visit to the last support call. He has worked across environmental monitoring, industrial operations, and distributed systems — and holds the standard on long-term operability, not short-term demos.
Co-founder
Javier Bates
Javier works across hardware, software, and automation — finding where technology fits in an operation and building it to last. He focuses on the real constraints of how organisations work, not just the technical requirements of what they want.
If you want a team that stays past delivery.
Most technology firms build what they are asked to build and move on. We stay. We build for the people who will run the system long after we are gone — and we hold ourselves to that standard on every engagement.