Zac Townsend

The number one way that startups in Y Combinator fail is through founder disputes and divorces. It often turns out that people cannot work together or one of the founders can't really work on startups at all. So picking who to work with is one of the most critical things you can do to ensure that your startup will get through the early stages.

Y Combinator applications just opened for this summer's class. It seems like a good time to talk about how Standard Treasury's co-founders knew each other and laid the foundation for sticking together, raising a seed round, launching a product, and building a good team.

My two co-founders and I know each other in much different ways that basically mirror the two ways one should find co-founders. With Dan, we have been friends for over a decade. We have discussed founding a company together for years. We know each others habits, strengths, and weaknesses inside and out. We knew we could work together.

With Brent, we knew each other for only months before we started working together and we were constantly assessing whether we could work together, figuring each other's style out, and ultimately deciding we could be partners carefully and over time. We vetted each other in-person and through friends and professional contacts. We came to know we could work together.

If you're going to found a company with someone, I'd suggest having one of these two stories: old friends or careful decision. I have never seen anything rushed or careless work out well for the startup or the team. I have never seen it work out just because folks can agree on an idea. Startups are more hectic and trying then that. In that way, the story of how I know Dan and Brent can be instructive to the ways one should know and vet their partners.

This is the first of two posts on building our team at Standard Treasury. The second post will be on our first three engineers. Building a team is the most important priority of a startup. With a great team, one can get through most troubles. With a bad team, even the best startups can fall apart.

Two Argumentative, Balding Friends from New Jersey: Dan and I

Dan and I met at Harvard Summer School in 2003. We were not instantly best friends. I remember quite vividly the first day of our first class, Introduction to American Government. Dan was then quite similar to how he is now, at least in this one respect: we met because he walked into the classroom and, without any compunction, began introducing himself to every single person in the room. I found it strange then and although I still find it strange now, I at least can see its utility. It is why Dan focuses on business development at Standard Treasury.

I was particularly annoyed though, when I showed up to my second class, Introduction to Political Philosophy, and there Dan was, introducing himself to everyone in that classroom as well. We were the only two students who took these same two classes.

Despite whatever feelings I might have had that first day, in retrospect, it seems obvious that we were going to have a full and long-lived friendship. We were both from New Jersey, and then, as now, we have a mix of tough-guy go-fuck-yourself, sarcasm as humor, insatiable curiosity, intellectualism, and ambition.

I have this theory that lots of founders have childhood trauma (or, at least, difficulties), that motivates them towards the implausibly difficult task of building a startup.[1] A part of my deepest friendships come from a common, shared understanding of something difficult: in Dan's case, the tragic death of his father and serious injuries to his mother in a car accident when he was an infant, and in my case, my mother's alcoholism and disappearance from my life for ten years.

The important point here isn't the particular personal details of our childhoods, though. As Dan and I got to know each other that summer, we bounded over our similarities in affect, goals, and histories. We spent a lot of the summer together, studied together, explored Cambridge and Boston, and became good friends.

Harvard ended but geography kept our friendship alive. We only lived thirty minutes apart in New Jersey. We would hang out, from time-to-time, throughout our senior year, and like all teenagers of that era, we spent a lot of time chatting on AOL Instant Messenger.

It's hard to understate or understand the intensity of our friendship from there on out. We went to different colleges in different time zones. We saw each other maybe twice a year in person. But Dan was among five or six friends that I talked to nearly every day (and I feel bad that I don't have a reason to write blog posts about them all!), and one of my closest friends.

We usually simplify our friendship by referring to the month we spent together in India in 2006. It's a good synecdoche. I had a fellowship from Brown in the summer (I think I successfully had them pay me, to do what I wanted to for every summer), and Dan was traveling on to Nepal and Tibet with a UChicago group. We visited Delhi, Agra, Jaipur, and Varanasi together as poor college students. We got very sick together, rode elephants together, visited the Taj Mahal together, got lost together. It was fun, but, at times, stressful. We learned a lot about our friendship through that sort of travel. We figured out, I think, that we could work together.

After college, Dan moved to San Francisco, I moved to New York. We pursued what appeared to be quite different career paths. Dan in tech, me in government. But we're both passionate about many subjects and my interests moved closer and closer to data science and civic technology over time.

Dan and I had spoken many times about founding a company together. Whether it was the naive thoughts of two sixteen year olds or the more mature (I hope) reflections of two old friends separated by thousands of miles, it has been often in our minds. So, when I decided that I wanted to move on from the Mayor's office in Newark, NJ, I decided to pursue my interest in technology more directly, by moving out to San Francisco, working at Stripe, and being closer to my old friend Dan.

That inevitably lead us to applying to YC, getting in, and starting Standard Treasury.

Being old friends is one model of finding your co-founder but another is meeting each other through trusted friends and deciding you can work together after getting to know each other quite intensely. That's the story of working with Brent.

Bringing on Brent: Third Co-Founder and CTO

The cornerstone of our team at Standard Treasury is our third co-founder and CTO: Brent Goldman. He joined Dan and I during Y Combinator. He came highly referred from a friend (and many others), studied computer science at Caltech, and worked at Facebook on Platform for four and half years.

If you know Standard Treasury today, you know Brent. Brent and I work together on every product decision, as PM and EM, while Dan sells banks.[2].

Dan and I were first introduced to Brent in February 2013. A friend told me that Brent and Dan were his two smartest friends and that they were both thinking about starting companies.

When we first met, Brent was kicking around some great ideas and, in fact, had another potential co-founder he was working with on them. Dan and I had thoughts about Standard Treasury (then without a name) in ways that were much like our original YC application, which was filled out around the same time.

But, when we met in February, we were all casual. We hadn't incorporated Standard Treasury. Dan was still at Giftly, I was still at Stripe, and Brent was working with another co-founder. It seemed then that the timing would not work out well for the three of us to work together, although we all ended up liking each other a good bit. At the time, I remember being pretty sure that I would be at Stripe for four years!

Despite Brent’s immense interest and experience in platforms, in these early days we were just feeling each other out (and aligning calendars - including a month-long trip to New Zealand). Brent tried to sell us on some of his ideas, but Dan and I knew what we wanted to do as YC had already offered us a YC interview on the idea. I'm not sure we could sell remaking commercial banking well at the time — it is boring to the uninitiated.

What we found, though, was a lot of group chemistry — what we've come to call "founder chemistry." Our skills complemented each other, and ideas were flowing. The only issue was that we didn’t know each other and we didn't know if we could work well together long-term. Founding a company together is like a serious relationship and this was just the first date.

Over the next couple of months, as Dan and I left our respective jobs and got in to YC, Brent, Dan, and I met up every couple weeks to expand on our ideas, swap war stories, and discuss philosophies about what kind of company we wanted to run. Over time we realized that we could work together, and that we could found a company together.

So we joined forces.

Brent fills out our skill sets and together we're all well-complemented. I often joke that on almost everything (technical skill, financial knowledge, desire to talk to investors, ability to write clearly, attention to detail, etc.), that between the three of us, two of us are always at opposite ends of the spectrum, with the third acting as the mediator. It works well — it's just the right level of tension and conversation between us.

Most importantly, Brent puts engineering excellence above almost everything else and has the experience in shipping code and mentoring engineers to back it up. He's instituted a thorough code review process, sets the technical direction, and works with everyone to build sustainable, maintainable systems.

But, despite his perfectionism and attention to detail, he's also a pragmatist who will do whatever it takes to get things done — whether it's re-prioritizing or cutting features, accumulating technical debt (the right kind, with a sound plan to pay it off), or leading the charge to the long hours necessary to meet a tight deadline.

Brent is a force multiplier for engineering productivity and has infused our company with the engineering-focused culture we always knew we wanted. We lucked out in finding the right co-founder to help us build it.

Growing the Team

Just as we were formalizing our relationship with Brent, we finalized two more engineering hires. They are both dedicated and productive, and both snapped to the engineering culture Brent wanted to build. Then Brent brought in an old colleague from Facebook to fill out the core team. It's been the six of us together until our first new hire last month. We've found that we not only have an amazing team but one that is very cohesive.

In my next post I'll talk about how to find a team, what kind of team one needs to build for a successful startup, and how we did it at Standard Treasury.

[1] I even have a half-written, unlikely-to-be-published blog post on this topic, and how much I validated it through my dozens of close friends in YC. It is a hard thing to write about because it's deeply personal and it opens you up to a common line of attack: well, I had or have it worse.

[2] The division of responsibilities and founder relationships is another planned post.

This morning Simple sold for $117M to BBVA. It's great news for the team, and I think it's going to be great news for retail banking.

Simple had amazing potential but also ran into many problems and difficulties caused by being built on top of Bancorp, not owning their own rails, and starting on the retail side. Simple could never build the infrastructure they needed for the product they really wanted to ship because what they have is not a bank account as people understand it. BBVA will change that.

We chatted with Shamir for awhile in Standard Treasury’s early days. Simple walked down the path of trying to get a bank charter but never followed through. It was partially timing — they were looking into buying or becoming a bank at the worst time possible — and partially that they did not build the company's capitalization to allow them to go down that path.

Also, looking at their history, it seems like they didn’t become a bank because along the way, at every step, it appeared to be the wrong choice — why build infrastructure when seemingly there are off-the-shelf options? But when one looks at the course of the company in aggregate and all the trouble they had with their service providers (I think they restarted their integrations three times), it would likely have been easier for them and better for their customers (not to mention their shareholders) if they had gone down the bank route.

It also seems like Simple never considered starting with the business-and-commercial side of banking. From the start (according to Josh’s blog post) they were focused on retail. We think starting on the other side is the right strategy to build a large bank. That’s why Dan and I have written a step-by-step product plan for a commercial bank.

Let me talk about what I see in the idea of building a bank. (Bear in mind, though, that this is not a likely outcome for Standard Treasury).

Building A Bank Directly

Everyday I read the Financial Times because it is wise to study the ways of one’s customers. But it can be depressing. With the headlines focused on bad bets, fines and settlements, price-fixing, and inquiries into malfeasance, it can be hard to focus on what I think of as the positive power of banking. To me banking is not about capital markets, investment banking, "the one percent", or high-frequency trading. Banking's true potential is not even seen in a better retail product experience like Simple. Instead, banking is about making commerce simpler and easier for businesses and consumers alike. It’s about empowering calculated risks and enabling trade in all its forms.

I want to build a bank with the simple mission of making it easier to do business - easier to be a business and easier to be a customer of businesses. Build a bank that had that simple creed at its center and you would make different product decisions and different hiring decisions than most banks do today.

This is not a casual interest of mine (although it’s a side interest to the business I am running now). Standard Treasury builds software for banks. That is the first approximation I can get to making the world I want inside the sanity and capital bounds that most venture capitalists seem to operate under.

We need a small — technology driven — bank.

Dan and I have chatted with former and current regulators at the Federal Deposit Insurance Corporation, the Office of the Comptroller of Currency, and the Federal Reserve. We have also chatted with lawyers and bankers in the business of buying and forming banks. There is no doubt that building a bank is hard. It is the ultimate schlep. But it is possible. Every conversation seems to start with people thinking we're a little bit crazy. Every conversation seems to end with an agreement that our dream is not only possible but desirable.

I won't publish our full step-by-step product plan but I do just want to talk about what a bank run like a technology company might mean in the abstract.

Bank As Startup

One key and obvious idea to anyone who works in technology is that banks have way too many people working for them. As Dan reminds the Standard Treasury team and all our customers, the banks that will survive in the future will be those that are most able to alter their cost structures.

One senior banking official recently told us that banks are likely to go through the same type of restructuring that the airlines went through in the 80s and 90s. They had large costs and outdated ways when the money was easy. But when the well dried up and airlines had to remake themselves, many airlines simply died. Well, now, the easy money is drying up for banks, This is the moment to build the Southwest Airlines of banking.

Without focusing in on capital markets, a new bank could defeat banks on product, technology, segmentation, and customer acquisition. The bank could do this with few people (mostly engineers) and a lot of software. This is because today’s business customers don't want to talk to their banker and rarely need a branch. They want to be able to trust their bank, to feel like the goals of the bank and their goals are one, and they’d like a great product experience with a customizable and open ecosystem at its core.

What does this mean in reality? It means the elimination of the physical (“wet”) signature and the start of instant risk determinations, easy to use but powerful tools to manage money laundering and customer identification requirements, and dynamic offerings targeted to the needs of the customer, with simple user interfaces and transparent pricing. In short, the anthesis of today's banking experience.

(Notice that banks are one of only two retail categories where you walk in and cannot find a list of products or their prices. The other is healthcare.)

The Problems

Regulations. Politics. More regulation. Acronym soup. Capital requirements. Passivity requirements. Etc. I won't bore you with the details but this isn't for the faint of heart. I think that most venture capital is ignorant to the nuances of just how complicated (and expensive) this gets, and just how quickly.

We have had a lot of these ideas floating around for awhile as have others, and as we participated in a recent Twitter conversation and after today’s sale, I wonder if maybe someone is willing to take the jump with us.

I've written in earlier blog posts about how I don't think that credit card processing is a particularly good business (Credit Card Processing is a Hard Business and Credit Card Processing as a Commodity Business).

The gist of my argument is that a company in the card processing business has to reach truly massive scale before starting to profit. That is very hard to do. Square, Braintree, Stripe, and WePay prove that one can build valuable businesses but they have all achieved massive scale. Braintree after all was purchased mostly for their consumer product and its network while Stripe is working hard to build out Stripe Checkout so it can store consumer card data and do the same.

I was chatting with Jareau Wade, one of the co-founders of Balanced Payments, to get some idea of comparables on the scale. He pointed out that Vantiv processed roughly $530B last year and currently has a market cap of $5.7B. Heartland Payments processed roughly $120B last year and currently has a $1.6B market cap. At the time of Braintree's acquisition it had a processing run rate of $12B a year and was worth $0.8B. PayPal did not perceive Braintree's value as coming from their processing business, no matter how fast it was growing.

My comments on card processing led me to a thought experiment: maybe a processor could give card processing away and make money some other, higher margin way.

No independent sales organizations (ISO) - such as Stripe or WePay - could make the marginal cost of a charge zero because a huge percentage of the fee they collect goes to the card networks and their member banks (often called, not quite accurately, the interchange fee). In fact, big businesses can often get a card processing fee structure of interchange + some margin (known as "interchange plus" pricing). Maybe these processing business could charge everyone that way and find some other way to make most of their money. They can't quite make it zero margin because the processor does take on some risk but they could run this part of their business at break even.

A business that comes immediately to mind that could do this is Sift Science. They could just give processing away on top of their already profitable product. Sift Science is proving that a ton of businesses will pay them for better credit card fraud protection. They've cracked that nut but their system get better and better as they see more transaction. More data improves their algorithms and their blacklists. One way they could see a lot more transactions is if they just gave the transactional service away for free.

I'm not actually advocating that Sift Science get in to the processing business. They're running a great business and likely don't need a different path to user acquisition. It would certainly burden them to become an ISO with someone like Wells Fargo or Paymenttech. I am using them as an example though of how one could build a business that gives processing away while helping build a profitable core business.

As a contrast take Square, for example. They keep releasing (not particularly successful) products to try to get at bigger margins: Cash, Wallet, Register etc. Rather than running a processing business and then trying to find one's high-margin product it would be better to figure out a high-margin product where dirt cheap processing would be a way to get a lot of people to use it.

Below is the application that Dan and I sent in to YC. Our business model has changed a ton since then and I'm not particularly worried about folks beating us on our combination of technology, relationships, execution and payments/banking knowledge.

Also see my post from Tuesday on our story of applying to YC and my post from yesterday on application advice. Next week I'll share some of the highlights of the summer from getting in to demo day.

Your YC username:

zt

Company name:

bedrock (we're working on it)

Company url, if any:

Phone number(s):

[Redacted].

Please enter the url of a 1 minute unlisted (not private) YouTube video introducing the founders. (Instructions.)

[Redacted].

YC usernames of all founders, including you, zt, separated by spaces. (That's usernames, not given names: "bksmith," not "Bob Smith." If there are 3 founders, there should be 3 tokens in this answer.)

zt dkimerling

YC usernames of all founders, including you, zt, who will live in the Bay Area June through August if we fund you. (Again, that's usernames, not given names.)

zt dkimerling

What is your company going to make?

We are building APIs for commercial banking services by building on top of multiple large banks.

If someone needs advice they can call Goldman. If they just need to transact then they can use one of our APIs. We will build commercial banking middleware that will sit on top of banks just like Twilio sits on top of multiple phone carriers. It is much easier because we'll have (mostly) RESTful APIs with good documentation, etc, and (if we choose) cheaper because of bulks rates.

1) Delivered programmatically, using good APIs - Anything transactional shouldn't involved a human being. Most banks suck at technology and admit that. They're excited to have us resell their services.

2) Narrow to start, but ultimately broad services - We want to abstract away the pain of dealing with banks for transactional services like ACH, F/X, wires, factoring, short-term loans, etc, just as Stripe, Braintree, and others have done for getting a Merchant ID. We are starting with ACH and F/X as foundational products.

3) Multiple banking partners - We're willing to endure the pain of setting up commercial contracts with many banks and then offering the transactional services (via API) in an intelligently routed way. We've gotten verbal agreement from Wells Fargo, and are pretty far along with JPMorgan and Capital One. Will start with other banks shortly.

For each founder, please list: YC username; name; age; year of graduation, school, degree and subject for each degree; email address; personal url, github url, facebook id, twitter id; employer and title (if any) at last job before this startup. Put unfinished degrees in parens. List the main contact first. Separate founders with blank lines. Put an asterisk before the name of anyone not able to move to the Bay Area.

zt Zachary Townsend 27 2009, Brown, AB, Applied Math, Economics ztownsend@gmail.com zactownsend.com http://www.facebook.com/zactownsend @ztownsend I work at Stripe, mostly on Risk

dkimerling Daniel Kimerling 27 2008, UChicago, AB Political Science, AM International Relations, (Also half-way through UChicago Booth MBA) http://www.facebook.com/dkimerling @dkimerling COO, http://www.giftly.com/

Please tell us in one or two sentences about the most impressive thing other than this startup that each founder has built or achieved.

ZT reorganized child welfare investigations in New York City. He got tons and tons of data, wrote R code to analyze it, set up ethnographic research conducted by his team, etc. He sniffed out details, wrote a report, and then helped implement the changes to a staff of 2000, and a budget in the tens of millions.

Dan built Giftly, particular the proprietary stored value product, from a regulatory, legal, risk, etc, perspective.

Please tell us about the time you, zt, most successfully hacked some (non-computer) system to your advantage.

When I started in Newark, I didn't have a computer or an email, and City Hall didn't have wireless. So I tracked down one of the wireless networks I could find - owned by a bails bondsman close to the court, and negotiated with them for their wireless password.

I once spent hours looking at floorplans and historic housing lottery data so that my roommate and I could pick a HUGE double with our own bathroom despite having a terrible pick at Brown.

Please tell us about an interesting project, preferably outside of class or work, that two or more of you created together. Include urls if possible.

http://deciens.com/ We raised the money, we have made investments. We have been to YC demo days and invested in Keychain Logistics.

How long have the founders known one another and how did you meet? Have any of the founders not met in person?

We've known each other since we were 16, when met at Harvard summer school.

Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?

We started by thinking about ACH, which is a problem that Dan actually had in his work. Zac sees how hard it is for even Stripe to deal with Wells Fargo on F/X, wires, etc.

Dan knows a ton about payments. Zac won finance prizes @ Brown. We both want to disrupt banking and have been talking about it for years.

What's new about what you're making? What substitutes do people resort to because it doesn't exist yet (or they don't know about it)?

When most businesses wants to do something financial they have to call their bank and talk to a person - except for getting a MID. That doesn't make sense. Getting a wire, as an example, often involves twenty minutes, a painful conversation, and $30. Even non-quant hedge funds needing to convert EURO to GBP have to pick up the phone and talk to a bank's trading desk.

No one has built developer friendly bank back-end processing, so you have to deal with banks, which overcharge, are slow, and are not developer friendly. Wells Fargo, for example, does offers an API which costs more than their other options and, well, is not very good.

Who are your competitors, and who might become competitors? Who do you fear most?

Possible competitors: Square, Stripe, Braintree, Wells Fargo, JP Morgan, Bloomberg, Intuit, PayPal

Banks cannot innovate on technology. A senior exec at JPMC told us that even if building good APIs was a Jamie Dimon priority it couldn't get done before 2017.

Commercial banking broadly - including every service we're imagining other than ACH (F/X, Wires, Factoring, Lending, Account Creation/Deletion, etc) - is not something that the innovative payments companies plan to provide to others, although they're all services they, themselves, need. Stripe, for example, is trying to make payments work on the web. We're trying to make commercial banking work in the world. They're both trillion dollar problems, but they're different.

So, who do I fear most? I fear regulators the most. Banks can't beat us on technology but we might be so successful they beat us with the law.

What do you understand about your business that other companies in it just don't get? People who run banks don't care about providing high quality technology services, and the people who care about technology don't want to work with (or buy) a bank. Schlep blindness, as it were.

Also, there is great power in abstracting away thinking about your particular bank. Take ACH: since we are willing to suffer through forming eight banking relationships, we can provide next-day payouts to 80% of checking accounts in the US. Everyone else can only do next-day payouts on their one bank.

How do or will you make money? How much could you make? (We realize you can't know precisely, but give your best estimate.)

We make money on transactions.

For a (very, very) rough guide, profits at ten biggest banks last year were $120b. Let's call 50% of that transactional/FICC/pure commercial banking as we define it.

As for TAM, SAM, SOM, using big-O:

Total addressable market: O(100s of billions)

Serviceable available market through APIs: O(10s of billions)

Share of market: O(10s of billions)

If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?

Pre-development. We've incorporated. I'm still at Stripe. Dan's still at Giftly. It didn't make sense to start until one of the banks signalled a willingness to sign a commercial agreement as their was nothing to integrate with. Ready to start now. Raising money because of non-trivial commercial and regulatory costs. Far along with recruiting the rest of the early team and considering raising a seed round.

How far along are you? Do you have a beta yet? If not, when will you? Are you launched? If so, how many users do you have? Do you have revenue? If so, how much? If you're launched, what is your monthly growth rate (in users or revenue or both)?

We're far along on regulatory/commercial contract/legal stuff. Once we have that settled, there is a lot of backend, unsexy stuff to do to make it as pretty/smooth as we'd like: settlement files over SFTP, testing required by the banking partner, automatic underwriting built on Microbilt/LexusNexus/Iovation, etc, and then launch.

If you have an online demo, what's the url? (Please don't password protect it; just use an obscure url.)

No online demo yet. It might be awhile before we have a dashboard and mocking up a fake API for you doesn't seem worth it.

How will you get users? If your idea is the type that faces a chicken-and-egg problem in the sense that it won't be attractive to users till it has a lot of users (e.g. a marketplace, a dating site, an ad network), how will you overcome that?

Working the network, undercutting others on price and (especially) ease, directly reaching out to every startup that needs banking services beyond payments that exists or is founded for traction.

We've focused our user research on three customer segments: (a) Corporate treasury departments (a heretofore undisrupted part of most enterprises) (b) hedge, private equity, and venture funds (minus quants/HF) and their back offices (c) technically inclined SMEs and startups who aren't served well by big banks.

If you're already incorporated, when were you? Who are the shareholders and what percent does each own? If you've had funding, how much, at what valuation(s)?

[Redacted]

If you're not incorporated yet, please list the percent of the company you plan to give each founder, and anyone else you plan to give stock to. (This question is as much for you as us.)

If we fund you, which of the founders will commit to working exclusively (no school, no other jobs) on this project for the next year?

zt dkimerling (we've envisioning this being a, uh, five-ten year project at least)

For founders who can't, why not? What level of commitment are they willing to make?

-

Do any founders have other commitments between June and August 2014 inclusive?

No.

Do any founders have commitments in the future (e.g. finishing college, going to grad school), and if so what?

No.

Where do you live now, and where would the company be based after YC?

SF. SF.

Are any of the founders covered by noncompetes or intellectual property agreements that overlap with your project? Will any be working as employees or consultants for anyone else?

We both have CIIAA's that could cover this work.

Dan's company is pretty far away.

Zac declared this idea when he signed his at Stripe. He's asked Stripe for an IP waiver letter, or whatever it's called.

(I also described this entire idea in a youtube video I sent to you in December before we didn't accept a late interview, so...there is a lot of documentary evidence that I had this IP before Stripe).

Was any of your code written by someone who is not one of your founders? If so, how can you safely use it? (Open source is ok of course.)

No.

If you had any other ideas you considered applying with, please list them. One may be something we've been waiting for. Often when we fund people it's to do something they list here and not in the main application.

Please tell us something surprising or amusing that one of you has discovered. (The answer need not be related to your project.)

"The failure, if it was one, lay in the fact that, having too much to hold on to, they slowly lost what they had. On the whole, it was those who had least who were able to move most freely to the new world which was coming into existence." --That reading The Making of the Middle Ages can make you think of everything from startups to the state of America in the world (this happened in December)

(This is the second of three posts I'm doing this week about applying to YC. Tuesday I wrote about our crazy story of getting in to YC and tomorrow I'll post our application. Early next week — after the application deadline — I'll tell the story of our YC experience from bringing on our amazing third co- founder up to demo day).

I have had a few friends of mine ask me whether they should apply to YC and what advice I can give on the application itself. This is in addition to the 5 people Dan has met with this week about applying to YC.

Let me caveat my thoughts. Getting in to YC is similar to getting in to college. You're never quite sure how (or why) it happened. They don't send you a memo telling you their criteria and most of what you learn about the process is already public.[1]

Should you apply to YC?

I get questions about whether it's worth the equity. Short answer—yes.

YC gives you incredible focus and discipline. You have 100 days until demo day so get moving.

YC is a community. Your class is supportive, helpful, and in the trenches with you. They will always lend an ear or a hand.

YC is a guild. The alumni are incredibly generous with their time. We've gotten specific product feedback, investment, advice, and introductions from the extended YC family.

YC is a guide. The YC partners are successful and helpful. They will kick your ass in every conversation you have with them, improving your business and your thinking.

YC is a mafia (cough) I mean, a union. If someone treats you poorly then PG will treat them poorly.

Do you have advice on my application?

Be yourself.

Be concise.

Be demonstrably committed.

Don't lie. Don't bullshit. Don't exaggerate. Avoid adjectives and pronouncements.

Prove that you and your co-founder likely won't get divorced. This is how most companies die early.

Not-for-profits

Having worked in the social and civic sectors, a ton of my non-profit friends have asked me about applying to YC. I have no special advice to them except that they have to have some plausible story of how the NFP will grow. Startups are growth. YC funds startups.

I'd also suggest reading Glen's thoughts.

[1] This is basically true of all the advice from and operations of YC on some level. Almost all of the knowledge — although very little of the pressure and urgency — are in PG's many essays.

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.