Matt McInnis wanted to go to a few baseball games. This is how he came to spend roughly $9,000 on season tickets, build a desktop application, train a pricing algorithm and attract the attention of IBM. The original ambition had been considerably smaller: enjoy the Blue Jays with his wife, Pam, without paying an absurd amount for the privilege.
He had paid about $110 for a home-opener seat he remembered as a $20 seat. Then a friend could not come, leaving him outside the stadium trying to sell the spare. A woman passing with her daughter noticed his Western university shirt. The daughter had one too. McInnis remembers the mother’s expression as a small, silent referendum on the value of higher education.
His response was to buy season tickets. The discount, he reasoned, would let him sell seats to friends and leave enough room for a few outings of his own. The purchase consumed about two-thirds of his savings at the time. He tells the story with an appreciation for its questionable proportions. Saving money had acquired an unusually large entry fee.
The $9,000 solution to a $110 ticket
Owning the tickets created another problem: how much should each one cost? McInnis wrote an Electron application that collected information from the Blue Jays’ website and StubHub. Comparing listings over time helped him construct a dataset, which he used to train an algorithm to price his seats. The application could then send his friends an email with the available tickets.
His approach to identifying sales was an inference from changing listings, as he described it, rather than access to a ticket exchange’s completed transactions. That distinction matters. The interesting accomplishment was making a usable system from the information he could gather. It had an audience, a purpose and a button he could press when he wanted it to work.
McInnis credits that project with helping open the door to IBM. It is a pleasingly awkward origin for an enterprise AI career: a baseball fan who had become annoyed enough to create his own homework. By then, however, he had already spent years teaching himself to program. The tickets gave those skills a particularly memorable demonstration.
The classroom followed him
He grew up in Aurora, Ontario, studied mathematics and went into teaching because he wanted to improve the way people learned it. Working in university help centres and as a teaching assistant, he had seen students in other disciplines struggle with required mathematics. A statistics course could obstruct an entirely different ambition. He thought better teaching could change that.
His teaching career took him to Prince Albert, Saskatchewan, and later to Centennial College. He began learning technology to make things that might help him teach. Electronics, programming and classroom questions became entangled. He recalls using children’s Arduino books because he found them more useful than the books intended for adults. The professor was quite prepared to accept a younger reading age.
The learning continued through evenings and weekends around a full-time job. He started with web pages, then moved into applications and databases. Online courses helped him understand what was happening beneath the code. He particularly valued a University of Washington course on the connection between hardware and software. Wanting a result kept pulling him toward the next unfamiliar mechanism.
One project was a browser tool for sending a webpage and a short note to his girlfriend, now his wife. It was a meaningful application to him because it had a back end and a database, and because the two people who wanted it could use it. Two users were sufficient to justify the work. Nobody had to manufacture a market forecast.
Another was Where The GOOD Is!, a website built around short videos encouraging people to volunteer with Toronto charities. He recruited filmmaking help and approached charitable organizations. The project also gave students something concrete to examine in web analytics: a site they could promote, with traffic they could study. Volunteer recruitment and a programming lesson shared the same address.
“I appreciate software that has opinion sometimes.”
Matt McInnis, in conversation, 2022
That mixture explains more than a tidy list of job titles. McInnis’s projects joined learning to something outside the lesson: a friend, a classroom, a charity or a baseball season. His argument for personal projects comes from having needed their motivation himself. After a working day, an exercise that matters to you has a better chance of getting opened again.
Five months, starting again
At IBM, and later Microsoft, he worked with large companies on AI and data-science problems. He enjoyed both jobs. Microsoft offered the chance to work more deeply on projects, while his own company occupied the remaining hours. Typist was built through evenings, weekends and vacation days used for meetings. A holiday allowance can disappear remarkably quickly when every customer has a college calendar.
Typist began with keyboarding software for students preparing for administrative careers. Its next substantial undertaking was document production: helping students learn to create properly formatted business letters and other workplace documents. McInnis sought faculty willing to help shape it. They would describe the work, respond to prototypes and, if the product met their needs, use it in their courses.
A developer helped produce a prototype in Rails. A college saw it and wanted changes. McInnis could see a route to a working product, but also a problem with the system underneath it. Comparing uploaded Word documents took too long. A classroom would send a burst of submissions together, precisely when the product needed to give everyone a useful response.
To rebuild the document-production system after deciding the prototype’s architecture would not carry it through.
The cost of keeping enough capacity waiting for those bursts threatened the economics. He decided the processing needed to move to a different arrangement, using JavaScript and functions that could run as demand arrived. The technology mattered because of a very ordinary event: a roomful of students finishing a test at about the same time.
There was also an educational problem inside the engineering problem. If a student mistyped two characters, the software needed to recognize the rest of the work and respond proportionately. Losing the marks for an entire paragraph would be a poor account of what the student had done. Comparing expected and submitted text, while preserving meaningful feedback, required more than simply checking whether two files matched.
He had five months to rebuild. When he explained the situation to his Microsoft manager, she encouraged him to go. He spoke with Pam and gave notice. The departure carried a specific piece of unfinished work into the next stage of his life. He remembers a difficult summer. A functioning demonstration had been followed by the less glamorous business of making it survive a class.
The learning after the qualification
The classroom remains visible in how McInnis introduces Typist to instructors. His micro-course breaks information into short portions, followed by quizzes or practical activities. It is designed to leave someone with a class set up and a sense of what to do in the semester’s first weeks. Teaching the teacher gets the same attention as building the software the teacher will use.
His public introduction says he has collaborated with faculty at more than 45 colleges. That is a statement about collaboration, rather than a dated count of paying customers. The work itself concerns unshowy skills with consequences beyond the exercise: typing accurately, preparing a letter, interpreting instructions and getting enough feedback to attempt the task again.
Watch the coding session ↗In 2024, discussing recruitment on Toronto Metropolitan University’s podcast, McInnis returned to the question of learning. Similar-looking applications make it difficult to identify who will do well. He looks for evidence that someone kept learning after formal education ended. A project, volunteer work, another course or a microcredential can all offer something concrete to ask about.
The preference fits his own experience. A person explaining why they made something is giving an interviewer more to examine than a list of technologies. There is a need to understand, a series of decisions and the evidence of an attempt. McInnis has described that as particularly useful in a small business, where employees must notice what needs doing.
He has also been explicit about what he wanted from work: autonomy over when and where he worked, freedom to choose problems and the possibility of financial independence. Those preferences helped him decide that he wanted a technology business. They also sit beside the practical demands of customers. You can choose the company; a class still needs its software ready when the semester begins.
His GitHub introduction offers the domestic version of the same curiosity: coffee shops, video-game machines and learning dances with Pam. There is room for things made simply because they are enjoyable. The baseball application belongs in that company too, despite the substantial bill. It solved a problem close enough to matter, then led somewhere he had not planned to go.
McInnis’s career makes a persuasive case for giving an interest some machinery. The result may be a company, a new job or a small convenience shared by two people. In his case, a wish to attend a few games produced a data project. A wish to help students produced Typist. The next question has often been practical: what would it take to make this work?