AARON SPINDLER

I didn't get into tech because it was trendy. I got into it because I liked figuring out how stuff worked, then tinkering with it until it worked better. The first version of that was Minecraft. I started by playing, then got curious about hosting my own server, then ran one from my MacBook until I discovered the practical problem: if I took the laptop out of the house, the server went down.

That eventually led to a retired 1U enterprise server with 72 GB of RAM, which felt completely ridiculous at the time. It was fast, loud, and absolutely not appropriate to run in a normal house. It also taught me a lot. The stakes got bigger over time: robotics, school, consulting, government systems, startups, and now healthcare payments. The thread is still the same: build the system, run it, find the weak spots, and make it better.

The Early Spark: Game Servers and Community

My first real experience with "production" systems came from gaming, not school. From 2012 to 2014, I ran and maintained game servers for a community called Falcon Gaming. I started with Minecraft, mostly because I wanted my own world and my own rules. Then I wanted plugins, better uptime, better performance, and a server that did not disappear every time I left the house with my laptop.

The retired 1U server solved one problem and created others. It had 72 GB of RAM, which felt unreal, but it also made the kind of noise that makes everyone else in the house question your choices. That was probably my first honest lesson in infrastructure tradeoffs. Performance, uptime, cost, heat, noise, and real users all mattered at the same time.

I was also moderating the community and building tools to keep things fair. It was the first time I felt the full loop: build it, run it, fix it, improve it. If the server was down or lagging, nobody cared how clever the plugin was. That lesson has followed me into every serious system I've worked on since.

Learning Through Building: Robotics and the Value of Iteration

In 2015, I became the lead programmer for Team 3710 Cyber Falcons. I originally joined because I was interested in programming, but I ended up loving the camaraderie and the challenge just as much. Robotics had a way of making software feel physical. A bug was not just a stack trace. Sometimes it was a robot turning the wrong way, missing a sensor reading, or failing right when everyone was watching.

We designed, built, and programmed robots for sports-themed competitions across Ontario. The team placed first at a regional event, and students I mentored went on to win a World Championship. Robotics taught me how to think in systems, work with a team, and ship under real-time pressure. When competition day is coming, you don't get to debate architecture for three weeks. You build, you test, you fix it, and you go again.

This was also where I first got comfortable working across disciplines. I was writing code, but I was also wiring controllers, dealing with sensors, and working closely with the mechanical side. That habit of crossing boundaries has helped me in almost every job since.

Formal Education: Computer Science Foundations

I studied Computer Science at Ontario Tech University from 2015 to 2017. At the time, it felt like the default right path. I liked computers, I liked programming, and school seemed like the official way to turn that into a career. The truth was more complicated. I did not love school, and I had a hard time with subjects that did not catch my interest.

I didn't finish the degree, but that time still mattered. It gave me more theory than I had before: algorithms, data structures, and a better way to think about complexity. It also taught me something useful about myself. I learn best when I can connect the material to a real system, a real need, or something I actually need to build.

Even during school, I kept working on real systems. That mix of theory and practice became a pattern pretty early: learn the fundamentals, but stay grounded in shipping systems that actually work.

Consulting and Early Products

Spindlers started as my first real exposure to the overlap between business and programming. The short version is that I got grounded, and the only way I could touch a computer was if I built my dad's company a new website. That was an effective loophole. It also showed me that software was not just a personal hobby. It could make a business look more serious, bring in customers, and solve real operational problems.

In 2014 I started consulting under Spindlers, and I've worked with businesses to design, build, and maintain web and desktop applications across the full SDLC. Consulting forced me to get pragmatic fast. It's easy to over-engineer when you're building for yourself. Client work doesn't let you hide there for long. You learn to care about clear requirements, reliable delivery, and getting feedback early.

In 2019 I started RoomScout.ca, a roommate management and marketplace platform. It came from a problem I already had during university: I had rented a whole house and needed to find and manage roommates. The pain was not just finding people. It was bill splitting, transparency, household coordination, and small recurring chores like garbage and recycling schedules.

RoomScout became a full product from idea to production, built with Django, Redis, Celery, and AWS. I added automated moderation using AWS Rekognition and sentiment analysis, which made me think harder about the gap between a feature that sounds smart and one that actually saves operational time. RoomScout taught me how fast product complexity and technical debt show up when you're moving quickly and making real tradeoffs.

Automation at Scale: Canada Border Services Agency

In 2020, I joined the Canada Border Services Agency through an innovation program focused on government proofs of concept. It was my first real look at public-sector systems at scale, and it was eye-opening. There were too many workflows where skilled people were spending their time clicking through web interfaces instead of doing higher-value work.

One of the major projects was an automation application that reduced processing time for permit holders at points of entry by 93%, creating more than $10M in annual savings. The part that stuck with me is how small the team was. A developer in Victoria, BC, and I were able to help remove a huge amount of repetitive manual work. That was a big moment for me. It showed me how software can directly improve real outcomes for people and institutions, not just make a dashboard look nicer.

Technically, it was a deep dive into asynchronous processing and automation. The system used task queues and tools like Selenium and BeautifulSoup to automate workflows, and the surrounding work included CI/CD, training, and agency-wide API standards. It wasn't glamorous, but it worked. That job really cemented my belief that boring tech, done well, can have a huge impact.

ShippingTree: Reliability, Tests, and Delivery

From 2021 to 2022 I worked at ShippingTree. I joined a startup because government work moved slowly and did not pay very well. I also learned that third-party fulfillment was not the most fulfilling industry for me, which is a joke I am legally obligated to make at least once.

The work itself still taught me a lot. I led design and development for new features and integrations, increased test coverage from 5% to 67%, and put a CI/CD pipeline in place. That immediately improved reliability and release velocity. It also reinforced something I still believe strongly: investing in quality systems early pays off.

I also helped reduce technical debt during a migration from an MVT architecture to a microservices architecture using Django REST Framework and React. Those transitions can get messy fast, but sometimes they're the right call for scale. The main lesson I took from it was simple: migrate with intent, and don't forget the people who have to maintain the system after you're done.

Pearl Health: Building for Primary Care

I joined Pearl Health in January 2022 as a Software Engineer and became a Senior Software Engineer in June 2023. I wanted to work at a healthtech startup with a promising goal: make healthcare better and help reduce Medicare cost inflation. That mission mattered to me because the software is connected to something much bigger than the software itself.

I currently focus on payment and financial performance systems for primary care. A big part of that work has been revamping payment validations and related workflows so providers get paid correctly and on time each month. The stakes are clear: if the system fails, people don't get paid and trust disappears fast.

I also write technical specifications for integrating financial performance and care quality indicators into client-facing applications. That means taking messy complexity and turning it into something clear and useful for providers, while keeping the underlying systems auditable. The work spans Python, Django, TypeScript, PostgreSQL, dbt, AWS, and infrastructure automation, and it has included payment architecture handling more than $55M across 500+ providers. It's a mix of backend systems, data engineering, and product impact, and honestly it's the best blend of complexity and meaning I've found so far.

Team Bio

I founded Team Bio in 2023 and led strategy and product delivery for the venture through 2025 alongside my main career track. The idea came from joining Pearl in a fully remote environment and realizing how hard it was to learn about coworkers as actual people. You could work with someone every week and still know almost nothing about them outside of meetings and tickets.

Team Bio was my attempt to solve that problem while also learning new tools. The product combined profiles, trivia, coffee chats, and shared context, with integrations using OpenAI, Mapbox, Stripe, and Google APIs. Working on it pushed me further into product thinking, and it gave me a useful way to explore AI without treating it like a gimmick.

Achievements

• Reduced permit-holder processing time by 93% in a CBSA automation project, generating more than $10M in annual savings.
• Increased test coverage from 5% to 67% and implemented CI/CD at ShippingTree.
• Led payment architecture and validation improvements at Pearl Health across more than $55M in payments for 500+ providers.
• Built RoomScout.ca end-to-end to solve real roommate-management problems like bill splitting, transparency, and household scheduling.
• Founded Team Bio and shipped an early product that combined profiles, trivia, coffee chats, and API integrations into one workflow.
• Led a robotics team to a regional win and mentored students who later won a World Championship.

Continuous Learning

I try to keep learning a little outside my day-to-day work too. Some recent certifications and courses that have shaped how I think:

• Understanding Neural Networks
• The Definitive Guide to Celery and Django
• Mastering Django
• The Complete Self-Driving Car
• Python for Financial Analysis and Algorithmic Trading

How I Think About the Work

Over the years, I've moved away from chasing frameworks and more toward chasing outcomes. The early server days were a blunt version of that lesson. Nobody cared what the setup looked like if the server was down, slow, or too loud to live with. The same idea applies to bigger systems. If a system handles money, people, or time, it needs to be clear, observable, and durable.

I also think strong specs and good defaults are underrated. A clear technical spec is often worth more than rushing into code. It gets people aligned, cuts down on rework, and makes quality visible earlier. That mindset has helped me deliver more predictable outcomes, especially in messy domains like healthcare.

Lessons Learned

• Reliability is a feature. If the system is down, nothing else matters.
• Automation is leverage. You can scale impact without scaling headcount.
• Tests are a speed multiplier. They enable you to move faster, not slower.
• Simple does not mean easy. It means fewer moving parts and clearer ownership.
• Real constraints teach fast. A MacBook server, a loud rack server, a robot, and a payment system all make different tradeoffs visible.
• Shipping beats theorizing. Real users are the ultimate test.

What I Want To Build Next

I want to keep working on systems where accuracy and trust matter. Payments, healthcare outcomes, data pipelines, and decision support are all areas where good software can make life better for people. My focus is to keep building systems that are dependable, scalable, and understandable: software that quietly does its job well for a long time.

If you want more context on how I think about building on the web, I have already written a bit about it in my first post, Cut Out The Bloat, and Be Your Own First Customer.