1.What is Punch Through
Punch Through is a software and systems engineering partner specializing in connected medical devices. We’re a multidisciplinary team based in Minneapolis with embedded engineers, mobile developers, cloud architects, and systems designers who’ve been working in highly regulated environments for over a decade.
We work with everyone from early-stage startups building their first connected device to established manufacturers evolving entire product lines. Over the years, we’ve helped bring dozens of devices to market, from implantables to remote monitoring systems.
What sets us apart is how we approach problems. We’re system architects who understand how technical decisions ripple across the entire product. A Bluetooth stack choice impacts your FDA submission timeline. A mobile UX decision affects patient adherence rates. A cloud architecture pattern determines your post-market update strategy. We work across the full stack because connected medical devices demand that kind of thinking, and the products we help build actually work in clinical use.
2.What about Punch Through’s work and impact makes you the most proud?
I’m proud of how we show up when things get hard. There are moments in every project where teams hit walls, like connectivity issues threatening FDA timelines, security concerns discovered late, system dependencies the architecture didn’t account for.
We don’t just fix the immediate problem. We help teams understand why it happened and how to prevent it next time. What makes me most proud is that clients who came to us panicking about a single project become long-term partners who bring us in early on subsequent products. That trust is earned through consistent delivery and honest conversations, especially when the answer is “this will take longer, but here’s why.”
3. What is on the horizon for Punch Through? What is something exciting people can expect to see from the organization in the near future?
What’s ahead is helping clients move faster without compromising quality. We kept seeing teams rebuild the same foundational pieces like device provisioning, mobile BLE libraries, and cloud architecture. Every project starts from scratch, costing time and money.
We built what we call our Connected Systems Accelerator to help solve this challenge. It’s a collection of pre-engineered components we’ve built and refined across dozens of projects. Clients get proven building blocks already validated for regulatory and technical requirements. Shorter timelines, fewer surprises, stronger foundation. We make it available at no additional cost because projects go better when everyone starts ahead.
4. Tell us about your professional journey in the healthcare industry. How did you first get involved and what were some of the key moments that led you to working with Punch Through?
My background is in computer engineering. I started in regulated markets where I learned that compliance can’t be an afterthought, it has to be built in from day one.
My first medical device project was in wound care. Seeing pilot data showing how our device affected healing rates, realizing my design directly impacted whether someone could keep their limb or their life. That changed everything. It was a different kind of pressure, but it hooked me.
When I joined Punch Through, we weren’t a MedTech company. We solved hard Bluetooth problems across industries. But medical device companies kept finding us when they hit technical walls. Those clients kept coming back and referring others. That’s how we ended up fully committing to this space. We followed where our capabilities met the most meaningful technical problems.
5. What’s the biggest challenge you’ve faced as a leader and how did you navigate it?
Learning when to say no. Early in my career, I thought good leadership meant always saying yes to clients, to opportunities, to growth. But in MedTech, that can be dangerous.
Saying no is uncomfortable. Telling a potential client their timeline won’t work and watching them go to a competitor who says yes. Pushing back on scope when everyone’s excited about a feature, but you can see it’s going to create problems down the line. Protecting your team’s capacity when the business could use the revenue.
Every one of those decisions creates short-term tension. You lose the project, you disappoint people, you leave money on the table. But the alternative? Overpromising to clients, compromising on testing, burdening clinicians, burning out your team? Those costs show up later when they’re much more expensive.
The clients who understand why we make those calls are the ones building products that will succeed in clinical use. For teams building something that works when lives are on the line, we’re all in.
6. What advice would you give to aspiring healthcare leaders who are looking to make a lasting impact?
Most advice for healthcare leaders focuses on what to do. But the harder question is usually: what not to do, or what to do later.
Every connected device project has ten critical paths and finite resources. The teams that succeed aren’t necessarily the ones who do everything perfectly. They’re the ones who correctly identify which three things absolutely cannot fail, and which seven can be good enough for now.
That kind of judgment is hard-earned. It’s knowing that you can iterate on your mobile UX post-launch, but you can’t fix a flawed security architecture without a recall. That you can live with a clunky provisioning flow in V1, but you can’t retrofit Bluetooth reliability if the RF design is wrong.
So my advice is to be ruthless about focus. Take a hard look at what your team shouldn’t do right now, and commit fully to the few things that matter most.
7. Outside of your career, what are some of the favorite ways to spend your time?
When I’m not at work, I’m spending time with my family. We’re often out exploring, no matter the weather. When I need some me-time, I’m usually out on a trail somewhere. I’ve been a mountain biker for years, and it’s a great way to disconnect and reset.
8. What do you appreciate most about being part of the Medical Alley community?
We’re fairly new to Medical Alley, even though we’ve been doing this work for years. Most of our projects came through direct referrals or clients outside the region, so we were building without being visible locally.
What drew us here is being in the room with people who understand the regulatory realities, the clinical stakes, and why partnerships built on trust matter more than speed. We’re here to learn from this community and help raise the bar for what connected medical devices can be.
9. How do you see the healthcare industry evolving over the next 5-10 years?
The big shift is architectural. Medical devices are moving from being endpoints to being nodes in distributed systems.
That changes where the complexity lives. The question used to be “does the device work?” Now it’s “does the device work when the hospital WiFi is congested, when the mobile app is two OS versions behind, when the cloud service needs to push an update but the device is mid-procedure?” The companies that understand they’re building distributed systems with medical device components, not medical devices with connectivity features, are the ones who’ll succeed.
The real challenge ahead is making systems more resilient when any piece can fail independently. Making devices smarter is the easy part.
10. How can the Medical Alley community rise to face those changes and challenges?
The technical challenges we see every day aren’t unique to our clients. We’re all dealing with making connectivity work in real environments, navigating regulatory requirements for software-driven devices, and building systems that hold up under clinical use.
Medical Alley can be the place where companies share not just their wins but their technical near-misses. Where we compare notes on what FDA is actually asking and what works in deployment. Where device makers and health systems align on real integration challenges early. That would accelerate how quickly we all get better products to patients.
We’re here to learn from this community and share what we’ve learned building these systems.
