Skip to content

Instantly share code, notes, and snippets.

@phillmv
Created July 24, 2020 15:39
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save phillmv/87777eb4fb2c5906081940b09000a719 to your computer and use it in GitHub Desktop.
Save phillmv/87777eb4fb2c5906081940b09000a719 to your computer and use it in GitHub Desktop.
A letter to Toronto city hall councillors

Hey!

I just heard about this agenda item that went thru the exec: http://app.toronto.ca/tmmis/viewAgendaItemHistory.do?item=2020.EX15.5

Professionally, I'm a software engineer and entrepreneur. I don't have the time to evaluate this deal in detail but this has a weird smell to it. Questions that come to mind:

  1. Why single sourced? What's the rush? This doesn't have a COVID timeline.

  2. Contra staff, the city actually does hold a lot of risk. The contract may expire in three years, but replacing an integration that replaced 22 existing payment processes will be a significant, many-months-long project that can easily cost (a few) millions of dollars. Once we're in, it will be a lot harder to leave!

  3. At a glance, this actually runs contrary to the City's Corporate Strategic plan of "Financial Sustainability" and "Well Run City" in two ways:

3.1) Collecting revenue is a core function of the city, and outsourcing this function represents a reduction in the city's capacity to execute on vital projects.

3.2) The financial sustainability angle is an accounting trick; it merely moves the capex and opex cost off the city's books and directly onto ratepayers. To wit: if the city plans on moving a billion dollars in transaction volume, it can get better than 2.35% in credit card fees - probably in the 1.7% to 2% range, depending on the payment network.

--

My intuition goes like this:

A unified payment & invoicing gateway is a lot of work, and at the scale the city deals with, it is a non-trivial project. That said, it is a well defined problem space, with lots of prior art, and in which many programmers will have experience with. Think of it like… a bridge, or an office building.

A new bridge doesn't require a lot of "innovation", and more importantly once it's built it doesn't require a lot of ongoing work. You need to maintain a bridge, or else it'll fall apart, but most of the cost happens during the construction phase. When we need a bridge built, we pay for the cost upfront; we don't give the contractor a cut of the tolls in perpetuity.

A deal structured with an existing company, with an existing product, remunerated on payment transaction volume will be faster to execute, and cheaper in the short-run. But mechanically, I get the sense that in the medium to long-term it'll cost Toronto taxpayers a lot more than if the city built something in-house.

An innovative solution here would be to form a new entity, ideally with local talent, to develop this solution and have the city hold equity in the company. That way the fee structure is at least less problematic.

These are my intuitions from skimming this report. I'm not an expert in municipal governance, but it just smells weird.

Have a nice day,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment