Zac Townsend

Dan and I had an unusual time applying to Y Combinator.

In September 2012 we started talking about the company that would become Standard Treasury. Primarily we were interested in why there wasn't an API platform that focused on ACH.[1] It's a core payment type and is pretty much a pain in everyone's behind. Things came to head at Thanksgiving time, when Dan and I had dinner at a restaurant in New York City and hashed out a vision we had for a "Twilio for financial services".

After that, though, I interviewed and got an offer from Stripe in the first week of December. Then began a little bit of a dance. John and Patrick Collison were very generous with me while I tried to decide whether to work at Stripe or start my company with Dan. Many long emails were exchanged and the Collisons showed a huge amount of patience as I decided what to do. In the midst of that — in early December, two months after the deadline — Dan and I applied to Y Combinator for the Winter 2013 batch.

But, we didn't hear anything back from YC.

Dan was still working on Giftly and I was really in love with the Stripe team and culture. After a couple amazing phone calls with Patrick, I decided that I should go work at Stripe, really get a feel for startup life, and learn all I could.

I moved to San Francisco and the Friday before I was to start at Stripe we got the following email from Harj:

"thanks for the yc app. do you think you'd be able to make it to PA on Monday [my first day at Stripe] for a late interview? it's the day before YC officially starts but we'd like to meet you in person."

I had literally spent days making this big decision to go work at Stripe, not do my own thing, move to San Francisco (which Stripe paid for) all to have YC want to interview me at the 11th hour! Shit.

We didn't take the interview. It just didn't feel quite right.

But that one little email from YC likely made it destined that I couldn't stay at Stripe for long: that it likely wasn't going to work out for me there. That tiny bit of validation — which really isn't much validation at all when you think about it, they interview a lot of people — propelled Dan and me think about the idea more, to talk about the idea more, and to mention it to friends. Eventually I was bringing it up at Stripe and had a conversation with the General Counsel about how to handle my IP questions.[2] Dan and I would be emailing people at Wells Fargo from our personal computers at night trying to figure out what was possible for our business, while I would be talking to other people at Wells Fargo during the day. We couldn't talk to venture capitalists, but we were socializing the idea with people, some of whom were even investors in Stripe.

That wasn't sustainable.

Stripe taught me a huge number of lessons about engineering culture, transparency, emailing writing, business development, and more. First and foremost though it partially demystified the startup world for me. I had worked in government before and held startups in awe. They are awe-inspiring. Building a company is so implausibly difficult. But in many ways when you're employee 37 at a startup, particularly one that is killing it, you think a lot about starting your own company. It only highlights the idea of being a founder. It only dares you to build a similarly great company.

So we applied to YC again. We got an interview, again. Again, I wavered and wasn’t sure that I wanted to leave a rocket ship. Again, we turned down the interview.

Then it all came together at the same time.

Dan’s company, Giftly, was sold — he knew the deal was coming together. That happened on a Friday. On Monday, Patrick and I had a serious talk where it was decided that I’d likely be happier if I did my own thing. In fact, my one-foot-in, one-foot-out approach hadn’t done Stripe any favors or made me particularly popular within the company, and it turned out to be better for both me and them that I move on.

On Monday night we emailed YC to ask for that interview we were offered. We emailed alums we knew. Several of them told us to “just go down there and wait.” Thankfully we didn’t have to make that decision. On Tuesday morning Kirsty, YC's CFO, emailed us. If we could make it down to Mountain View in an hour then we could interview that morning.

We were very nervous and frantic. We rushed down, driving 85 on the 101. Dan and I are practicing our pitch back and forth. We’re coming up with questions to answer. We are incredibly nervous. We hit traffic — you always hit traffic on the 101 — and we freaked out. We weren’t really prepared at all.

We arrive at YC, check in, and although we’re a minute late, so are they. We sit down to wait. When you’re waiting to interview at YC they have some alumni there to chat with you. To calm you down. They told us we would have a minute or two to present our pitch and then we would get questions. Try to be succinct. You’ll do fine.

We walk in and we shake hands with the partners. We begin to sit down and before our butts even hit the chairs, Sam Altman shoots “Isn’t your business just Dwolla?”. The rest of the ten minutes went by as a blur. [3]

That night I got the phone call. We had gotten in to YC. They made us the offer and I accepted. The phone call finished with Geoff asking, “Can you make our introduction session tomorrow morning?” Another trip to be taken on the 101.

Footnotes

[1] We either weren't aware of or very impressed by some of the existing solutions. 

[2] One of Stripe's secret weapons is their General Counsel. He's a lawyer whose first instinct is "we'll find a way" not to say "no". [

3] During the drive from San Francisco to Mountain View, Dwolla had announced their Series-C led by Andreessen Horowitz

This post was originally published on the Mayoral Performance Analytics Initiative blog of the Ash Center for Democratic Governance and Innovation on December 5, 2012, but the blog no longer exists. As I'm currently attending the Code for America 2013 Summit and it reminded me of the idea. I never did write the rest of the series and David Eaves wrote a great response to me.

Guest Post: Introducing the idea of an open-source suite for municipal governments

VOICES FROM THE FIELD: Zac Townsend We will occasionally feature guest posts from those working in local governments. This is the first by Zac Townsend, the Senior Technology Policy Advisor and Mayor's Office Fellow in Newark, New Jersey.

New technologies are transforming the way that municipal governments and citizens interact. Open data platforms are releasing increasing amounts of information to the public, allowing anyone to understand and interact with the inner workings of government. Washington, DC, San Fransisco, and New York have all seen civic “hackers” build software applications on top of open city data. In many other cities, citizens have new avenues to report information and to make service requests. The Office of New Urban Mechanics in Boston is allowing citizens to make service requests through their Citizens Connect smartphone and text message applications, while Code for America has supported many cities in building applications for citizens to more easily make service requests through web applications.

Yet, much of the promise of modern technology has not improved the capacities of governments to get things done, to provide better services, or to directly support the most vulnerable populations. Too often, technology is used an excuse for why a particularly policy idea or service plan is not possible.

Tony Blair, in a short piece on transforming government in the 21st century, notes that government effectiveness and implementation are at the heart of good governance. He continues that “only systemic change, as opposed to incremental reform, will allow government to keep pace in a rapidly changing world”.

A systemic change is possible in municipal technology. As Linux changed operating systems and Mozilla Firefox changed the web browser wars, an open-source software suite of municipal government software could change municipal technology and, more importantly, municipal services. Open-source software makes publicly and freely available all the source code, end-product design, and implementation details.

Over several blog posts, I will outline and argue for a joint project between cities, philanthropic foundations, and academics to build an open-source suite of software solutions tailored to small and medium size cities. This series will build on an earlier post at The Catalyst, while this post serves as an introduction to the idea and the suite. The suite would ultimately provide well-designed and well-executed versions of key municipal systems through an absolutely free set of software code for cities (and their vendors) to use, build on, and customize.

There are currently 163 small and medium sized cities. They have populations between one hundred thousand and one million people. Each of these cities have similar core backend information technology systems--either designed and built themselves or purchased from vendors. Although cities consider themselves unique with individual technology needs, the creation of one set of open-source systems would reduce the costs for all cities, make maintenance easier, and allow cities to leverage technology to improve city services.

I am calling this idea “CivicOpen”, and one could imagine it as a sort of Mozilla or Apache for civic technology. The goals are to radically reduce information technology costs, to transform public sector services through user- and citizen- centered design and technology, and to allow any city to easily use and implement one system or all the systems.

Reducing information technology costs.

Costs have exploded within state and local governments predicted to spend $60 billion dollars a year on IT by 2014. When cities realize they need new IT systems--sometimes because of a desire for new business processes but equally likely because no one has the requisite outdated skills to maintain the system--they are often so expensive that the project has to be abandoned or critical resources have to be shifted from direct services to citizens into IT backend systems. Big vendors charge individual cities tens, if not hundreds, of millions of dollars on overly-complex and overly-specified technology projects.

Overall, city governments tend to be bad purchasers of technology, often relying on vendors to tell them what they need, to train their staff, and to even to write requests for proposals. By creating a freely available core set of systems--that is well designed and well executed--every city will have the option to implement core systems more cheaply (even if they need a vendor to customize and implement the software) when the time comes.

Transforming public sector services through user- and citizen- centered design and technology. The last twenty years have seen staggering advances in technology, user interfaces, and user-centric design while municipal governments have been left behind. Cities have been saddled with outdated, bespoke, and inefficient software solutions. These older system are are used as an excuse to avoid positive change-- “we can’t do that because our systems won’t allow it”--so services cannot be improved because of an old system that implements an outdated process from many years ago, in an ugly and unconsidered way.

CivicOpen would be an opportunity to use modern technologies to improve service delivery through user- and citizen-centered design, service design, and ethnographic research on service needs and delivery.

Allowing any city to easily use and implement one system or all the CivicOpen systems. Cities tend to have technology systems that sit on two sides of a spectrum: either overly customized on one end or an off-the-shelf closed-source solution that is not customized at all. Either way, interoperability and information sharing can be very expensive or impossible for municipal governments, and cities can get locked in a custom built or a closed-source ecosystem where only the products of [insert vendor name] play well together.

With freely available source code, CivicOpen will allow cities to tailor the suite to their needs, either by using or not using all the core systems, adding their own software as needed, or customizing the available software as far as needed. The suite would also be built with well-exposed and well-documented application programming interfaces (APIs) that will allow developers to load and utilize components as needed.

Jump-starting civic innovation.

By making this large, targeted investment in civic technology, CivicOpen will create and foster a large systemic change with municipal governments. The suite would change the cost-structure of technology in government, would bring new service designs to cities, and would allow cities to come along at their own pace.

As a preview of the series, I propose that the CivicOpen suite be designed from the start with a citizen-centric view, have data analysis and visualization available, facilitate open data and transparency at its core, be place-based and geocoded, and have best practices built into it. With open source software, cities would be able to have a core set of technology available to them for free, while still having the option to implement customized versions at low-cost. By being open-source, OpenCivic would allow any city to share code openly with other cities, and allow for upgrades to be propagated, for free, to cities based on others' work. The project could be jointly conducted by a coalition of alpha cities, and a series of academic, for-profit, and community partners. This public-private partnership will build a working software suite that would help retire billions of dollars from the cost structure of local governments with the following components:

• Budgeting and Financial Planning
• Financial Management and Contracting
• Personnel and Payroll System
• Citizen Relationship Management--Service Requests and Fulfillment
• Licensing and Consumer Protection
• Work / Asset / Inventory Management
• Land Use, City Planning, and Mapping
• Grants Management

Over the coming weeks, I will write posts that more fully elaborate the problems I see in government IT, the advantages of open-source for government, the design principles for the suite, the component systems of the suite, and a possible organizational structure of the joint initiative.

Zac Townsend is the Senior Technology Policy Advisor and Mayor's Office Fellow in Newark, New Jersey.

Dan and I have an angel fund called Deciens Capital. It is very small, with just a few hundred thousand dollars to invest. We raised the fund from friends and family a little over a year ago with the explicit understanding that we would make investments part-time.

The idea of starting a fund was inspired by our interest in some of our friends' startups. We were already helping out informally — with general advice about their businesses and startup ideas. Some folks had also asked us for introductions to investors we knew. That's when we thought that maybe we should do some investing ourselves, in the companies we liked and in those run by friends of ours.

While Dan and I were mulling that over, we came to realize that all of the businesses we liked were businesses that had some strong offline component or connection. They were marketplaces or in financial technology, education, government, eldercare, etc. They shared the core idea of improving the efficiency of some "real-world" process. Software eating the world indeed.

But that cliché doesn't do the future justice. In a comment on HN, PG noted that the massive fortunes of the future will be made by "startups in industries that didn't previously have them." That encapsulates the idea much better: that's agriculture (Sourcery), payments (WePay, Stripe, Balanced, Square), lending (LendUp, Lending Club, Capital Access Network), startup investing (Anglelist, WeFunder), insurance (Oscar), laundry (Prim), house cleaning (Exec, Homejoy), accounting (Indinero), etc. And let’s not forget banking (Standard Treasury). Many if not most industries can be improved with an injection of technology and the introduction of the startup ethos (disruption, growth, efficiency, data, etc.).[1][2]

In part, of course, we invest in these companies because we think there are fortunes to be made in them. Most of the economy is still untouched by the methods used by Silicon Valley's engineering-first companies. One advantage here, though, over some online-only businesses — such as social networks, photo sharing apps, etc. — is that you know the markets exist. Health insurance is out there waiting to be disrupted. But it's a schlep. Those businesses which figure out how to bring technological innovation to existing industries seem to be closer to having known, demonstrable value. Part of what I mean is that their having positive outcomes seems more likely/predictable. So, they seem like a better bet. But their value can also be more defined. It is more concrete because the need is evident.

This leads to the second reason we invest through this lens — we don't know if we have any comparable advantage in understanding technological innovations that are internet-only. In the winter 2013 YC batch there were approximately five big data companies. We have no idea which one is better. Put another way, we sometimes feel too stupid or too ignorant to judge whether this responsive-first web design tool is better than that other responsive-first web design tool, or this big spreadsheet is better than that big SQL table manipulator. We just don't know which one will get more traction. That's our own limitation. But when it comes to complex real-world systems and figuring out who has the best plan to jigger innovation into them... well, there we can shine. We have done it in the past and are trying to do it now. That's something we understand. We grok it. We're good at it, too.

Dan and I have invested in eight companies so far: Fuze Network,Tendertree, SponsorHub, [Keychain Logistics] (https://www.keychainlogistics.com), True Link Financial, wevorce, 7 Cups of Tea, and Simple Legal. In the near future, I'm going to write a blog post on each company and why we invested in them. The list is pretty clear to us though: credit card for the elderly, pushing money on to your credit card, eldercare, truck shipping, divorce, emotional support, and legal billing. I can even use those very short phrases to describe those businesses to the technophobic. Dan and I like being able to do that, and we hope to keep finding great companies like these.

[1] I adopted this paragraph from a comment I made on HN, which inspired this post. [2] This list of industries (and the companies listed in each industry) is non-exhaustive.

The Financial Times published a letter of mine:

From Mr Zachary Townsend.

Sir, Banks are “Realising the promise of new technologies” (The Connected Business, FT.com, September 30), despite being saddled by outdated and outmoded core banking technologies. Some of the best but least studied innovation is happening inside treasury management and commercial banking groups. There, far from the public eye, new technologies – such as application programming interfaces – are allowing financial institutions and businesses of all sizes to interact in new, faster ways. These technologies speed the flow of transactions for the business while decreasing risk and delivery costs for the bank.

Unfortunately, Eric Openshaw and Larry Albin continue the false dichotomy between the business and technology functions of banks. Ultimately, banks are “big” data and technology companies. At the centre of every bank is simply a data store that records who has how much money and the rules governing transaction processing. We call this data store a core banking system, which is then surrounded by delivery channels, risk management and other technologies. Banks, their boards and their shareholders will come to realise that huge portions of bank budgets and headcounts can be replaced by modern web technology if architectured correctly. Those financial institutions that remake themselves fastest in the model of software engineering first companies such as Google or Facebook, including picking a forward-thinking technologist as chief executive, will be the true benefactors of this new era in finance.

Zachary Townsend, Co-founder, Standard Treasury, San Francisco, CA, US

I wanted to expand on my post from yesterday after some great feedback. When I said that credit card processing is a commodity business, I was not saying that it was a bad business. It is just a hard market to be in exactly because processors need to get to a huge processing volume to generate meaningful revenue. In the credit card processing business, volume is the only metric that matters.

Companies that operate well in credit card processing are to be praised and any industry that is producing multiple companies with multi-hundred-million-dollar valuations is a very healthy one.

Having said that, many companies create something that is heavily differentiated from their competitors and are able to charge for that differentiation. Apple creates laptops that are 10x better than PCs running Windows, so many folks are willing to pay 2-3x as much for their laptops. Apple is able to take their differentiation and convert that into increased revenue and better margins.

In the world of credit card processing one cannot charge more if one says they are in the card processing business. Even if someone created an idealized solution for dealing with the payments system, once a user reaches sufficient scale they will be more concerned with the variable components of the processor’s cost than the lower fixed costs of development and set up.

That makes perfect sense. Most business wants to commoditize all of their inputs and differentiate their outputs. Technology businesses, and big businesses that rely on contractors or system integrators, will eat a month’s worth of horrifically painful engineering as it is much cheaper over the long-term than paying even an extra few basis points (hundredths of a percentage point) on each transaction. That is, if a business is doing enough processing that even small increases in marginal cost matter then increased upfront fixed costs won’t.

To succeed in credit card processing, a processor can succeed in one of two ways.[1]

The first is to clearly be in the credit card processing market, have razor thin margins, drives toward massive volume, and create a much better product so folks use the product at all. Businesses will not pay the processor more for a better product though. The processor will invest more and more money in their product but with margins that get more and more squeezed on the one hand by knowledgeable large enterprises, the processor’s most valuable customers, that want things like an interchange plus basis points pricing. And, on the other hand, processors will get squeezed by the absolute fixed costs of what the banks and card networks charge the processor. Adding insult to injury, as the processor gets better known fraudsters pay more attention to it, increasing the cost of simply operating

That is a hard place to be. That is the place that Braintree, Stripe, WePay, and Balanced operate in as well as a ton of companies that we are not as fortunate enough to have heard of. Ultimately, Square is there too — although their situation is slightly more complicated. It is not necessarily a bad business to be in: any entrepreneur would be happy to be added to the list of successful processing companies.

The other way to succeed in credit card processing is to figure out how to be a payments company without appearing to be one so you can just charge much more. That is what most marketplace companies succeed at doing. They have built a better and better product experience, whose heart is credit card processing, and they can charge for that something better. What they have done commoditize their input — credit card processing — and differentiated their output into “booking blackcars” or whatever it might be. Ultimately, their core business is having their customer pay with credit card and then paying it out to a wide set of merchants, e.g. drivers, via electronic checks (ACH). That’s Airbnb, Eventbrite and others. Whether or not those companies go on to use Braintree or Stripe as their payments gateway does not matter because they are making such a large percentage of every transaction.

Addendum: Braintree’s Revenue

Braintree is actually a gateway, rather than a full-stack processor, for many of their best known and largest customers. That is a high-margin game with little risk. In this world, they make $49/month and $.10/transaction from those customers. That might make their margins higher than I suggested yesterday. It is actually hard to calculate the precise difference or relative value of those different business models without knowing how much they would make on a percentage basis, the average ticket size for those customers, and how much risk the company’s processors take on.

If this is all mumbo jumbo to you, dear reader, then keep your eyes peeled for future posts explaining various parts of the payments system.

[1] This is a model for argument. I think it’s useful but I also know that I’m simplifying important and complex businesses into gross categories.

Thank you to Daniel Kimerling, Jim Brusster, Brent Goldman, and Spencer Sugarman for suggestions and edits.

Braintree sold to PayPal (Ebay) this morning, which reminded me that I am a payments skeptic and especially skeptical of credit card processing.

Credit card processing is a commodity business. Companies advertise fees like 2.9% but the vast majority of that goes to the card networks and to the issuing and acquiring banks. On top of that, the majority of processing does not actually happen anywhere near the posted rates. Most processing is by large merchants (following the ubiquitous 80-20 rule) and those merchants get volume pricing and other discounts.

The margins in the card processing business are incredibly small. A company would be very lucky to make .5%. That’s not discounting the money lost to risk or the cost of acquiring customers.

Let’s take the biggest online example. PayPal processed $144.973B last year. If that was entirely processed over credit cards than they would have made - assuming 0.5% - $0.724B on processing itself. $724 million isn’t all that much.

PayPal actually made more like $5.6B last year because they make most of their money by having people use electronic checks (ACH) while charging them credit card like fees, and by charging customers high, and opaque, foreign exchange and transfer fees.

Compared to the high margins of other software companies it isn’t all that great to be in the credit card processing business. One needs a lot of infrastructure to make not all that much money, and ultimately the biggest player in online processing business gets most of their revenue from other parts of their business.

Braintree is processing $12B a year with few revenue streams outside processing. A generous reading of their net income would put them at $60M a year. I doubt they are actually near that number and, as mentioned in the press, I assume that their purchase price is so high because of a generous understanding of the value of the Venmo network.

A bunch of folks have asked me what the acquisition means for Stripe. Having worked at Stripe I think they are the best online processor on the market. They have the best solution and certainly the best team.

But is the acquisition good for Stripe? Yes and no. Yes because over the next few months Stripe is going to have an influx of great customers and their transactional volume.

The one caveat is that, inside payment circles, Braintree was known for bidding ridiculously low in bake-offs between them and other processors for hot companies like Github, Airbnb, etc. So low that they might be losing money on the deals just to secure them. Some of these customers might not move over to Stripe exactly because they’re being given an unreasonable deal, one that PayPal can sustain. Those companies have also already built their payments systems on top of the Braintree’s infrastructure.

On the other hand, this deal pegs Stripe's short-term market value. Stripe is growing faster than most YC companies but let’s assume, given their time in market, that they are processing single digit billions a year. If Braintree sold for $800M and is processing $12B than the deal depresses Stripe’s implied valuation. I don’t think that matters since they have plenty of cash but the sale highlights how hard it is to be in the processing business. And, Stripe is the best there ever has been in the business.

I actually think that there are two interesting places to play in the credit card processing system these days. One is to be what I call a vertically specific payments company. That’s Airbnb, Uber, and Eventbrite and a different blog post entirely. The other is if you can own more than one layer of the processing stack like Credorax does in Europe.