Evolving companies need evolving systems.
Pacesetter puts directional drilling tools thousands of metres underground and trusts their software to keep up. System limitations have a way of sneaking up on you. It doesn't happen all at once. It's a list of changes you've been meaning to make, a workflow that's gotten more complicated than it needs to be, a fix that takes longer than it used to. One day you look at that list and realize the system can't keep up with the company it’s supposed to serve.
Pacesetter knew exactly what they wanted. They had a clear picture of where the system needed to go. What they needed was the right team to help them build it.
Pacesetter
directional drilling
Sector
Directional drilling · energy services
Engagement
Operations platform rebuild
COLLABORATION
Embedded with Pacesetter's dev team
DEVICES
MWD laptop · dog house RFD
LEGACY STACK
Specialized visual programming language
NEW APPROACH
Unified, role-specific platform
DATA
Cloud-connected · real-time
OUTCOME
One system, built to last
The challenge
Not broken. Just not built to last.
The limitations weren’t failures. They were ceilings. Individually manageable, but together they made the system harder to scale and harder to hand off than it needed to be.
01
Specialist-dependent
maintenance
maintenance
The legacy system ran on a specialized visual programming language that most developers have never worked in. Any change or fix ran through a single person. The knowledge lived in someone’s head, not in the software.
02
Log management
was manual
was manual
Data lived locally on whichever device recorded it. Retrieving a log meant knowing where to look and having physical access to the right machine.
03
Multiple applications
The main system didn’t run in isolation. Operators juggled multiple separate programs alongside it, switching between tools that were never designed to work together.
04
A workflow that
assumed expertise.
assumed expertise.
Experienced operators knew the next steps, which parts of the application to use, and how to get where they needed to go. Not having this knowhow meant spending more time navigating than doing real work.
The client
A clear vision. The right team to build it.
— Pacesetter
“It’s been working great, and it’s been reliable, but it needs a change.”
Pacesetter came to Nexxt Ideas with something many clients don’t have: a well-defined picture of where they wanted to go. They understood their constraints, had mapped out the roadmap, and knew what a better system needed to do. Nexxt Ideas brought the technical architecture and proof-of-concept work to get there.
The work was a real back-and-forth. Nexxt Ideas embedded with Pacesetter’s own development team, showing up at the warehouse, running demos, and iterating based on what operators actually said. Design decisions were tested against real workflows before anything was locked in.
The approach
Built with operators in mind.
The new platform carries forward what the legacy system did well. The rest was rebuilt around a cleaner experience, with design focused on surfacing the data operators actually need in a way that feels familiar.
01
Role-specific views.
Operators see a view tailored to their role, showing them what matters for their job without waiting on anyone else to configure it.
02
Real-time data across every device.
Gone are the days of data being isolated to a device. Data is now centralized and available throughout the entire Pacesetter system.
03
Cloud-connected logging.
Data syncs automatically. No manual retrieval, no physical access required. When something needs to be reviewed or corrected, it’s there.
04
Step-based navigation
A checklist-style workflow guides operators through each stage of a job, with less room for process errors and less reliance on what individual operators happen to know.
05
Application consolidation
Several of the separate programmes operators had been juggling are now integrated or replaced. One place for the work.
06
A foundation for what comes next.
The architecture was built to grow. Future capabilities are already in scope, and the system gives Pacesetter a real base to build from.
The solution
What the engagement taught us.
01 ·You know your paint points
The best clients come in with a roadmap
Pacesetter didn't need us to diagnose the problem. They'd already done that. Our job was to bring the technical depth to match what they already knew and work alongside their team to build it. That's a different kind of engagement, and honestly a better one.
02 · Real feedback
Operator buy-in starts at the design stage
The new system was shaped by the people who would use it. Feedback from real workflows changed real decisions. That matters in an industry where a clunky interface doesn't just annoy people, it slows them down on a job site.
03 · Real Feedback
Hidden logic is a liability
Things operators had to guess or infer about system state, like which tool was active, were small friction points in isolation. Surfaced explicitly in the UI, they become something the system handles for you.
The results
What changed
Metric
Before
After
Metric
Data visibility
Before
Device-local, inconsistent between operators
After
Real Time
Metric
Log access
Before
some Manual retrieval, physical device access required
After
Automatic cloud sync, accessible remotely
Metric
Workflow guidance
Before
Operator knowledge assumed
After
Step-based checklist, guided navigation
Metric
Application footprint
Before
Several separate program used in conjunction
After
Consolidated into one system
Metric
Maintainability
Before
Specialist-dependent, hard to hand off
After
Accessible to a broader development team
Metric
Future development
Before
Limited by legacy architecture
After
Foundation in place for continued builds
What’s next
Foundation for what comes next.
The new architecture wasn’t built to solve only today’s problems. It creates a platform Pacesetter can continue to build on — with future capabilities already in scope, ready to extend as the company keeps growing.
the handoff
A foundation Pacesetter owns.
Two years of embedded work produced more than a new interface. It produced a platform Pacesetter’s own team can run, maintain, and grow — without specialist dependency, without calling someone else when something needs to change.
01
A codebase their
team can work in
team can work in
No specialist language. No single point of failure. The system is built on a stack accessible to a broader team, so future changes don’t require finding the one person who knows how.
02
An architecture built to grow.
The platform wasn’t designed to solve today’s problems and stop there. The structure supports future capabilities — new views, new integrations, new workflows — without rebuilding from the ground up.
03
A process that runs the job
A structured workflow is now part of how Pacesetter operates. The system carries the sequence, so experienced operators can focus on the work — not on remembering which application to open next.
This is our impact
We turned a reliable system into a scalable one.
A system that worked well in experienced hands now works for everyone — knowledge captured in the software, the active tool always visible, and the same real-time picture on every device.
Knowledge in the software
Capability lives in the platform now — not locked behind one specialist’s language.
The invisible, made visible
The active tool and current run are always surfaced — assumed knowledge becomes shown information.
One platform, real-time
