Background & Experience
Academic & Early Career
I studied mechatronics engineering at the University of Waterloo because I wanted to learn what I couldn’t teach myself: disciplines like mechanical systems, electronics, and control theory.
Waterloo’s co-op program was a crash course in the real world. Over five years, I did six internships that let me test every direction I was curious about. Some highlights:
- Built internal reporting tools for BlackBerry’s hardware team (back when people still used them).
- Developed a vision system at Toyota that tracked tagged tools in 3D space on the assembly line.
- Joined Thalmic Labs as the fourth engineer post-Series A, helping shape a wearable startup that eventually became North (acquired by Google).
- Spent two internships at Apple — first designing electro-mechanical test fixtures and sensor-data pipelines, then joining the Special Projects Group’s autonomous vehicle team.
That mix of experiences, along with a few more years building at Apple and a hardware startup, gave me a broad view of how different industries operate and what it actually takes to ship complex systems.
Building a Company
I’ve always wanted to work on something that made a larger impact on the world. Several of my family members work in the medical field, so I always thought I’d end up starting something in that space — partly because the tooling is so outdated, and the problems are evergreen and multivariate.
Right after college, I actually started a company called Scintilla where we built a contactless ultrasound system using photoacoustics and vibrometry. I learned that while it’s important to develop at the edge of research and science, it’s just as important to solve a critical need and iterate in the market.
Julie and I started working together on an unrelated project during the early days of the pandemic. We had a revenue-generating business within six weeks, and I realized that sales and marketing are just as first-principled as engineering. She had spent her career selling to large organizations and understanding organizational psychology, so we were naturally a good fit as a team.
We started thinking more seriously about what we wanted to tackle over a longer timeframe, and building tools for hardware engineers was a clear overlap of our experiences. This is what led to Dystr.
Dystr
Dystr is an AI-native computation environment for engineers working on complex physical systems to write, reproduce, and share analysis. Previously, extracting computational value required significant software experience. Now that AI has lowered this knowledge barrier, the opportunity lies in writing, versioning, and managing calculations while keeping them associated with specific projects.
Mechanical, electrical, and manufacturing engineers need to maintain calculations, datasets, and contextual documents within cohesive project frameworks. These teams develop computational and data processing workflows rather than full software applications. Their goal isn't building complex interfaces but creating and using deterministic computations with minimal programming knowledge, such as physics-based calculations or analyzing oscilloscope datasets within discrete projects.
For many customers, learning sufficient code for computational analysis has presented a persistent barrier. They typically resort to MATLAB only in extreme cases, otherwise defaulting to paper, pen, and TI-83 calculators. With Dystr, they perform engineering calculations while maintaining documentation, sharing with teams, and facilitating reviews.
This capability extends naturally to automating manufacturing data analysis or any recurring engineering process. Our customers create computational tasks that process periodic datasets, such as measurements from vendors monitoring assembly lines.
In essence, we're developing an "agentic notebook" where professionals maintain calculations, notes, datasets, and external references while collaborating with AI models on their engineering analysis.
Landscape of Engineering Analysis Tools
The analysis tools available to engineers working on physical solutions haven't evolved significantly in decades.
While software tools have gotten better at helping people build and deploy software, engineers designing circuit boards, mechanical systems, or manufacturing processes are still stuck with outdated methods. It’s not uncommon to see teams responsible for critical systems, from aircraft components to automotive safety features, still doing calculations on TI-83s or paper notebooks!
MATLAB was the last significant platform focused on non-programming engineers, but it still requires substantial coding knowledge. Specialized tools like ANSYS or COMSOL address narrow applications but don't solve the broader computational needs.
A critical bottleneck is that existing platforms either demand programming expertise that most engineers lack or offer limited analytical capabilities. This forces organizations into inefficient workarounds: having software engineers build custom tools, maintaining outdated systems, or simply accepting the productivity limitations.
The result is significant wasted engineering talent, slower innovation cycles, and knowledge that remains trapped in isolated notebooks or individual workstations.
Current Use Cases & Customer Outcomes
I come from a mechatronics background, so we initially built Dystr with those workflows in mind. But we’ve been surprised by how quickly engineers outside that core have started using it.
Civil engineers working on structural analysis have found significant value in our platform despite different data types and calculations. One civil engineering firm that conducts forensic investigations has reshaped its reporting process using Dystr. Previously, writing their detailed 100-200-page reports required 40+ hours of engineering time. They've now implemented a workflow that automatically retrieves relevant analyses from their document library based on investigation findings, cutting report creation time by orders of magnitude.
We’ve also seen unexpected use cases from manufacturers. Some teams now process incoming test data, sent from partners via email, through Dystr automatically to generate analysis reports without any manual intervention.
Long-Term Roadmap
We see Dystr becoming the central computational backbone for engineering teams working on physical systems, and evolving into an “engineering team in a box” with a deeply thought-through series of applications designed specifically for technical professionals.
Over time, the platform will take on more of the routine analytical work and let engineers focus on higher-value problems and expand their technical scope. It’s creating a new generation of engineers who work across traditional domain boundaries—no longer constrained by computational limits or knowledge silos.
An electrical engineer, for example, might move from designing a circuit board to building test fixtures to overseeing manufacturing, with Dystr providing support at every step. That kind of interconnected workflow marks a shift from isolated specialties toward more integrated engineering practices.
Our goal is to give engineers tools that let them follow problems across disciplines, design better systems end-to-end, and spend more of their time actually building instead of wrestling with fragmented tools and manual workflows.
Q&A
Favorite Invention
I tend to think less about singular achievements and more about the cumulative stuff we take for granted. Things like modern water and electrical infrastructure that weren’t one big breakthrough, but the result of thousands of small, compounding improvements.
What’s wild is how these massive systems have become so reliable and invisible that we barely notice them anymore. That shift, from extraordinary to everyday, is to me, the clearest sign of impactful engineering.
Favorite Interview Question
I don't have a standard question, but I focus on understanding a candidate's first-principles thinking. When working with emerging technologies like AI, experience with specific implementations matters less than fundamental understanding. I often introduce a basic concept relevant to the role and explore how deeply the candidate can analyze it. This reveals whether they've memorized surface knowledge or genuinely understand underlying principles. For engineering roles, this might involve discussing material properties or circuit behaviors; for product positions, it might be user interaction patterns.
What I'm evaluating isn't specific knowledge but their ability to reason from foundations to applications, a critical skill when working with rapidly evolving technologies.
If you’re curious to learn more about Dystr, you can reach Nabeel on LinkedIn or try their platform at dystr.com
