Merge: One API To Rule Them All
The company on a journey to integrate one API to the entire world of SaaS.
Welcome to the second edition (and first Explore More) of ‘The API Economy’!
Be one of the early (now that it’s too late to be one of the first 😊) interested, forward-thinking people, to subscribe to the newsletter.
Hello everyone 👋 ,
Today’s edition of The API Economy is brought to you in partnership with Merge.
Shensi Ding and Gil Feig, the founders of Merge were kind enough to work with me on the first Explore More for The API Economy. I can’t emphasize enough how amazing the Merge team has been to work with, how important their vision is for the future connectivity of software, and how monumental this company is on pace to become.
Besides telling you about how great the Merge team is, I also want to tell you a little bit about how they are changing SaaS integrations as we know them through their ‘unified API’, or as I like to call it, one API to rule them all.
Now, let’s explore Merge.
We can build anything, but we can’t build everything
Does this integrate with [insert integration here]…
No software we want to use lives in a vacuum. It almost always has a context that is broader than the core users and functions it serves on its own.
If you’re in or have been around SaaS, you know one of the first questions to get asked when pitching a product is what any given tool integrates with. But with every company using specific tools that fit their specific need, the volume of integrations any given product needs is starting to feel endless.
According to a recent Okta study, the average enterprise organization uses 175+ applications and the quantity of the different software used is up 68% over the past 4 years.
So why doesn’t every software simply integrate every other software so we can all just have a fully-integrated tech stack? Total software composability sounds like a no-brainer, right?
Well, working with integrations tends to be technical, complex, and the ecosystem evolves constantly. One update or modification to a webhook or API can bring down an entire endpoint leading to significant downtime or disruption in your product.
Integrations are particularly complicated for 4 reasons:
They are difficult to build.
They are equally (if not more) difficult to maintain.
They are often table stakes for whether a company works with you or not.
Developers want to focus on core product competencies, not integrations.
That’s why Merge set out on the journey to become the integrations platform built to enable product development teams to outsource the entire process of building and maintaining integrations.
Their proprietary ‘Unified API’ gives developers a way to add integrations to their products within an hour as opposed to weeks (or oftentimes months or quarters).
Merge represents much more technological sophistication than IFTTT (if this then that) workflow tools. It represents the promise to link together B2B software, so all of our tools can work better together.
Think of Merge as the integration layer of your tech-stack, allowing you to leverage plug-and-play connections to any other SaaS tools. As opposed to developers spending their time spent building and maintaining integrations costing time, money, and focus away from the company’s core product roadmap.
As Ben Thompson more eloquently put it in his essay Stripe: Platform of Platforms,
This is a textbook example of the power of platforms; consider an operating system like Windows: any number of applications can run on any number of computers thanks to there being an abstraction layer in the middle:

Thompson describes Merge perfectly. They enable products to become platforms and operate more like well-connected operating systems rather than single-player games.
The API-first sweet spot
Working on an API-first integration platform puts Merge right in the API sweet spot. In APIs All the Way Down, Packy M explains the ‘API sweet spot’:
Giving Shopify merchants access to more inventory at better terms all in one place is core to what Shopify does, and it takes advantage of the scale benefits that Shopify itself has, bringing demand from millions of retailers to bear on wholesale negotiations.
Strategy is about knowing when to say no, so that when you say yes, you can go all-in. Because Shopify s-core things, it’s able to increase its product velocity on the things that really matter to its customers.
Now how about the API-first businesses themselves?
Strong API-first businesses sit in this sweet spot: they provide mission critical but non-core functionality to their customers, like accepting payments, providing cloud security, or sending communications to customers.
That means two things:
Massive Markets. API-first companies each provide a small slice of the things every business needs to do. Almost every company needs to collect money, remain secure, and communicate with customers.
Moats. They’re in a position in which companies can’t just rip them out -- imagine not accepting payments for even a day! -- but where it’s probably not worth the resources or defocusing to build a different solution in-house.

Because Packy is an investor in Merge, Shensi and I were able to reach out to him and ask him to elaborate on the ‘API-First Sweet Spot’ and how it applies to Merge:
“Engineers' time is any startup’s most valuable resource. You almost can't put a price on it; even companies that have raised a ton of money and are willing to pay nearly anything for great engineers because they face a constant shortage. So it's crazy, then, to spend all of this time, money, and heartache recruiting engineers only to have them work on things that don't differentiate the company. Since I wrote APIs All the Way Down, that challenge has only gotten more acute, which means that companies need to be even more focused on keeping their engineers' plates free of non-differentiating work.
The point of good API-first companies is to take as much of that non-differentiating work away from their customers' engineers as possible, both upfront and on an ongoing basis, and to do their particular thing better than any of their customers could.
Integrations sit squarely in the API-first sweet spot — every tech company has to do integrations, but they're never their core product. Engineers don't like spending time integrating with a bunch of third-party vendors and normalizing data upfront, and they really don't like wasting cycles on the Sisyphean task of maintaining those integrations and fixing them when they break.”
The concept of Merge makes the entire software industry as a whole exponentially better because it frees entire teams of developers being forced to work on integrations (that can be automated) and allows them up to make their products features and core components better.
Big enough to matter, small enough to win
So with a vision as big as becoming the platform for companies to build & maintain all of their B2B integrations and an idea with the potential to make Merge one of the biggest players in SaaS, why would Merge start by integrating ATS & HR technologies?
I’d like to think Merge’s approach to entering and expanding the market they started with is quite brilliant. If you think about it from a ‘Blue Ocean Strategy’ perspective, Merge is taking an approach to align API & integrations innovations to a painful, yet underserved market need.
To put blue ocean strategy simply:
Blue Oceans: these markets represent markets that don’t currently exist. In blue oceans, demand is created rather than fought over. The alternative challenge to this strategy is having to create demand in a market through innovation and education.
Red Oceans: these markets represent existing markets that might be big, but are typically highly fragmented and commoditized. In red oceans, market saturation creates cutthroat competition that turns the ocean bloody; hence, the term "red oceans."
In my experience, the companies that approach Blue Ocean Strategy the most successfully are the ones that can focus. Shensi & Gil decided that focusing on ATS & HRIS integrations was the perfect place for a few reasons.
Every HRIS & ATS needs to integrate, period.
There is a huge volume of HRIS & ATS solutions.
Both founders have felt this particular pain first-hand.
The market was a blue ocean.
It’s a big enough market to matter and still small enough to become the category king.
When chatting with Shensi to prepare for this essay, she told me:
“ATS integrations were really big for moving our plans forward to create Merge. Gil and I had a weekly Sweetgreen dinner where we’d chat about how even though we both worked in different industries (recruiting & cybersecurity), they shared a level of need for integrations. Because it was impacting both of us so similarly, it allowed us to think about the problem in a cross-category way.
On one particular evening, we sat down and Gil immediately started venting about how a Greenhouse integration was the bain of his existence. He had taken himself out of day-to-day meetings and management meetings so he could lock himself in a conference room to build out the integration.
He was frustrated because it was an integration the team needed to build, but he couldn’t afford to pull his team the core competencies that made their product so great. Which meant the burden felt on him to get the integration built.
We went back and forth about how throughout our career, the integration issue had a recurring theme. They were always mission-critical, but frankly, they were just a huge pain.”
So they decided to build Merge and picked ATS & HRIS integrations as their first categories to launch out of stealth.
To showcase the initial market opportunity, here are just a fraction of the modern HR Technologies powering today’s businesses:
To put the HR tech market in perspective, let’s use Workday as an example. The HR conglomerate has more than 600 integrations. Workday represents just one tool that over 600 companies have partnered with to build out custom integrations. That’s a lot of developers doing the exact same thing over and over again. 600 times to be exact.
They say the definition of insanity is doing the same thing over and over again while expecting different results. Well, when you build an integration, the process can be consistent, it all can be automated, and it can be scaled exponentially. The fact that we still build one-off integrations feels insane.
This makes building out integrations HR tech alone a huge market, without even considering the ability to add on new categories to the platform to continually expand their total addressable market (TAM) which is actually one of the things that excited me most about Merge
Why is it so important to go after big markets and have a gigantic TAM?
Don Valentine, Sequoia Capital via his “Target Big Markets” View From The Top talk at the Stanford Graduate School of Business:
“We have always focused on the market. The size of the market, the dynamics of the market, the nature of the competition. Because our objective always was to build big companies. If you don’t attack a big market, it’s highly unlikely you’re ever going to build a big company.”
In my opinion, Merge is going after, potentially one of the biggest markets I’ve seen and has the potential to become a very important technology.
So how big is the market opportunity for unified APIs? In a recent Forbes article titled ‘API Stack: The Billion Dollar Opportunities Redefining Infrastructure, Services & Platforms’ Patrick Salyer states:
As the API economy matures, I’m excited about what sort of API companies will continue to emerge. We will see more and more businesses built within the API Stack, a combination of API Infrastructure and API Services. Iconic, lasting companies will be those that can achieve breakout velocity, scale, and funding, providing a significant install base and war chest to broaden offerings via R&D and M&A. I’m confident that there is a bright future for the startups that are building these next generation of APIs, as well as all the businesses that will be built by this new set of infrastructure and services.
Merge is building just this, the next generation of infrastructure and services build on their API-first platform. As more and more companies adopt an API-first strategy, Merge will continue to grow and become a unicorn and beyond.
When I asked Packy (mentioned previously) about how big Merge had the potential to become, he stated:
“Merge's team, customer list, and growth are a big part of why I invested and why they were able to pull together such an all-star capital, but Merge's place in the sweet spot is why I think they're building a defensible and sustainable business, and why I think the opportunity is so huge. As more and more of the software that people use becomes a bunch of APIs talking to each other in the background, being the central hub for all of that activity is an extremely sticky and valuable spot in the software value chain. I'd be guessing at valuation here, but if the addressable market is all software companies that use APIs, and if Merge gets more valuable and harder to rip out with each integration it adds, I don't see why this couldn't be a $100B business one day.”
And while there aren’t too many $100b+ SaaS companies as of this writing, the trend among the most valuable software companies in the world is clearly to have endless integration options to best enable their users.
In fact, after doing some research on the top publically traded SaaS companies sorted by market cap, the top 10 SaaS platforms had on average over 2,000 integrations and other software add-ons (not included is private SaaS companies like the $95b juggernaut Stripe who opted this year to remain private.)
The biggest companies in SaaS realize the importance of integrations (SaaStr has done some similar research.)
The need for everything in SaaS to integrate
I’ve felt the problem Merge solves first-hand at every company I work with. To help paint the picture, I thought sharing some experiences from my time at Northpass (since we integrated with a lot of HRIS’s) might be helpful.
One of the core products Northpass sold during my time there was an API-First LMS (learning management system) mainly used by on-demand & gig-economy companies (like Uber, Lyft, Airbnb, etc) to create white-labeled onboarding programs for their distributed workforce (drivers, hosts, etc). Think of this offering as a headless LMS to run on the backend, with the power to build a fully customized UI on the frontend.
Since our technology was just the onboarding piece of a company’s tech stack, they always wanted additional workflows to pair with our technology both before and after its place in a given workflow.
Before our technology would kick in, many of the on-demand companies have an ATS (applicant tracking system) like Greenhouse or Fountain and a background check API like Checkr or Onfido to automate as much of the application process as possible (see workflow below for a visual depiction.) Remember, most on-demand companies are hard-pressed for a large quantity of talent, so they’ve gone to great lengths to make it a seamless process to work with at their company.
So, before someone gets launched into onboarding, they need to apply, pass their background check, and prove they are authorized to work for the company hiring them (usually as a 1099 contractor).
Once all of those boxes get checked, they get passed to Northpass to complete an onboarding program on a variety of topics including how the app they are working on functions, how to do their job, and other admin details.
Northpass collects data during the onboarding process, which gets passed to their HRIS (the CRM of HR) and other systems to centralize whether they completed the onboarding or not, store documents they uploaded, etc.
This diagram should help explain the workflow strung together by APIs:
There are a few things to call out during this process.
Most (if not all) of this process was typically white-labeled and you’d be hard-pressed to be able to tell that you’re touching an array of different software.
This takes a lot of integration and a little magic. The workflow is made possible by a well-thought-out string of APIs and webhooks.
Each use case has nuance, but this is more or less the workflow happening behind the scenes when you apply to work with an on-demand company.
For us to be a part of building out these workflows for every company, we needed to integrate with every ATS and HRIS to make every workflow work. Thinking through the logistics of this made me realize pretty quickly that there’s a LOT of HR software out there.
Since these integrations were table stakes, we went to work early on the strategy behind building out a full menu of integrations. As we planned and discussed taking critical resources away from our core product, we realized that integrations were critical but not something we were equipped to handle at scale.
To dig into our strategy a little bit, we still decided to bubble up integration build-outs to the number one priority on our product road map for a few different reasons:
The number of deals in our pipeline either blocked or lost due to the lack of an integration became too big to ignore.
It expanded our TAM significantly.
It gave us net-new partnerships from both a tech and a growth perspective.
It made us more global.
It opened up new use cases.
More integrations improved product usage, retention, ACV, and many other key SaaS metrics.
To summarize the strategy — we found our place in the ever-expanding software world and identified that to be successful, we needed more integrations to pair with the incredible technology we’d spent 6 years building.
I know what you’re probably saying to yourself, “it’s not rocket science genius, just build out a bunch of integrations.”
But I’m here to tell you it’s not that simple.
A recent Oracle and IDC webcast with Mickey North Rizza, Program Vice President at IDC, and Juergen Lindner, Senior Vice President of Oracle SaaS, put the problem into perspective:
Fully integrated SaaS environments are still rare in today’s workforce. In fact, only 5 percent of large enterprises (defined as 10,000 employees or more) have all of their SaaS applications fully integrated with corporate-wide systems. However, the full integration of SaaS with corporate-wide systems is an important goal for 97 percent of large organizations.
Since we understood the market’s demand for a fully integrated LMS, we set out to build one. Knowing how difficult it was going to be, we decided to deploy a large portion of our already lean engineering organization to build out new integrations.
Then we went to work scoping new integrations and seeing which ones we wanted to work on first. I remember sitting in one of the first debriefing meetings to discuss our integration strategy where we talked about integration capacity and at the bandwidth, we had, basically how many integrations we could build in a quarter.
The answer was one (and it ended up taking even longer.) Sacrificing significant engineering resources, features, functionality, and core product performance to be able to build out one net-new integration a quarter.
And the sad thing is, it still felt like our best path forward.
When we ramped integration production, we learned pretty quickly was our engineers weren’t particularly fond of working on integrations. They joined our company to build the first API-first LMS to run globally at scales that could support the tremendous growth of the on-demand boom. They wanted to focus on our core technology, which was enabling a distributed workforce to be able to learn how to do their job right from their phones.
What they didn’t want to focus on was building out a full-blown HRIS, building HRIS analytics features, or building out integrations to other software providers.
Don’t forget about maintaining integrations
I worked at another company where we did get to the point where we built out a sizable sum of integrations in-house after a big effort and we found out about the headache of integration maintenance.
In this Zapier article on ‘The Technical Debt Behind Your Integrations Strategy’, writer Adam DuVander states:
After you’ve built one integration–or several–the real work begins. While the initial integrations are factored into roadmaps and engineering workload, most teams are not as careful or realistic about what it takes to maintain what they’ve built.
APIs change, improve, and require you to adapt. And APIs disappear, for minutes, for hours, forever. The technical debt of API integrations is exponential.
In fact, we started to see a very clear progression of diminishing returns working on integrations where our progress would stall out because we’d have to spend more time fixing and maintaining current integrations and less time building new ones. At around 30 integrations, we finally got to the point where we had to pause building new integrations to focus exclusively on maintaining existing ones.
Founders built to build a unified API platform
Two Columbia grads come together to start a tech company… This isn’t the start of a joke, this is the start of Merge. Shensi Ding and Gil Feig met Freshman year at Columbia while chasing computer science degrees.
After college, they went their separate ways with Shensi went into investment banking and then cybersecurity. Gil on the other hand went into software engineering for companies like LinkedIn, Wealthfront, and then eventually led engineering at the Diversity Recruiting Platform, Canvas.
A fun fact on Shensi is she started coding when I was 12 (before the cool kids started coding). She loved coding, but she was always curious about finance which led her to the world of investment banking. While working in a corporate investment banking environment, she got introduced to the tech world and had the opportunity to join Expanse (recently acquired by Palo Alto Networks) as the Chief of Staff to the CEO.
There, she learned about how integrations can be a big problem for many companies. At Expense, it came up time and time again that they had to push data to other systems but the product team couldn’t build the integrations fast enough to keep up with demand. On the flip side, Gil was running into similar problems at Canvas and having to dedicate his critical engineering resources to in-house integration buildouts.
When I chatted with Shensi to dive deeper into the company and platform, she told me that starting Merge inspired her to rediscover the side of programming that 12 year old her fell in love with, and has since become a contributing full-stack engineer for the first time in her career.
Not only that, she humbly explained to me how she can add a new integration in as little as 4 hours and queue it up for the QA team to test.
The product & the team are both built to scale. And they have the proof.
The 1:many API

I set out to do some research on my own to see if I could find some people in the wild talking about Merge. And without looking very hard, I landed on G2 where Daniel Marashlian, Co-Founder & CTO at Drata was raving about his experience with Merge.
“I started integrating into HRIS systems one by one and quickly realized that the industry is very fragmented and complicated. I was going to need an API partner that took care of all of the subtle details from a 1:many perspective as it relates to HR data. Merge API team did this with excellence with their API, their easy-to-use web application, and their AMAZING team. The engineering team and even the founders would even get on with me on a shared slack channel to help us figure out edge cases.
The core problem we're solving with Merge API is we needed a 1:many API for all of these different HRIS & ATS tools.
1. We don't need to partner with these companies direct anymore, saving a lot of time.
2. The Merge API has a standard schema to it; it's kind of like Segment for the HRIS & ATS industry.
3. The web application lets the Customer Success team sign in and deep dive into a customer issue without getting engineering involved.
4. All of this added up, saves us on our engineering head-count budget, and allows our engineers to build more product features.”
In a follow up on the Merge blog, the team added:
“When we first came to Drata, it was clear that they needed a reliable and responsive product to help with the full integrations lifecycle. In assessing API provider options, Drata was focused on finding a solution that was proven and consistent. Downtime and bad data would result in customers violating their audit window — unacceptable results for a customer-facing enterprise experience.
With Merge’s SOC 2 Type II compliance, customers are ensured their data is stored in a secure environment. Our team’s commitment to customer relations and scalability means that any issues are addressed as they pop up, and Drata’s customers are able to access integrations as they are released.”
This highlights another point of why Merge is so good at what they do. It’s because they are obsessed with security. And they need to be if they want companies to trust them with critical components of their product.
Merge API At A Glance

I wanted to also touch on some of the technical specifics of Merge.
Merge currently integrates a variety of categories into their Unified API using platforms’ official APIs helping developers can harness the entire range of data. They make integrations with their Unified API painless with accessible API design, SDKs in multiple languages, and easy-to-use documentation.
An SDK or software development kit or devkit for short is a set of tools for software developers to be able to use your tool effectively. It’s essentially the instruction manual to tell developers how to use Merge, how to implement the code in their tool, and exactly what that code will do.
Their SDK integrates with your product using just a few lines of code (which takes 20-30 minutes to install) allowing you to easily authenticate any of their categories and applications including new ones as soon as they get added.
Once you integrate an application using Merge’s API, you unlock the API analytics you never knew you needed. Like their ‘Issues’ feature giving you insight into when an API there a problem (like an API goes down). From there they alert you, send you a template of the issue to relay to the company, and give you testing capabilities to ensure it actually comes back up.
The thoughtfulness of processes like this is what makes Merge such a well-designed user experience. Especially when you consider that without Merge, resolving an issue like an API going down requires an engineer to divert time from their sprint to troubleshoot.
Again, the theme is getting developers their time back.
Along with what Merge is, I thought it was important to clarify what Merge is not. Merge is not, Not, NOT a workflow automation tool. Typical workflow automation tools (like Dell Boomi — obvs acquired by Dell), are great for building out internal automation, but they don’t satisfy the need to integrate a large volume of software together more holistically.
Gil Fieg touched on this when being interviewed post-series A funding explaining, “They really are still workflow automation, which is mainly beneficial for internal use cases, like ‘when something happened on Salesforce, notify the sales team on Slack.’ The benefits overall of what we’re doing is the fact that we’re unified, the fact that you get 20, 30, 40 APIs all unified into a single format. That one build produces all of those integrations whereas those classic workflow products that more and more people are rolling out still require you to build one-by-one. They just move the implementation from code to having to drag and drop blocks in a UI.”
Since launching from Stealth in April of this year, Merge’s stats speak for themselves (as of December 2021):
4 Categories: HR, Payroll, Recruiting, Accounting (next up are CRM and Productivity Tools)
60+ integrations and counting
1,000+ organization sign-ups since launching from stealth in April
6M+ API requests processed per day
$20M in capital raised from:
Former MuleSoft CEO, Greg Schott
Cloudflare CEO, Matthew Prince
Plaid CTO, Jean-Denis Greze
PagerDuty CTO & Founder, Alex Solomon
Closing thoughts
Having had similar ideas for a platform in the past, I’m incredibly optimistic for the opportunity Merge has (see a screenshot of a business plan that loosely resembles Merge that I created last year).
I’ve always loved the idea of a unified API for integrations from a growth perspective because it is inherently a viral loop. This has been proven time and time again, but when you create a new integration in a category, start providing extreme value to a specific company, build up your partnership & referral program, and start making noise in the market — the rest of the companies in a category follow pretty quickly.
With many of its integrations, Merge is already starting to see the flywheel come full-cycle with promotion & partnerships as showcased here via a LinkedIn post by Ning Wei, Founder & CEO at HireBeat (who integrates with & uses Merge.)

Just because all the right things seem to be coming together for Merge to take over the integrations market, doesn’t mean it’s going to be easy. Some challenges they’ll have to overcome and opportunities they have before them:
Why APIs & why now?
APIs have been along for a very long time with the first mention on APIs coming over 50 years ago, so why is now the time for an API-first company like Merge to thrive? On the podcast TechTends, they answer the question well in their episode on ‘Plugging Into the Power of APIs’ with guest Stephen Markwell, Head of Treasury and Payments Product Strategy, Commercial Banking at JP Morgan Chase where he states:
We've seen in modern API's emerge in the last decade and these modern API's, they use ‘standards’. Standards are great but only when they are adopted by the majority. What we've seen recently, is mass adoption amongst some heavily funded technology organizations and so now:
You have standards that have wide adoption.
You have cloud based infrastructure which makes it easier for companies to integrate with API's.
You have a high degree of specialization.
So these factors are driving mass API adoption because:
These APIs exist.
They have standards wrapped around them.
They're easily accessible via the cloud.
You have specialized companies popping up just doing one piece of the value-chain and they're able to build businesses from scratch very quickly. I think it's become the way that we think about building everything.
It really feels like it’s APIs time to shine, especially with integrations. This puts Merge in the right place at the right time with the right team in place to do something special.
Continuing to educate the market on the benefits of a Unified API vs building and maintaining integrations in-house.
I’d like to think the market is coming around to APIs, but there is still a large portion of software companies that wouldn’t dream of outsourcing their integrations.
Similar to the journey it’s been to move companies from home-grown tools and on-premise software to SaaS tools in the cloud, Merge faces similar challenges in making Unified API integration adoption more mainstream.
Imitation is the sincerest form of flattery… Except in SaaS.
With the growth of a great idea and innovative technology, other companies are going to sprout up quickly. Considering how low the barrier to entry is to start a SaaS company these days, innovative technologies have a short horizon to validate their technology, become the market leader, and build moats to keep out the competition.
Take for example SOC 2 compliance software. Since SOC 2 was introduced in 2011, it took a few years to become more widely adopted (let’s say within the past 5 years) and then a few more years to become more prevalent for software to automate the process.
It started with one tool (I can’t even tell you who was first to marketing), but now, in just a few short years, we have potentially hundreds of SOC 2 automation software like Drata, Secureframe, Vanta, and more to handle compliance tasks.
Merge for the foreseeable future will have to continue to expand the market through the introduction of new categories and become the leader in each category before someone enters the market in a category they don’t yet serve.
As Merge’s base grows, net revenue retention should be top of mind.
With the go-to-market strategy discussed in this piece, a winning metric to pay attention to is net revenue retention. Essentially net revenue retention is:
([your revenue base] - [churned revenue]) + [expansion revenue]
Basically, it’s a metric to calculate how much more your customers are spending with you and if that base is growing.
For SaaS, 125% is considered good. In Snowflake’s Q3 earnings, they reported that they have a revenue retention rate of 173%, showcasing what great SaaS revenue retention looks like.
As Merge introduces more categories and integrations into their product which become more widely adopted, it should, in theory:
Make customers stickier and less likely to churn.
Increase usage leads to frequent upsell opportunities.
The more value customers get out of the platform, the more word-of-mouth referrals will flow in.
Thanks for reading — until our next adventure.