There's lots to be said and argued on the subject of open source - its definition and the various licenses, creator/user relationships, the role of commercial entities in the ecosystem, whether startups should OS their projects and more. I'm not going to delve into that in this post, but for clarification, when I refer to open-source I'm using the layperson definition and including things like open-core and source-available.

Now the fun stuff! As part of my work on this project, I also cooked up some fun charts and tables around the most popular repos on GitHub, measured simply by star count. All the data and code can be accessed in this project. Feel free to run yourself or create your own charts.

Top-line Stats

I gathered the list of repos in Github over the past 5 years with more than 100 stars. Naturally, we expect as more time passes more repos will cross that mark, and that's indeed what we get:

Number of repositories in 2019: 34,232
Number of repositories in 2020: 33,191
Number of repositories in 2021: 24,990
Number of repositories in 2022: 19,910
Number of repositories in 2023: 15,416

I also plotted this out to see the growth over time

No idea what’s up with the the yearly peaks in the early months (Feb/March/April). I thought I had duplicate data at first, but that wasn't the case. If anyone has any theories I'd love to hear them. Might just be noise, seeing as it’s not quite as prevalent in the 5,000 star line.

Looking at the total over the last 5 years, we have:

Total number of repositories with stars > 100: 127,739
Total number of repositories with stars > 1000: 12,960
Total number of repositories with stars > 5000: 1,982
Total number of repositories with stars > 25000: 184

127k repos with 100 stars in 5 years is pretty crazy to me. Something something "networks". I’d be curious to get some data of user growth, and growth in user propensity to star projects or engage with Github in a more social way. I also wonder if “fake” stars contribute here meaningfully. This is relevant because star count is used as a proxy for popularity/traction/growth, particularly in pitch decks. There’s a great post from Dagster where they measure “fake” stars in projects and dig into the Github star black market.

For fun, here’s a table of the most starred repos in the last 5 years:

Repo Topics

Users can annotate their repos with topics, which gives us some interesting details on prevailing themes/languages/categories.

Unique topics in total: 97,666
Unique topics in 2019: 41,184
Unique topics in 2020: 42,476
Unique topics in 2021: 31,516
Unique topics in 2022: 24,881
Unique topics in 2023: 17,561

We almost have as any unique topics as we do repos, which I think is kind of interesting.

Of the last 5 years, these are the 25 most popular topics

Here's the same chart but with a 5,000 star cutoff instead of 100

Anything stand out?

1. What is going on with “Hacktoberfest”?

   It's an annual month-long event that encourages people to contribute to OS. The reason why it's the top-ranking topic for high-star repos is because those projects already have a lot of visibility, and thus attract attention during the event. Note that topics can be added at any time, so a project like Rust can have the tag, even if it didn’t start out as a Hacktoberfest project.

2. Python is the OS language king (more about this later).

3. Typescript/Javascript parity, on the surface. But when I looked further, there's a clear trend of Typescript supplanting Javascript. In 2019, Javascript appeared 831 repos to Typescript's 620. In 2023, It was 243 for Javascript vs 364 for Typescript. And of those 243, 89 had also tagged Typescript in the project. The people have spoken!

4. ChatGPT shows up in the 5k star chart, despite only being around for a bit more than a year!

Let’s take a greater look at the impact of LLMs. The top-N charts for 2019-2022 look more or less the same. Then in late 2022 ChatGPT comes to the scene and completely shifts the attention of the open-source community. Take a look below

2022

2023

Craziness. The amount of attention towards LLMs in the Open Source is unlike anything we've seen with any other trend, at least with respect to open source project creation. I wonder how this compares to the early internet days.

In the full jupyter notebook, I also have some charts around exclusive topics (meaning topics appearing in year X but not year Y). I'm not going to add it here, but one of the topics I saw was "NFT", so I wanted to see how it does in all the years

Number of repositories in 2019 with topic 'nft' and stars >= 100: 5
Number of repositories in 2020 with topic 'nft' and stars >= 100: 7
Number of repositories in 2021 with topic 'nft' and stars >= 100: 75
Number of repositories in 2022 with topic 'nft' and stars >= 100: 35
Number of repositories in 2023 with topic 'nft' and stars >= 100: 0

Yikes! But not surprising.

It was also fun to look at the counts for AI related terms. Here's one

Number of repositories in 2019 with topic 'llm' and stars >= 100: 10
Number of repositories in 2020 with topic 'llm' and stars >= 100: 8
Number of repositories in 2021 with topic 'llm' and stars >= 100: 15
Number of repositories in 2022 with topic 'llm' and stars >= 100: 52
Number of repositories in 2023 with topic 'llm' and stars >= 100: 663

Note that people can add a topic to a repo whenever, so the pre 2022 repos didn't necessarily have that topic before ChatGPT came out.

Here's another way to look at the above discrepancy between 2022 and 2023 topics

Top 25 topics in 2023, by percent of repos with that topic

AI topics dominate 2023, Language/Frameworks dominate 2022.

Last chart on this is around repo activity. In this case, inactive repos are those without a commit in the last 30 days.

Not too much to glean, except that many "ChatGPT" repos are toy apps, but fun to look at. The 10 point differential between GPT4 and GPT3 suggests people have moved onto the newer model.

Languages

Some repos add languages to “topics”, but there’s a more specific “language” field in the repo schema. Github uses Linguist to try and determine the “primary” language in a repo.

It more or less confirms what we’ve seen, primarily the outsized popularity of Python.

This chart is from all 5 years, but I also looked at each year individually. They mostly looked the same with 2 exceptions - one being that Python dominated 2023, going from around 23% of 2019-2022 languages to a whopping 34.5% in 2023. No doubt thanks to its monopoly in data science and AI and the onslaught of such projects in 2023. The other trend was the move from Javascript to Typescript, confirming what I mentioned earlier.

Subscribe now

X-post from

Vlad Writes

A Look into the Most Starred Github Repos

In our never-ending quest to improve and expand our deal sourcing, I recently started a project to ingest GitHub data and see what we can find there. We already have a number of portfolio companies that began as OS projects, such as Mermaid Chart, creators of…

Read more

2 years ago · 1 like · Vlad Rachev

Shift-left is a popular buzzword in the developer world, with countless pitch decks and marketing copy promising to shift left everything. The movement started gaining popularity with DevOps, the aim being to connect the traditionally disjointed fields of development and operations, and has now grown to include any permutation of business function X and Ops you can think of. DevSecOps, DataOps, MLOps, GitOps, FinOps, ChatOps (no seriously). So what is this all about, and is it just marketing hoopla?

Shift-left is not particularly new. The term has been around since at least 2001, and the idea itself has been thrown around even earlier. Essentially, it means moving a process (be it testing, managing deployments, monitoring etc..) earlier into the development lifecycle. The advantages make intuitive sense: moving operational processes closer to the development stage results in less friction, better integrations and greater resilience. It’s also a common sales pitch from infra companies. They’ll talk about how developers are now empowered to manage X, resulting in faster iteration cycles and cost savings from not needing whoever used to handle X. Sounds great? Maybe.

When does shift-left work and when does it fail?

#1 Shift-left done wrong increases cognitive cost for developers and overall complexity

For any of you reading this, particularly if you are a software engineer, do you ever feel like you have too many responsibilities? Or that you need to have so many horizontal skills to do the job? If this resonates with you, then you might be paying the cost of shifting left. 

The core idea behind shift-left is to move things that were being done later to being done earlier, but a common pitfall is work being introduced that was never done in the first place! There are a few reasons why this keeps happening.

• Team norms and rules around software are rigid and apply to all projects, regardless of size, scope and requirements. Once a practice is shifted left and adopted for one codebase, it often becomes a requirement for all codebases.

• Engineers like to optimize for maximum robustness and try to automate everything. They’re also financially incentivized to do so in many orgs. Many teams and engineers are not judged by how they contribute to the bottom line but by how complex the work they do is. 

• Not wanting to buy, only wanting to build.

• Sometimes the requirements change or you have to enable a use-case that wasn’t possible before. In these cases, the added complexity might be necessary.

When a new responsibility is shifted left onto an engineer without proper tooling and abstractions, it comes with a big huge productivity hit. Sometimes this is necessary, but we should strive to figure out the ROI and costs associated. It’s great to want to an app the scales horizontally to handle traffic spikes, supports failovers and is connected to an APM tool for all sorts of usage telemetry, but if your app is used internally by 2 people it’s probably better to just write a quick jupyter notebook and start getting immediate ROI. Partly this becomes a battle of premature optimization vs potential tech debt. Finding a good balance is important.

#2 With the right motivation, shift-left can reduce blockers and enable autonomy

Shift-left fails when it’s motivated by the wrong things: cutting costs (never happens), copying trendy processes, or adding complexity for vanity. At its core, shift-left is just the reorientation of process (you can also shift right, or add process in both directions). The goal is to figure out when a process step would be more successful if pushed left. Usually this is true when the current process is incredibly disjointed/siloed, brittle, and so stretched out that the incentives for success are lost in the confusion. Shifting left well requires a lot of work—good tooling, internal scaffolding (eg. platform/security teams), and a focus on reducing end-user complexity—but it can dramatically improve iteration speed, create stronger stakeholder/developer alignment and reduce overall pain. “Shift-left testing” is a classic example of this and is now the standard at modern companies. With a robust test suite and a well set up CI/CD pipeline, it may take just a few minutes for a code change to go from PR approval to production. This is much better than having manual QA for every change.

#3 Not everything needs to be shifted left

Above I mentioned that shifting left is simply the reorientation of process. Well, sometimes process needs to be to the right, or in the center, or be a part of multiple steps (people are calling this shift-everywhere). Jeff Williams has a fantastic post on how to think this through. Though he writes specifically about security processes, the ideas are applicable to other fields. Here’s an example he mentions that should be shifted right:

Authentication and authorization. Testing for these vulnerabilities is challenging. These functions almost certainly use custom code unique to the particular application, requiring manual testing such as pen testing. These vulnerabilities should be tested regularly, perhaps every year. Shift right. Far right.

Don’t just mindlessly shift left!

#4 Opportunities for founders

The big theme here is the importance of reducing complexity and empowering people to build faster and better. Shift-left is an approach to try and do this, but the crux is in the tooling that makes this possible. Without CI/CD engines, continuous delivery is not possible. Without the cloud, releasing a new app means racking up a server yourself. Companies that transfer complexity from users to their own product will succeed here. Cloud databases are another example here, and near and dear to my heart (I used to work at MongoDB). Today, when I’m working on a new side-project I can provision a robust, scalable database in minutes by going to a cloud DB vendor. When I worked at MongoDB and was still an engineer, we managed our own database for the internal apps we maintained. No need for a DBA or physical racks. This is the best kind of shift-left - I get autonomy, iteration speed, and arguably less complexity despite additional responsibilities.

Subscribe now

X-post from

Vlad Writes

So You Want to Shift Left?

Shift-left is a popular buzzword in the developer world, with countless pitch decks and marketing copy promising to shift left everything. The movement started gaining popularity with DevOps, the aim being to connect the traditionally disjointed fields of development and operations, and has now grown to include…

Read more

2 years ago · 1 like · Vlad Rachev

Thinking about developer trends is one of my favorite parts of my job, and I wanted to share some things I’ve been thinking about for 2024 and beyond. An interesting, albeit obvious thing I’ve observed about trends is that they take a long, long time to manifest, especially when it comes to developer infrastructure. It’s hard to pinpoint when a trend that’s been bubbling up for years hits a critical peak right before it becomes mainstream, so rather than attempt to predict the trends that will hit that peak in 2024, I’ll share some ideas that are in various stages in their potential S-curves.

User Experience Becomes Table Stakes for Developer Products

Some of you might be thinking, “isn’t this just DevEx? Haven’t we had dedicated teams doing this for years”, and yes, we have had that, and we’ve needed that, because the user experience of most developer products suck, and the ecosystem has gotten so complex that we need a team to help drive best practices.

I think the tide is changing, and we’re now seeing products with actual UX baked into it. Between 2010-2020 companies focused on creating infrastructure that scales - we’ve more or less done that, and now the focus is shifting to infrastructure that is pleasant to work with and improves developer speed.

Some areas of focus:

Fixing the CI/CD problem 

We’re slowly realizing that CI/CD is being wildly misused and does not reduce developer iteration cycles. CI/CD is good at what it does, which is to make it easier to merge code changes into production, especially on large teams working on complex projects. But we’ve been abusing CI/CD by using it while working on code changes. It’s not the dev’s fault - the problem is that tech stacks have gotten very complex and can no longer be tested locally. So devs just push to GitHub and wait 15 minutes for tests to run. Nice for coffee runs, not so much for productivity.

We’re starting to see this change, with solutions that enable developers to bypass CI/CD during active development but get similar feedback in seconds instead of minutes. There’s a number of approaches here. Local emulation is an interesting one, with a few examples like Wing Cloud, LocalStack, and System Initiative. We’re also seeing cloud-connected developer environments. There’s CDEs - like GitPod and GitHub codespaces which handle environment set up steps like installing dependencies. There’s also approaches to connect local environments with cloud resources - one example being Ampt, which has a REPL-like UX where every code change locally updates the live deployment (unique environment per branch) in real-time. 

Static environments -> Dynamic ephemeral environments

Traditional environment setups amount to a set of 3 or so environments, named something like “QA/Staging/Prod”. Naturally, this presents a host of issues when you have multiple people relying on a single environment for testing. For some reason it’s taken the industry a long time to either realize this and/or do something about it.

In the last year or so, we’ve started seeing a number of startups offering the solution - ephemeral environments. Instead of a static set of environments, users are able to get fresh, on-demand environments with production-matching services and seeded DBs. Qovery (our wonderful portfolio company!) has written about this and has a list of competitors in the space.

Modern terminals

Terminals have been more or less unchanged in 20 years, and we’ve grown so accustomed to them that my first reaction to Warp was along the lines of “You can do that? Just make a new terminal?”. Mostly this is a compliment to the traditional terminal, which I think is different from most of what I talk about here in that the UX is quite good - but I’m nonetheless very interested in seeing what happens here. The number of companies in this space and the level of funding (Warp recently raised a $50M series B - in the midst of a growth investing drought no less) supports the view that UX is not just a nice-to-have.

AI Tooling

I mostly ignore AI in this article, partly as a silent protest against the never-ending onslaught of AI content, and partly because it’s a muddy area with little extractable signal. But perhaps the one trend that has already developed is the use of AI in evolving the developer workflow. First it was Github Copilot with its fancy auto-complete, then we started getting code editors with native ChatGPT support like Cursor, and more recently we’re seeing PR generating bots like Sweep and Ellipses. Partly, this is about increasing developer speed - but it’s also about finding the right UX in this new age. I suspect this will continue to change over the next few years, and it’ll be interesting to see where we end up. 

Cost Reduction Driven Innovation

In 2022 and 2023, the post-ZIRP economy forced companies to pay attention to a previously long ignored aspect of the income statement - the bottom line. It seems crazy to think that we collectively ignored the primary goal a business has (generate profit) for more than a decade, but when capital is cheap we collectively rationalize a lot of bizarre behavior in the name of growth.

The transition from top-line to bottom-line focus has been brutal for the startup world, particularly companies who raised at high valuations in 2020 and 2021, but it has also created a new opportunity for startups to compete on, and we’re seeing a number of new architectural trends in the developer infrastructure world borne out of this new constraint.

Most of the architectural changes I see are from teams hypothesizing that the metrics and functionality that customers cared about in the last decade are the wrong ones and that we need to change the tradeoffs we make to align with the post-ZIRP reality.

Cost optimization is happening everywhere and in many forms, but I’m more interested in products built from the ground up with cost as a key objective. I’ll share a few approaches I’ve seen.

Leveraging Hardware Improvements in Data Infrastructure

Earlier I wrote:

Between 2010-2020 companies focused on creating infrastructure that scales - we’ve more or less done that, and now the focus is shifting to infrastructure that is pleasant to work with and improves developer speed.

I left out the reasons behind why this shift is possible, namely (1) the vast majority of companies are (surprise!) not at Google scale, and (2) hardware has improved so much over the last 10 years that many infrastructure needs can be met without needing massive systems.

Data in particular is seeing a reinvention towards a simpler and cheaper tech stack. Modern Data Stack in a Box with DuckDB - a fantastic post, is the closest thing to prophesying what this future will look like. Of course, a single node data stack is more of an exercise in possibilities - we may still want extra nodes for reliability and such, but it’s probably not an exaggeration to say that most data computing needs can be fulfilled in a single node with current hardware (and I don’t just mean using AWS’s insane 24TiB memory EC2 instances). 

Tools like DBT, DLT and DuckDB (amongst a myriad of competitors) are working to create a vastly simpler future, and thanks to hardware advances like the Apple M chips, previously “large-scale” end-to-end pipelines can now run locally. This will have big implications for data professionals, both by making development a lot easier but also unlocking new capabilities (eg. distributed pipelines on the edge/client or pipelines running on Lambda).

Distributed Systems Built on Top of Blob Storage (S3)

This has long been the case with data warehouses, data lakes and the such. But we’re starting to see companies in other areas such as streaming, queuing, observability and monitoring. The founders behind Warpstream have written some great content on the rationale behind using S3 and the potential to reduce costs by an order of magnitude.

The idea behind this is fairly simple. S3 is a persistent, highly fault tolerant, and nigh infinitely horizontally scalable K/V store that is significantly cheaper than disk based stores (in most cases at least - some caveats around file sizing and API costs). The big tradeoff here is the latency cost of S3. With block storage one can achieve sub-10ms latency, with S3 p99 latency is closer to 50x that. Clearly this won’t work for very latency sensitive systems, but many - perhaps most - systems, have requirements that allow for 500ms latency with no service degradation.

It makes sense that blob storage was first used with data warehouses, as the use-cases services there are traditionally (1) batch based, (2) historical and (3) analytical instead of operational. Companies want to store all their data, but don’t know if or when they’ll need it, and so blob storage was a natural candidate. But now founders are asking whether there are more cases where the use-cases are not quite as latency driven as we thought - and what that unlocks. 

Relatedly, minimizing networking costs (egress/ingress) is another key drive. Optimizing cloud costs in general is in vogue, and cloud networking fees are particularly exorbitant (eg. 59% of cost for a Kafka deployment).

We’re seeing infrastructure companies building with networking costs as an underlying constraint, and so are designing their architecture to try and minimize data movement - eg. using blob storage, shifting processing closer to the edge or client, pre-processing information etc.. 

X-post from

Vlad Writes

Trends in Developer Infrastructure and Tooling - 2024 and Beyond

Thinking about developer trends is one of my favorite parts of my job, and I wanted to share some things I’ve been thinking about for 2024 and beyond. An interesting, albeit obvious thing I’ve observed about trends is that they take a long, long time to manifest, especially when it comes to developer infrastructure. It’s hard to pinpoint when a trend th…

Read more

2 years ago · 3 likes · Vlad Rachev

Subscribe now

Until two months later, when he received an email informing him his credit score had dropped 20 points. He called up the credit card company again to point out he’d paid the full balance and closed the card. Actually, they informed him, he hadn’t. He’d had some interest that carried over from mid-cycle; the interest had accumulated late fees; no, they couldn’t tell him exactly how much more he owed—not until the end of the cycle, which wouldn’t be for another month. And sorry, no, they couldn’t do anything about his credit score. 

Tens of thousands of people have experiences like these every day. Why? Because banks, credit card companies, and other financial institutions don’t have access to real-time data. “Think about your own card,” Bivons says. “You make a payment. Do you have any idea where that payment was applied? Was it applied to the last item first, the highest interest item? You have no idea. And when you call the bank can't tell you either, because they don’t know.”

A decade of experience in private and public fintech, plus frustrations like these, led Bivons and co-founder Will Hanson to start Canopy, a company that builds servicing infrastructure for fintechs and financial institutions. “Canopy’s platform is providing this level of transparency and real-time data to allow people to make better decisions,” Bivons says. In a landscape where many fintechs are itching to offer more personalized credit and lending products, Bivons knew that better credit servicing was essential. 

Historically, fintechs looking to provide credit and lending products had to go through complex and costly regulatory and development pathways to build a single credit offering. Banking cores, the back-end infrastructure that handles accounts management and statements, could quote up to a million dollars in implementation and fees and a 12- to 18-month development timeline. This put loan management and servicing out of reach for most startups.

Bivons was determined to change this. He built Canopy to allow developers to launch—and service—financial products with minimum effort and maximum flexibility. “Canopy began as a safer student credit card,” Bivons explains. “To build the Canopy card, we needed Know Your Customer (KYC) verification, a decision engine, a bank sponsor, and a loan management and servicing system of record. When we learned how expensive — and limited — an LMS would be to license, we decided to build it ourselves.”

The interest from other fintech founders in Canopy’s back end was so great that Bivons decided to pivot and offer Canopy’s modern banking core and servicing automations as a service. He envisioned Canopy’s API powering a cornucopia of new credit and lending products.

The interest from other fintech founders in Canopy’s back end was so great that Bivons decided to pivot and offer Canopy’s modern banking core and servicing automations as a service. He envisioned Canopy’s API powering a cornucopia of new credit and lending products.

“Credit and lending products have largely been the same,” he said. “With Canopy you can customize more than 20 attributes of a financial product. When you combine that with possible variations on an individual attribute, like APR, and you allow for different policies to be applied at the account level, you unlock an incredible variety of lending and credit types.”

Customization, scalability, and simplicity are at the heart of Canopy’s platform. “Our developers designed our platform and act as an extension of the product team,” Bivons says. Their combined decades of experience working for scrappy startups and behemoths like Capital One meant they understood the challenges associated with launching a credit product from scratch and also what it takes to safely migrate very large, complex data sets.  “We want developers and operators of Canopy’s clients to be able to stand up lending products quickly and to personalize those products and not be constrained by the rules of the system or blocked by data migration issues.”

Thanks to his experience in fintech, Bivons knew that systems of record in particular are a barrier to successfully launching credit products.

Thanks to his experience in fintech, Bivons knew that systems of record in particular are a barrier to successfully launching credit products. In addition to an operations team that deals with customer concerns, “you also need a system of record that is immutable, meaning that the data is always accurate, that you can calculate all the rules and policies on a lending product in real time and retroactively. And then you need to extract that data in a compliant way for statements, for bank reports, et cetera,” Bivons says.

Before the launch of Canopy, fintechs often floundered when it came to developing robust systems of record. “It was not uncommon for startups to use Google Sheets,” Bivons said. “That might be fine if you have one customer who's repaying simply, and they repay on time. But what inevitably happens is that a customer misses a payment or calls in, wants to pay off early, wants to add a second product. Now add a hundred thousand users like that. Google Sheets can’t handle that level of personalization; even CQL or Mongo DBS can't handle that level of personalization. You need a system like Canopy’s.”

Canopy’s rising star suggests that the fintech landscape is more than ready for loan-servicing API platforms. TechCrunch reported in August 2021 that the company’s customer base grew nearly five times from February to May of 2021, and in August the company announced it closed a $15 million series A funding round (for comparison, Canopy raised $3.5 million in its initial 2020 funding round). 

One driver of Canopy’s growth is the market’s appetite for more flexible credit and lending products. Last year, 91% of all consumer loans in California were BNPL — an indication of the pent-up demand for alternative financing.

One driver of Canopy’s growth is the market’s appetite for more flexible credit and lending products. Last year, 91% of all consumer loans in California were BNPL — an indication of the pent-up demand for alternative financing.

Does this mean infrastructure providers like Canopy are the future of fintech? Canopy is, after all, part of a larger banking stack that includes card issuing, compliance, and collections as a service. Best of breed players like Canopy will eventually compete with all-in-one providers. But as of right now, the lack of a modern core is holding everyone back. “It’s true that Canopy’s partner ecosystem is made up of best of breed providers like Lithic, Marqeta, Plaid, and Stripe,” Bivons said. “But there’s no reason why we can’t be the core inside vertically integrated players, as well. In many cases, we can accelerate their go to market. We’ve had initial conversations with some of the most promising players. At the end of the day, everyone needs a new core. But once they’ve built that core, all the differentiation will come from the products they build on top of it and how they take them to market. Their core then becomes a source of technical debt. Having Canopy service that debt — no pun intended — makes a lot of sense.”

About Canopy

Canopy offers a plug and play system of record for companies to service lending products efficiently and reliably.

Founded 2019

Raised $15m as of Sep 2021 from Canaan, BoxGroup, Homebrew, Foundation Capital

Covid-19 has altered the digital commerce landscape for good. Fintech pioneers are developing new ways for midsize online retailers to meet exploding consumer demands.

After spending twenty years working in payment solutions, most recently with PayPal, Gr4vy founder John Lunn was well aware of a growing roadblock to efficiency: The payments team for every retailer he worked with was building essentially the same product from scratch and entirely independent of one another.

Why the redundancy? It’s usually simple enough for small online retailers to begin with a platform like Stripe or Braintree for cards. But as businesses scale up, a single solution is no longer enough. They need to add other payment gateway options, like PayPal, Square, Google Pay, and Apple Pay. And international customers may have a completely different set of expectations and needs. “Different parts of the world use very different methods of payment,” Lunn says. In Germany, for example, shopping online with a credit card is surprisingly uncommon—consumers are far more likely to use real-time banking. When he was at PayPal, Lunn worked with a merchant trying to move into South America who was quoted $8 million for each new country because of the payment options they’d need to add. “That's just crazy,” he says. “That's a ridiculous amount of money. And it's not that hard to do this. It takes time, but not that level of time.”

The problem, Lunn explains, is that the bigger their solutions networks grow, the more difficulties—and expenses—retailers encounter. “You're adding more and more pipes into the plumbing that you're building internally, and it gets bigger and fatter and becomes a problem. I think this has slowed down payment innovation over the last few years.” Potentially adaptive new platforms, Lunn says, “never get traction because merchants have to work out the true cost in technical debt and engineering.”

The problem, Lunn explains, is that the bigger their solutions networks grow, the more difficulties—and expenses—retailers encounter. “You're adding more and more pipes into the plumbing that you're building internally, and it gets bigger and fatter and becomes a problem. I think this has slowed down payment innovation over the last few years.” Potentially adaptive new platforms, Lunn says, “never get traction because merchants have to work out the true cost in technical debt and engineering.”

This complexity was a significant issue before Covid-19, but in the wake of the virus, it may be the single biggest minefield retailers must navigate. “I saw this at Paypal all the time,” Lunn says. “Giving customers the choice of how they pay for things is really going to increase your conversion at checkout. And this has been massively accelerated by Covid.” Before the virus, Lunn points out, “having some payment types missing, having some holes, that was okay. But suddenly Covid means 100% of your orders are online. So those small holes became massive gaps. A missing payment option could be the difference between whether you're going to survive or not compared to your competitor who is offering that payment type.” There’s been a huge shift, Lunn says, in options available to consumers, like installment payments and one-click checkout. “As a retailer, you can't ignore that anymore. You've got to do it all to be competitive.”

42% of American consumers won’t complete a purchase if they can’t use their preferred payment method, and 50% of them stop a purchase if they find the checkout method too complicated.

The numbers confirm everything Lunn says. Nine out of the top ten global online retailers experienced double-digit revenue growth in 2020, and that trend is only increasing for large and small retailers alike. And consumers balk at any hitches in online checkout. A 2020 PPRO survey found that 42% of American consumers won’t complete a purchase if they can’t use their preferred payment method, and 50% of them stop a purchase if they find the checkout method too complicated. Although 41% of retailers have adopted Buy Now Pay Later options, such as Klarna, retailers are falling behind in offering the one-click payment system Amazon has conditioned many consumers to expect.

Obviously, online retailers need to offer as many options as possible. Lunn built Gr4vy to address the snowballing gap between customer expectations and retailer capacity. Gr4vy is a cloud-native platform that merges what Lunn collectively describes as “payment orchestration” with payment infrastructure. 

Payment orchestration is a relatively new approach that allows retailers to process payments from multiple providers through a single API integration. The payment orchestration layer handles all payment logistics, including fraud detection, reconciliation, and validation. 

Right now, Lunn says, “Merchants are not aware enough that orchestration is an option. A lot of what we’re doing, and why we’re doing things this way, is that the market needs to learn about the orchestration options.” 

Right now, Lunn says, “Merchants are not aware enough that orchestration is an option. A lot of what we’re doing, and why we’re doing things this way, is that the market needs to learn about the orchestration options.” 

Lunn draws a parallel between payment orchestration and fulfillment. “Companies used to have to have a connection to DHL and UPS and FedEx and so on. And then along came shipping aggregators that made it really easy for you to pick the best way to ship your bottles. And that's what's going on here. Instead of exploring a custom solution for each new expansion,  retailers should get a payment orchestration solution.”

Like many other fintech innovators, Lunn sees client education as a large component of what he does. The type of client he encounters most often, he says, is a product manager “who has been given a goal to do something either internationally or with a specific payment type and who is very frustrated by the timelines that they're getting back. People who reach out to us directly are literally like, ‘Make my life better. I've been told we need to launch in Japan and it's going to take 12 months. Can you make my life easier?’” 

But Lunn encourages retailers to think bigger. “At first, a retailer might not want the entire Gr4vy platform to solve an initial problem. But once we've shown we can fix this problem, they realize the power of everything we can do. We’re selling a powerful solution that is essentially an alternative to growing an entire payments engineering team.” 

Gr4vy’s approach isn’t limited to its home in the cloud. It also offers data residency and sovereignty to its clients. Each merchant has their own instance of Gr4vy in the cloud; they don’t share infrastructure or server loads with other Gr4vy clients. Customers only pay for what they use, so they can scale up or down without penalty.

Covid-19 has changed the way we shop forever. And payment orchestration pioneers are ensuring mid-size companies are able to nimbly respond to the rapidly evolving demands of the digital marketplace frontier.

About Gr4vy

Gr4vy is a cloud payment orchestration platform that helps businesses manage their payment solutions.

Founded  2020

Raised $12.2m as of Jul 2021 from GFC, Nyca, Plug and Play, Activant Capital, Firestartr

‍Most of us make purchases online without thinking much about the machinery behind each transaction. For consumers, the process is simple: Punch in your credit card number, and you’re done. But for merchants, there’s nothing simple about payment. And until now, that’s been a growing problem.

For consumers, the process is simple: Punch in your credit card number, and you’re done. But for merchants, there’s nothing simple about payment. And until now, that’s been a growing problem.

The payment facilitation model developed as the newly evolving world of online commerce demanded more flexible payment solutions. Historically, few options existed for online payment processing. In order to accept credit card payments, businesses had to sign up for their own merchant account at a bank—and the approval process took weeks. Or, merchants could spend years (and millions of dollars) building out their own payment infrastructure. 

‍Payment facilitators offered a way to circumvent that logjam. Under this framework, the PayFac itself partners with a financial institution, allowing it to apply for its own merchant ID. After approval, the facilitator can use its account to sign up sub-merchants and process their transactions. The facilitator also absorbs the administrative services and compliance requirements—and risk—for its sub-merchants. Payment facilitation revolutionized e-commerce: All a business had to do was go online and fill out an application with a PayFac platform. Approval took minutes.

Payment facilitation revolutionized e-commerce: All a business had to do was go online and fill out an application with a PayFac platform. Approval took minutes.

PayFac is a relatively recent innovation; although PayPal went public in 2002, two of the most recognizable payment processors, Stripe and Square, were both founded in 2009. Initially, “becoming a fully registered PayFac was a two year multi-million dollar process,” Tilled founder Caleb Avery says. “Most businesses that are customers of big companies like Stripe and Square and Braintree aren’t familiar with what it actually takes to operate as a fully registered payment facilitator. It’s really only in the last few years that the concept of actually becoming that payment facilitator has become much more mainstream.”

It’s really only in the last few years that the concept of actually becoming that payment facilitator has become much more mainstream.

The past five years in particular has seen a rise in vertical-specific software solutions for a variety of non-payment merchant needs, such as scheduling customer appointments. “Every single vertical has their own software solution that is offering more than just payment processing,” Avery says. “These vertical software companies are coming in and selling a scheduling tool, a payments collection tool, invoicing, employee management, payroll—all of these additional benefits aside from just payments. The real question has been, ‘How do you power integrated payments inside of these vertical-specific software solutions?’ And that question has been fundamental to the fall of these legacy processors, the rise initially of solutions like Stripe, and now the rise of alternatives to Stripe.”

The real question has been, ‘How do you power integrated payments inside of these vertical-specific software solutions?’ And that question has been fundamental to the fall of these legacy processors, the rise initially of solutions like Stripe, and now the rise of alternatives to Stripe.

Platforms like Stripe succeeded because they were able to provide payment options for vertical platforms in a matter of days, and companies were willing to sacrifice profit for convenience. And Stripe has dominated the PayFac market: The company is currently valued at $95 billion, and Stripe is used by 1.96 million active websites. But some software companies realized they could potentially bring in greater profits from payment processing than their core products, and Stripe is no longer the right choice for them.

The big shift that’s happened over the last few years has been all of these vertical software solutions realizing how much money they can make by monetizing their payments.

“The big shift that’s happened over the last few years has been all of these vertical software solutions realizing how much money they can make by monetizing their payments,” Avery says. “Toast, in the restaurant POS space, is a perfect example. They make three and a half times more money on payments than they do on their core software offering. Once you understand that economic landscape, you realize that if your competitors are just giving away all the revenue on payments, you can have an incredibly lucrative revenue stream from payment processing. What a lot of these vertical software companies are starting to do is give away the software and then earn revenue on payments. And it’s allowing them to achieve a pretty incredible scale in the distribution for their products.”

PayFac-in-a-Box solutions like Infinicept, Finix, Payrix, and Amaryllis give companies the opportunity to become PayFacs themselves, but still require a significant investment of time and capital. And, unlike PayFac platforms like Stripe, they require companies to build their own compliance teams and handle their own risk and liability—a significant hurdle even for larger companies, let alone small startups. “They took that historically two-year multimillion-dollar process and brought it down about a six-month, couple-of-hundred-thousand-dollar process. That brought down the scale that you have to have achieved in order to make the economics of becoming a PayFac viable. But the reality is, it’s still six months. It still costs a fair amount of money. And you have to build out a team to handle all the underwriting, the fraud monitoring, KYC, PCI compliance. It’s a big burden to operate as a fully registered PayFac. Even for companies that have achieved the scale where economically it could make sense, the question is, ‘Do you want to take on that overhead and that liability to become a PayFac?’”

Avery worked in the credit card processing space before he spent two years developing Tilled to address this gap. Tilled offers PayFac-as a-Service rather than PayFac-in-a-Box, and ease of use is a core value of the product. “The focus all along the way was on the ease of implementation. Before we ever wrote the first line of code, my goal was for somebody to be able to come and implement Tilled in under a week,” Avery says. As importantly—and as radically—Tilled is based on a revenue share per transaction model rather than a fee structure.

The focus all along the way was on the ease of implementation. Before we ever wrote the first line of code, my goal was for somebody to be able to come and implement Tilled in under a week.

With Tilled, businesses can be up and running in a matter of weeks, profiting off the payments they process each year with no upfront costs or extra overhead.  “From a business model perspective, when you look at the PayFac-in-a-Box landscape—those guys are offering consulting packages, plus high SaaS fees, typically $10,000 a month. We came at it from a completely different direction, where it’s all about a very simple interchange plus wholesale buy rates and then a revenue share. We give our partners the full flexibility to design the pricing models for their end customers.”

The market took notice: Tilled has raised a total of $13.15 million in funding since the company’s founding in 2019. And the PayFac market is vast and growing. It generated $2 billion in transaction revenue in 2018, and is expected to climb to $25 billion by 2025. Avery believes the secret to Tilled’s success is straightforward: “There's no cost to working with Tilled. It's a very simple revenue share concept. The combination of those two factors has driven the excitement in the market about what we've built.”

Few people understand the complex PayFac ecosystem better than Avery, and building a knowledge base is a major priority for the company. “Education is a huge component of what we’re doing, and it’s a big part of our strategy. It’s less about building up a huge salesforce, and more about getting the word out there through conversation and letting the world know about the paradigm we believe in. We’ll come in and talk with our partners and our customers and educate them on the landscape and the options that are available to them to help them figure out what the right option is for their business.”

About Tilled

Tilled is a PayFac-as-a-Service platform that allows B2B ISVs to monetize payments that pass through their platforms.

Fintech

Founded  2019

Raised $13.2m as of June 2021 from Canvas Ventures, Alumni Ventures Group, Peterson Ventures, Clocktower, SaaS Ventures, Abstract Ventures, Hack VC

And apps like Gatsby, Robinhood, and E-Trade are drawing in unprecedented numbers of young investors whose attitude to trading is radically different from previous generations.

Gatsby cofounder Jeff Myers is riding the wave. Gatsby is a social network and a commission-free stocks and options trading platform. Its name a deliberate nod to the famously wealthy character of Jay Gatsby, the app strips away jargon and simplifies the process of trading, allowing users to express trade opinions with more leverage and find inspiration and ideas in their friends’ trades. And apps like Gatsby, Robinhood, and E*Trade are drawing in unprecedented numbers of young investors whose attitude to trading is radically different from previous generations.

This generation really wants to use trading as a form of entertainment.

“This generation really wants to use trading as a form of entertainment,” says Myers. When he and co-founder Ryan Belanger-Saleh started developing the app in 2017, they started by talking to their friends. “Most of them had maybe 90% of their money on a robot adviser or a savings account, just sitting around passively in a more responsible way. With the remaining 10% they were trading cryptocurrencies, sports betting—whatever alternative form of investing that typically has a lot of volatility and an adrenaline rush.” Younger people were open to a level of risk, older, more traditional investors were not. “They have less money and less access to opportunity than previous generations in America. They’re in the gig economy. There’s a very entrepreneurial spirit among Gen Z and Millennials,” Myers points out.

The trend toward younger traders with a high risk affinity was only accelerated by the pandemic.

The trend toward younger traders with a high risk affinity was only accelerated by the pandemic. A 2021 E*Trade study showed 58% of investors under 34 are trading more frequently, and 55% said they are trading derivatives more frequently. A survey conducted by the investment management service Nutmeg found that its users aged 25-34 were most bullish about personal finances and investing. Robinhood’s customer base, whose average age is 33, grew by three million users in the first four months of 2020. Some industry experts estimate that Robinhood’s current user base is closer to 20 million, a number Robinhood has not confirmed.

Regardless of the numbers, it’s a fact that apps like Gatsby are designed to appeal to Millennial and Gen Z investors.

Regardless of the numbers, it’s a fact that apps like Gatsby are designed to appeal to Millennial and Gen Z investors. Young traders, Myers notes, are plugged into multiple information workflows simultaneously, and they don’t want an interface that interferes with their access to other content streams. “When we first started Gatsby we designed it for ourselves, but that put us into a position where we were attracting very young traders. We thought, what are cool features that young traders specifically would want?”

In addition to its simplicity and accessibility, Gatsby’s users are drawn to the app’s social feed, which lets users see and take inspiration from community trends along with other feeds, like Twitter or TikTok. Community members start to recognize prolific users and pursue bullish behavior trends on the same ticker. “We baked that concept right into the app. Gatsby is a social network. You can see what everybody’s trading, you can like each other’s trades, you can comment on your trades. So I think every little differentiator that we have, every feature that we have that another brokerage doesn’t, or does a little bit differently, is tailored around this specific segment of traders.”

But critics say apps like Gatsby and Robinhood put young investors at risk by turning trading into a game without making users aware of the consequences.

But critics say apps like Gatsby and Robinhood put young investors at risk by turning trading into a game without making users aware of the consequences. In June of 2020 a 20-year-old Robinhood investor died by suicide after mistakenly believing he’d lost $750,000 on a risky trade. His parents, who are suing the company, say Robinhood deliberately targets young, inexperienced users and pushes them into high-risk trading.

You can't take speculation as a strategy in your portfolio and assume that you're going to make money.

“You can't take speculation as a strategy in your portfolio and assume that you're going to make money,” Myers says. “And we try to be very clear that there's a lot of risk involved in trading options, which are inherently very speculative. But you can use it to hedge other elements of your portfolio, or you can view it as just a fun thing to do with a small portion of the portfolio.” He also points out the users themselves are subject to encounter unusual market conditions like trade halts. “We have a push notification on specific tickers that have either SEC- or FINRA-driven warnings—or even our own warnings—about certain scenarios in the market. We've done it if something's expected to be extremely volatile and one of the exchanges will halt trading around it. Which also irritates users. And they usually blame the introducing broker, even though it just isn't trading, it's frozen by the exchange.”

Like any other investment platform, Gatsby operates in a post-commission based brokerage revenue stream. “We’re actually big believers in payment for order flow,” Myers explains. “The concept is what allows any type of exchange to have a healthy source of liquidity, right? If you’re trying to make a fine art marketplace, you need art and you need buyers, and you would probably pay to have more buyers on your platform and have more fine art for them to buy. And that’s sort of what payment for order flow is.” Myers agrees that payment for order flow got a bad reputation early on, in part because Robinhood in particular denied taking it. Transparency, he says, is extremely important. “We like to be very upfront with our users on that. It’s how we drive revenue. In fact, now that commissions are more or less gone, our approach is to add transparency.”

20% of all retail traders currently holding positions now bought their first position in 2020. Every month, so far, in 2021 has had a higher volume of options contracts traded than any other year in history. 2021 is a monster year for trade volumes driven largely by retail traders.

Gatsby has been able to nimbly capitalize on the rapid shift from passive investment accounts to active trading, but Myers points out that the investment world is changing so rapidly that it’s impossible to predict how regulators will navigate trends around volatile products like cryptocurrency or meme stocks. “20% of all retail traders currently holding positions now bought their first position in 2020. Every month, so far, in 2021 has had a higher volume of options contracts traded than any other year in history. 2021 is a monster year for trade volumes driven largely by retail traders. Which shows a correlation in interest out there tied to meme stocks—you can definitely inversely correlate our cost per acquisition to the price of GameStop as of this year, and Tesla was basically a meme stock the entire last year.”

But there’s this brand new concept of trading as entertainment having a crazy impact on stock values. I think that’s more of a culmination of a trend than a brand new phenomenon, but it’s fun.

For Myers, the uncertainty is part of the package—and that’s a good thing. He prescribes embracing the risk-taking spirit of adventure that characterizes Gatsby’s users. “With nobody really to blame, the regulators don’t know what to do about it, or who’s responsible, or if the brokers should have prevented it. But there’s this brand new concept of trading as entertainment having a crazy impact on stock values. I think that’s more of a culmination of a trend than a brand new phenomenon, but it’s fun.”

About Gatsby

Gatsby is a no-commission stocks and options trading platform that makes investing approachable to everyone.

Founded 2018

Raised $13m as of May 2021 from Techstars, Beta Bridge Capital, Rosecliff Ventures, SWS, Barclays, Plug and Play