Zac Townsend

Last week Sam Altman wrote about Founder Depression. Catherine Shu followed on, among others, with a candid telling on TechCrunch of her struggles with depression. I applaud them both.

Many startup founders I know aren't depressed though. They are anxious.They are on the spectrum of anxiety disorders. Real existential concern about whether they'll make it. Whether they're doing the right thing. Whether they'll raise money. Actually that last one isn't anxiety: strictly speaking anxiety is generalized and unfocused fear. A lot of people who are running startups fit that bill though, they have terrible unspecified fear (of failure). You can get pretty far down the anxiety spectrum and just seem like a founder who cares. That is dangerous.

Highlighting depression is useful but also limiting. It can demarcate people who have had certain problems without highlighting others. I believe our community — Silicon Valley, Y Combinator, startup founders, or all ultra-high-functioning professionals — should be having a conversation about mental health more generally, about the sources (sometimes quite dark) of our motivations, about pathologies, about depression, about anxiety, and about other problems. Or, at least, be more comfortable having those conversations privately.

I know founders who are on the depressive spectrum too, which can range from the blues to deep clinical depression. I have a history of depression myself. I have not had a serious depressive episode since I took a year off from college and invested in intensive therapy, but most people don't have that luxury — or they are not comfortable taking that much time given how taboo mental health can be. I remember when I was in the depths of my depression spending eighteen hours in bed with a dreadful sense of melancholy. That's a serious case — I couldn't have run a startup when I was depressed — but depression hits people in different degrees. Someone who seems fine often isn't.

Depression and anxiety are just two examples of the challenging mental health that startup founders can have. Anxiety and depression are often described as opposites, which is too simple a story, and they need not be opposites in our mind. Either can be dangerous and destructive. We need to talk about both. The names of anxiety and depression can sometimes just obfuscate things more: We need to talk about much more too. I know a few (medicated or not) bi-polar founders. I know a few diagnosed with OCD.

No matter the diagnosis or the name, founders can feel isolated by their mental state. They can feel alone, which can make them more depressed, more anxious, more obsessed or whatever. But whatever your particular problem is, I promise you, other people have it. People in the community have gone through it. Many people have gone through it, in fact.

Over the last year I have also found that many startup founders had some deep personal trauma in their early lives. Glen Moriarty, the founder of 7 Cups of Tea, and I have discussed this idea at length and it has come up with many folks both inside and outside the YC community: startup founders insatiable motivation often comes from trauma.

We are all unique but most of our problems are not. Startup founders are so often a community that helps one another with introductions or advice. I hope that in time we can all be as comfortable talking about our mental health. That we could be as comfortable giving advice about our depression or our anxiety as we are about fund raising.

I might write a lot more about this soon. I don't know. Some of my friends, colleagues, and investors have cautioned me against being too public about my own history and my own traumas, but any founder should feel they can contact me, if no one else, whether they're depressed or anxious or something else (or use 7 Cups of Tea).

Banks have a nearly one-size-fits-all product model which leaves value on the table. For instance, when a bank releases a new online or mobile banking system, it will often be an identical system, with the exact same interface, for all clients of a particular segment. But oil companies like Chevron have different banking needs than do retail companies like Home Depot, even though they may be the same size. This type of mass standardization and lowest-common-denominator mentality applies even more to the retail customers — usually there are just two online and mobile banking options: one for normal customers and one for private wealth clients.

Technology that is new to banking is ushering in an era where mass customization is feasible, safe, and profitable.

Banks of all sizes have spent the last half-decade cleaning themselves up in the wake of the financial crisis. They have been implementing new requirements from the European Banking Authority, the United States Consumer Financial Protection Bureau, and other regulators, as well as adapting to Basel III and other new capital requirements. Many have built new risk management and compliance frameworks in response to sector-wide malfeasance.

Now, though, banks are refocusing themselves on growing top-line revenue. Many banks have organized new teams focused on revenue growth through “the innovation agenda” and “customer experience”. Technology is understood to be a potential driver of the sought-after revenue growth. One such technology will be “API banking” – a concept that, though it seems to have achieved buzz-phrase status, represents a new and revolutionary way of thinking about bank services and how to deliver them to customers.

API refers to the Application Programming Interface: the standards and protocols which allow outside software developers to build applications on everything from Apple’s iOS platform to Facebook’s social graph. This technology and the attitude of open development that goes along with it are now second-nature at Silicon Valley’s leading companies. Apple, Facebook, Amazon, and others capture the imagination and skill of tens of thousands of software developers through an open platform and simple profit-sharing.

With their new compliance and risk management systems, banks are now positioned to open themselves up just as technology companies have. They can build similar platforms for innovation and customer-facing customization. These financial innovations will not be used to obscure risk (as most innovations of recent years have done) but rather to improve how customers, both commercial and retail, experience banking.

We are entering an era of technologically customized banking. Trusted risk-and-regulation-sensitive financial institutions will provide the core financial services via APIs. Then they will leave many of the last-mile implementation details to trusted partners and software developers. Millennial bank customers could have their customized mobile banking with special tools focused on paying down their student debt, while Boomer customers would have an entirely different online banking suite, which could be focused on either building up or spending down their retirement, depending on individual circumstances.

Developers, and the technology that they bring, can make the unprofitable profitable for the platform provider. Just as it might not be profitable for Apple to build and then acquire customers for a variety of bird-focused games — Angry Birds, Flappy Bird, Tiny Wings, et al. — it is also not profitable for banks to build the skill sets necessary to acquire and optimally serve every potential customer. With API banking, specialized third-party developers can profitably provide services that banks couldn’t afford to build, by giving both banks and the new developer companies access to swathes of the banking market, including the underbanked.

As in the Apple App Store, bank clients will be able to find and experience banking in the manner that makes the most sense for them, in a co-branded and protected environment. Customer satisfaction increases with a more personalized user experience, and revenue increases as banks are able to target and display their offerings more precisely.

Crédit Agricole and Deutsche Bank are the only major banks with APIs and app stores in the market right now. But APIs are one of the best and most talked-about ways to increase top-line revenue in the face of decreasing fee and interest income. Many banks are working toward releasing their own this year.

Amid this renewed focus on innovation and customer experience, using APIs and the mass customization they foster is just the first of many lessons that banks will learn from technology companies in the coming years.

Republished from BankInnovation.Net.

“The skill of making and maintaining Commonwealths consisteth in certain rules, as doth arithmetic and geometry; not, as tennis play, on practice only: which rules neither poor men have the leisure, nor men that have had the leisure have hitherto had the curiosity or the method, to find out.” ― Thomas Hobbes, Leviathan

Jack Gavigan wrote a blog post yesterday titled "What would a disruptive bank look like?" Read it. It is well worth the time.

I basically have the same blog post written. I actually also have the same blog post written as a detailed fifteen-page business plan ready to pitch Marc Andreessen. I outline the technology needed in a bank, the product offerings and their rollout, the legal structure I'd use, the capital structure, relevant bank regulations. Ah and therein lies the rub.

Regulation. I know I am supposed to be a big, bad startup entrepreneur who spurns restrictions of all kind. Particularly those restrictions put on me by the government. But that's just hard to do in this case since you need a license to operate.

Banks don't often fail. They don't often fail because there are real limitations on who can buy a bank and how one can run a bank in the US. Those two ideas – hard-pressed to fail and deeply restrictive operations – are two sides of the same coin.

So, how does that manifest directly for the bank-running entrepreneur?

1. Maddening capital and other ownership restrictions;
2. Deep restrictions on personnel and hiring;
3. Writing a initial seven year business plan and sticking with it for seven years; and,
4. Deep restrictions in the operations of a bank.

The key problem of restrictive category number (4), and why I walked away from spending so much time on building a bank, is that regulators artificially restrict a bank’s growth rate. The number one historical indicator of a shady bank is rapid, radical growth. Very good lawyers, regulatory advisors, and current regulators at the FDIC, Fed, and the FFIEC have all told me that any new bank would be restricted from growing more than 25% a year. Is that enshrined in law? No. However, latitude and discretion is.

25% a year. A good startup grows 25% a month for years.

I think you're left with four choices then:

1. Figure out how to bring technology into the banking sector in a high-margin, fast-growing way (that's Standard Treasury);
2. Build a bank and hold it for a long-time or buy an already big bank (despite all I've said, several investors have approached us about this);
3. Build a bank someplace in the developing world that has less restrictive laws and then port it back to the US later (ready to talk when you are Marc); and,
4. Avoid banking, per se, altogether. Build out different parts of banking like lending (Lending Club, SoFi, Capital Access Network, On Deck) and payments processing (Stripe, bitcon startup du jour).

Last year, I shared our story of applying, our application, and some advice on the YC application. Now that the Winter batch is in full swing and the application is open for the summer, I thought I would share our story of going through YC and nine lessons I learned in the process.

I have had a lot of trouble writing a post about going through YC. It was one of the best and most productive experiences in my life; it was also one of the most difficult and stressful experiences in my life. As I have attempted to write, I've faced some difficulty in avoiding both what could be a boring recitation of facts that are widely known and a sensationalized portrayal of the experience.

YC left me more scared and yet with more optimism and excitement than any other three-month period I have lived through. YC is hard. You're stressed out. You're underslept. You think your company is on the verge of collapse (and the companies of some of the people around you are). The partners' advice is brutal — brutally honest and unvarnished in its delivery. YC is relentless. Difficult. Stressful. Thrilling. Unforgettable. Worthwhile.

The best metaphor for YC is a slow-cooker. Every week YC cooks a meal for fifty companies (now seventy) in a bunch of slow-cookers. That's all it takes: time, heat, and a pressing deadline for delivery. Sometimes you throw all the ingredients in and get a good dinner or a good company. Sometimes it's crap. No one seems quite sure beforehand which it is going to be.

If I ever found another company I would do YC again. Well, if they’d have me.

Lesson 1: Do YC if you can. It's worth it, but it isn't easy. (I promise the other lessons are more surprising!)

But let’s go back to the start.

If you get into YC, they call you the same night as the interview. The phone call is brief: do you want to accept the offer to join YC, and can you do an introductory talk on Wednesday in Mountain View? We said, "Yes".

Orientation

The orientation involved two parts: one where Paul Graham (PG) talks and one where Kirsty talks. This may change now that Sam Altman (Sama) is YC's president, but the gist will likely be the same.

PG condenses the most important lessons of YC into about two hours. It's a dizzying talk, even though most of what he says are in his essays. The most important piece of advice is to "start now". The day you get into YC you can start going to office hours, and you're told when Demo Day is. In effect, YC is on, even if the dinners don't start for a few weeks. Get working. There are a fixed number of days between acceptance day and Demo Day. Anything you do before Demo Day you can use to impress investors on Demo Day. Anything you do after Demo Day still matters to investors, but it likely won't matter until much later.

Kirsty Nathoo spends the second half of the day describing the basics of corporate setup. She goes over all of the associated paperwork, the YC investment, the YCVC notes, and advice on what to spend money on. It was a fast, expert primer on corporate law, corporate finance, startup financing, benefits, payroll, and more.

Part of being a startup founder is learning tons of stuff which you might not be comfortable starting with. That's what's great and what's challenging. One thing we learned early on is to embrace all the learning: being a startup founder is about constantly doing new things outside your comfort zone.

Lesson 2: Be comfortable doing anything. Learning anything. Working on anything. Most parts of founding a startup are unglamorous. Like talking to your lawyer about how to get the best strike price on your options for your employees. Or making sure that payroll taxes get paid. But that's what a great company is: a thousand carefully, but quickly, made decisions.

Moving to Mountain View

YC recommends that you live close to YC for the duration of the batch. They say that this is because they’ve found a high correlation between startups that attend YC events and those that succeed.

It’s also the case that there is a lot less to do in the Valley than in San Francisco if you’re young and childless. You will work more. Part of PG’s advice is to do little other than code, talk to users, sleep, eat, and exercise. That advice is much simpler to follow when you’re living in Mountain View; there is only so much you can do on Castro Street.

Lesson 3: Avoid distractions when starting a new company. Find a way to build and do little else. Go to the wilderness — by which I mean Mountain View — if you have to.

Dan and I lived with Kai and Claire from True Link Financial in a small house that has passed from YC company to YC company for a few years. Claire and Kai have become some of our closest friends, more broadly. They’re both amazing people, dear friends, and quite well-rounded in their interests. They also became reviewers and supporters of our work, with a much deeper understanding of working in fintech than most of our other friends.

Living with another team with whom we grew so close was critical for us. Otherwise, I think we would have torn ourselves apart. I'm not sure it’s necessary for everyone, but for two guys from New Jersey anything else would have led to a steel-cage death match.

Dan and I spent a huge amount of time together over the summer, but one rule we had is that we spent Saturday apart. We needed that time.

Lesson 4: Don't give up all human contact — just most. Do what it takes not to murder your co-founders in their sleep.

Idea iterating

We spent most of the first few weeks trying to figure out what we were going to build. Whether this is what YC meant by "start now" could be up for debate.

We were trying to figure out — in the abstract — what our business model would be. We spent most of this time just talking to businesses about what they found annoying in dealing with their banks.

In order to think through this, Dan and I walked around the same block in Mountain View several hundred times.

Over the approximately six weeks between orientation day and Prototype Day, we iterated through six ideas in sequence while talking to nearly a hundred potential customers: APIs for commercial banking (what we applied with), WealthFront for businesses, near real-time cross-bank settlement, financial reconciliation support, building a bank from scratch, and API gateway for commercial banking sold to banks. Given his experience and passion, Brent was most interested in the platform ideas.

The details of those business ideas, except the last, aren't so important to the story, but the process was helpful. We were not building anything — which I don't recommend — but we were making use of lots of potential customers to figure out what they would pay for and what their pain points were in the interface between their businesses and their banks.

Almost everyone we spoke with said: (1) we don’t like our bank, (2) we want a technology-forward bank, and (3) we want working with our bank to be as simple as working with new payments companies like Stripe, WePay, Balanced Payments, etc.

And then we just got lucky.

Our product

Starting in October 2012, about six months before we incorporated and eight months before we started YC, Dan and I had been talking to banks about an API for ACH. Our plan was to connect a bunch of banks and then have a cross-bank same-day settlement system. We were talking to J.P. Morgan, Capital One, Wells Fargo, Silicon Valley Bank, City National Bank, Citi, et al.

Then, while we were endlessly flailing around in circles in Mountain View, several of those banks came back to us and said that they wanted an API gateway. Would we sell the experience we were describing to them as a white-labeled or co-branded experience?

We were in the bank software business. Our first product was an API platform-as-a-service for commercial banking.

Lesson 5: Always be willing to iterate and always, always, listen to someone willing to pay you for your product. Paying customers are hard to find and they're often right.

Prototype Day

Prototype Day is one of the best days of YC. It's like a mini Demo Day. The order of the companies is randomly chosen and every company has a few minutes to present. It’s early on and you still don’t know most of your batchmates all that well. Prototype Day lets you learn about what everyone is doing and a little bit about every person in your batch.

The partners tell you not to prepare. However, we found preparation to be focusing, and we chose to put together a presentation. We used that as an exercise to figure out how we would pitch our idea and company to a large group of people.

After each presentation, PG tells the company's founders some of the things they did wrong. It's useful, although it's best not to be randomly chosen to go first or second. It's your first introduction to how investors might react to your pitch.

Prototype Day ends in a vote. Every founder gets to vote for two companies, then the vote is tallied, and the top ten companies are announced. I can't find any of the published results of any past Prototype Day, so I don't want to give any results, but we did fine.

Dinners

YC hosts a dinner with a prominent startup founder (or Ron Conway) every Tuesday evening. The talks are interesting — more inspiring than informative. A frequent theme is how to not get screwed by your venture capitalists. YC dinners are off-the-record, so I won't share any of the details of the talks we experienced, but they're enjoyable.

The most significant value of the Tuesday dinners is that it's the one time each week when YC turns into a co-working space. Companies arrive hours before dinner. You have many of your office hours for the week, you chat with Kirsty or the Levys (YC's two lawyers) about a random question you have, you catch up with everyone in the batch, and you get as much user feedback as you can get in the hours before dinner starts.

Lesson 6: Set deadlines for yourself. Always have something to fight towards, even if it's not concrete. Measure your progress even if the measurements are artificial.

The dinners are weekly milestones. Most people work their butts off all week culminating in Tuesday. Report back. Rinse. Repeat.

The Batch

One of the most important aspects of YC is that they fund companies in batches. And not just so YC can have dinners with good speakers. Batchmates make fast friends who stick with you long after YC is over. Dan, Brent, and I each invested in several companies in the batch!

You go through an adventure together. Batchmates are always willing to offer help with a product question or support you when you're down (and there will be times when you're down). It's hard to come out of Tuesday dinners without feeling energized because you've gotten that emotional lift (and competitive spirit) from your batchmates.

Office Hours

There are now seven different types of office hours. The regular and group hours are the only ones that happen frequently, so I'll describe them.

In regular office hours you meet with a partner for ten to twenty minutes. You talk about the progress you have made in the last week or so, discuss the particular problems you're facing, and ask any questions you have. In our batch, each company selected a partner or two as its primary partner(s), but now I think they assign one of the full-time partners to each company. We chose Geoff Ralston, who was perfect for our personalities: direct, to the point, and no-BS.

Group office hours happen every two weeks. Our group partners were Paul Buchheit, Kevin Hale, and Kirsty. Group office hours are like regular office hours, except they're public and shared. Each startup takes a turn giving an update and interacting with the partners. This is useful because it allows you to see the problems that others are facing (and also how they solved them!).

Selling Software to Banks: Slow Weekly Progress

Selling big, complex software to big, conservative institutions is hard. It is slow. During our YC batch we almost always thought we were just a couple of weeks away from having a deal: next week we will sign a deal with bank X, we said. We said that every week. We told investors that. We told YC partners that. We told friends that. We believed it. We were wrong.

Now that we have signed proof-of-concept deals that we are only now negotiating into definitive agreements, I can say with confidence that we were naive. We didn't know how enterprise sales worked. Experience has educated us. Harsh experience.

However, I think this made us look bad to YC. In retrospect, we were like boys who cried wolf. PG has said that the best way to tell which startups are going to make it is to look at their weekly progress. We did a lot every week: tons of meetings with banks, product and security reviews, etc. — but I am not sure any of it looked like progress.

Lesson 7: Every YC company (every company!) is a shitshow in one way or another, even if you often think it's just you. There's power in realizing that that's OK. It took many of our batchmates too long.

In December, I voiced my concerns about crying wolf to PG in an email when he asked about our progress (I think he emailed the entire batch). He said:

Don't worry too much. Deals of this sort are always slow.

If I were in your shoes, I'd focus on sales of whatever type I could get. As soon as you reach breakeven, everything changes. Slow customers are no longer fatal once you're profitable; they can decrease your growth rate, but they can't kill you, and if the market is big you'll eventually get big.

Deals of this type are slow. All enterprise sales are slow. YC was amazing, and I tell all my friends to apply, but it is also difficult for companies like ours - companies where a small number of large deals define them. Those types of companies may be on the path to success, but they aren't like consumer companies that can show that desired week-over-week growth.

It is an expectations-versus-reality disconnect. What is possible for other companies was never possible for ours. Yet YC holds up a mold for all companies to fit into. As YC grows and includes more enterprise companies, I'm curious to see how they manage that challenge.

Fundraising Too Early Before Demo Day

YC tells you to avoid doing it in the first two months. We did it too early. It was a mistake. In fact, we screwed up our entire fundraising process. Three friends told us that normally people who mess it up so badly can't recover; we somehow still raised a healthy seed round. I'd say we fucked the whole thing up, except we did end up with millions of dollars. If I ever find the time, I'll write another post on what not to do, but YC is right: don't raise money until you're ready.

I think that the ideal time is likely about two weeks before Demo Day; at that point you may or may not feel ready, but you're going to have to be so it's time to start acting like you are. People ask on Demo Day how much money you've raised, and the answer shouldn't be zero. But if the answer is that you closed the round (or that you got too many "No"s, too early), then that might be just as bad.

Lesson 8: Take advice. Sometimes your friends and advisors are right even if you think they must be wrong. Don't go with the crowd but try to do the right thing for your company at the right time. We didn't have the confidence to refuse introductions and meetings with big VCs until we were ready.

Rehearsal Day

Roughly a week before Demo Day you have a Rehearsal Day where every company goes through their initial pitch. Every company presents, there is a vote at the end, and you get in-stream advice. In fact, this time PG will just interrupt you with advice. This is the beginning of a week long sprint that culminates with Demo Day.

You have to practice this presentation so much that, despite its being scripted to the word, down to the second even, you sound perfectly natural. This proved not to be a strong point of mine. I can give good, if not great, off-the-cuff presentations — in fact, I relieved my stress by giving everyone else's presentations (sometimes in a joking tone) and helping batchmates come up with new phrasing, new ideas, new ordering, etc. But getting down the exact wording that I agreed to with PG? That took me all week.

Demo Day

The night before Demo Day is Alumni Demo Day in the same venue; I did not do well. I felt like I spent every single waking moment between that and our presentation on Demo Day practicing. I walked to the Computer History Museum from our Mountain View house giving the presentation to myself over and over and over again.

I think the first time I gave the presentation perfectly on stage was on Demo Day itself. It was a good time to peak.

When not presenting at Demo Day, you are surrounded by investors. It's ten solid hours of answering questions, discussing valuation, and trying to close some deals.

It was exhausting. It was exhilarating. But that's YC for ya.

Lesson 9: Enjoy yourself. Building a company is exhilarating, even if it's exhausting. You are building something through grit and persistence, so it's best to have some fun while you're doing it.

Thank you

Thank you to those who helped edit and advise me on this post — my co-founders, Brent Goldman and Dan Kimerling; my batchmates Aaron Feuer, John Gedmark, Glen (Professor) Moriarty, Claire McDonnell, Jake Heller, Nathan Wenzel, Patrik Outericky, and Maran Nelson; and the best-damn-proofreading-friend there is, Kate Brockwehl. I am always in debt for her countless suggestions of great value: and for all the present semicolons.

It is hard to hire people. It is very hard to hire great people. Our core team is amazing. I hope that by telling the stories of how we hired our team, haphazard as they are, others might get a sense of how to put together a good team.

Yesterday I told the story of how Standard Treasury's founders knew each other and today I am telling the story of hiring our first three employees. With that story I share five lessons learned about hiring: get your message straight, start now, do whatever it takes, be aggressive, and create a process.

I have talked to a number of YC founders that are at much later stages than us. They admitted they had a terrible time hiring at the beginning. They just didn't have access to top-tier talent. They didn't necessarily know at the time what top-tier talent was. Some didn't go to fancy schools and didn't have great networks. Some did YC when it wasn't what it is perceived to be now.

Once money is no longer your biggest problem, hiring is. They succeeded through grit, persistence, and a healthy willingness to fire people when they needed to.

We made offers to our first two hires before we quite finalized bringing Brent on as our third co-founder. As two only quasi-technical co-founders Dan and I have just gotten lucky at their quality and we have learned some lessons along the way.

I have a good sense of whether someone is an asshole or not, whether they can break out and plan tasks well, whether they get or are interested in our business, or whether they're completely full of shit technically. But, whether they can abstract classes well, can deliver high-quality software, can keep to our bank-imposed deadlines without sacrificing too much, or can write good test coverage...well, I'm flying blind other than that I know enough to ask the questions and see if my full-of-shit-meter goes off.

One thing we did have though was a great message. We have a big idea that scared most people away, and a network big enough to run references on almost everyone that came our way.

Lesson 1: Get your message straight. Think about how to message your company as much to candidates as you do to customers. We realized that Standard Treasury is potentially a big business but all the challenges were in relatively boring, if complex, topics like building against legacy interfaces and presenting unified APIs despite those crazy backends. We embraced the boringness and made it a strength: you can work on a big serious problem or with the others guys. To us, having a boring idea made it so the excited candidates were genuinely excited.

As one of my co-founder says, I know enough to be dangerous in all things, but it's clear to me that if you ran the simulation a thousand times, we likely wouldn't have gotten the outcome we did very often. We hired three great engineers to our core team without doing any technical screens.

The Infrastructor

One of those two initial offers was to Mike Clarke. Mike was in charge of infrastructure at Disqus, where he helped to serve more than a billion 'uniques' a month.

Mike and Dan knew each other from their days in Chicago (having been introduced by the great John Fox), but stayed in touch when they both moved to San Francisco. They ran into each other a lot, on the line for Senor Sisig (a food truck that's often on 2nd and Minna), and Dan would always say "When I found my company, I'm going to hire you!" Mike thought Dan was crazy. Dan had no idea just how good Mike was.

I looked through my emails and found that we started the conversation by Dan emailing Mike the TechCrunch launch article with the subject line: "Leaving disquess and joining Standard Treasury." Correct spelling wasn't critical to Mike.

A few long conversations later, Mike joined the team. Mike has ended up being the perfect early-stage engineer: a great coder, dedicated, thoughtful, fast, willing to take on anything, and with a skill set that has been critical to launching within banks.

Lesson 2: Start now. Always be recruiting. In the case of Mike this meant even before we started the company. You know who your best engineering buddies are. You know who you can work with every day all day. Start recruiting them even before you start your company. Maybe even years before. Recruiting takes time.

The Bank Integrator

Keith Ballinger proved easier to find, but, we were even less thoughtful about whether he had the right technical chops. We fell into him being a killer engineer. Keith worked for many years at Microsoft, including as an original core contributor to C# and .NET (although no one hates what it's become more than Keith) and then worked at a series of startups. He's our go-to expert on crazy enterprise software. He and I often handle all our bank integration meetings together.

Keith applied through Hacker News' jobs page along with a couple hundred other people last summer. Dan and I both met him once or twice. He seemed competent and didn't set off any of our red flags. We did a few reference checks that came back positive, but never did a technical interview. Then we offered him a job. I don't suggest that as a model for hiring employees.

Lesson 3: Do whatever it takes to find great candidates. Posting on job boards creates a lot of resumes and a lot of work. It isn't efficient but finding a needle in the haystack is worth it. Great engineers multiply your productivity and value exponentially, so spend time doing whatever it takes to find great people.

The Platformer

Last, but not least, Jim Brusstar rounded out our core team. Jim's the only one we hired who we knew was good — Brent had worked with Jim for years at Facebook. After Jim left Facebook to work as an engineering lead at Sidecar with his college buddies, he and Brent kept in touch. And when Brent told Jim he was founding a company, Jim was eager to learn more about the idea and meet the team. Jim joined thereafter.

Jim is the core author of our API infrastructure and is every bit as fanatical about code quality as Brent. Which makes sense, since he's the first person we hired based on knowing whether he was good or not — and he's been great. He keeps us all focused on the question of what will developers — and not necessarily our paying bank partners — want in the API. He's critically focused on building an excellent product experience and rounds out our core team perfectly.

Lesson 4: Be aggressive. Reach out to everyone you would love to work with. No matter how senior or junior. No matter how comfortable they may seems. You never know. Think through everyone you've ever worked and would like to again. Reach out to them as soon as you start your company. Some great candidates will jump, like Jim, others will take time but either way you're letting people know you're looking and you're setting people up to think of you when they do want to jump.

Hiring Moving Forward

Now, hiring is much more of a process. We've iterated through a ton of different technical questions and screens. With almost every candidate, we use the same process: a 15-minute intro phone call, followed by a 45-60 minute coding screen (usually on a call with a virtual whiteboard, but sometimes in person), then a 4-hour coding challenge / homework assignment, concluding with a 4-hour on-site interviews. The top of our funnel had hundreds and hundreds of resumes, we've done dozens of coding screen, we've had seven or eight full on-site loops, and we've made two offers.

Lesson 5: Create a process. Even at a small startup, process is important. We are inundated with applications that need to be sifted through and lunches with old friends. The only way one can manage it and feel like one is being fair and polite to every candidate is to create a process. A process allows you to move quickly, give people feedback, and seem like you have it together.

We've also been able to articulate, make known, and get a lot of feedback, on our values, which seem appealing to the types of candidates we find attractive:

• Excellence. We are building a team of great women and men who work hard, have a passion for perfection, and don’t tolerate bullshit.
• Candor. We practice internal transparency, and are candid about our finances, business development, and planning processes.
• Quality. We build bank software - our motto is more “slow and steady wins the race” than “move fast and break things”. Our critical technical values are security, reliability, consistency, maintainability, and craftsmanship. We emphasize tremendous attention to detail and build software that lasts.
• Collaboration. We use Phabricator and support each other with code reviews. We have a healthy culture of debate without argumentation.
• Entrepreneurship. We encourage people to set their own direction. We are looking for senior engineers who can lead product decisions. All engineers are able to suggest, research, and lead architectural changes, contribute to, and suggest, revisions to our road map, and create new coding guidelines and have them enforced.

If those sound interesting to you, or if you're just interested in joining a place that (by sheer dumb luck) has a great core team, then check out our jobs site.

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.