Are @Stripe costs eating 8% of your revenue?  

Maybe.

Stripe's pricing is transparent, what's confusing is which combination of products you're using. They have 21 now. 

We crunched their fees:


Here are the 21 products, you probably use a combination of them. 

Each one has its own pricing that generally involves a % of your revenue.


Example 1: For a standard B2B SaaS, here is what the "Stripe Bill" would look like: 

🔥 at least 4% of revenue + fix fees 



Example 2: you're a vertical SaaS, like @ToastTab @Mindbody 

Add "Stripe Connect" fees to the bill: 

0.25%+$0.25 per payout
+ $2 per monthly active account


These are for the direct costs, how about indirect costs? 

Stripe does not implement itself, especially Stripe Billing. 
They event bought @GetBillflow, a company building the "UI" layer on top of Stripe Billing. 

They used to charge 0.2-0.5% of revenue too.


Also, most Stripe products can only be used with... other Stripe products. 

If you're using "Stripe Billing" and your users want to use: 
@Gocardless @Razorpay or day I say @Paypal as an alternative payment processor 
-> it's impossible

Last, if your entire pricing stack relies on Stripe products, your negotiation power is close to zero. 

There are countless examples: 
- @PartTimeSnob https://www.gmass.co/blog/negotiating-stripe-fees/


Stripe Billing new pricing announcement on @hackernews 
https://news.ycombinator.com/item?id=16766846

@DoNotPay even has a service to "appeal Stripe fees": https://donotpay.com/learn/stripe-fees/

Some teams like @Primer_io or Inai.io are working on this. 

We have the greatest admiration for Stripe. 

However, as former customers, we don’t agree with the “rent seeker” approach and closed ecosystem model, which is why we decided to create an open-source billing API. 

👇 https://www.getlago.com/company/about-us @GetLago 


Awesome read by @jules_boiteux on how @livestormapp transitioned from a license-based model to #UsageBasedPricing!

https://tinyurl.com/2uzh88ey

My team @GetLago's notes 👇

@livestorm used to price per license. 

Its limits: 
- Password sharing
- Prevented @livestorm to spread within each of their 5K clients: the product could be used for any video use case, but as it required to buy an additional license, people would think twice


@livestorm took the radical decision to make the product free to use for anyone within a client organization, and rethink pricing based on the value they brought. 

They chose "Active contact" as the value metric: 

They asked their customer to pay upfront for a "max" number of "active contacts" though, here is why:



To implement that: 

- Their engineering team had to compute the number of "active contacts" within a a billing cycle and give enough visibility to their internal teams and to the end-customer. 

- Here is how their process initially looked like internally:


They progressively improved the billing processes with: 

1/ A gauge to give visibility on usage to the end-user. 

We 💛 this and @GetLago enables merchants to do the same thing for their end-user too!


They also displayed banners and emails to inform end users when a usage limit is being reached. 


2/ For users who paid yearly, and had some spike in usage, they offered a "bucket" of extra active contacts that could be used during the year, without upgrading. 


3/ They also made it possible for the CS team to block accounts which overrode the limit too often. 

That's a wrap, congrats on these bold choices and the relentless iterations, long life to @livestormapp !

 🙌 @jules_boiteux thanks for sharing in such a thorough way!



How to annoy a fintech founder in one question: 
-> "Isn't @Stripe already doing this?" 

We've been crazy enough to work on an #OpenSource alternative to Stripe Billing @GetLago. 

Luckily, other people already see the huge gap in the market too. 

🔥🔥🔥

Keeping me up at night: are we missing out on web3? 
Especially as a fintech founder: @GetLago?

I did not want to take the risk, and deep dived in web3 for 3 weeks. 

Here are my personal notes, as a "Normie" 👇

Thanks @misssaxbys @amyrlewin @Siftedeu for the opportunity!

1/ Apart from one exception, there is no market for ‘crypto startups’ yet 

Does not mean there won't be soon, but we're not there yet.

There might be emerging Web3-related needs such as token-gating access to some resources, or payments, but the best positioned to win might be Web2 scaleups for now.

This is what @stripe did, or @stytchauth did.

The only exception might be “pure” crypto infrastructure companies. 

Typicallly the AWS of crypto: @AlchemyPlatform @Polygon for instance. 

2/ The most promising companies are using crypto behind the scenes

As a fintech founder, the applications of Web3 in the Web2 finance system are what intrigued me the most.

@chippercashapp, operating in Africa, is one example. 

In general, the use of crypto in DeFi for the underbanked markets are already having a massive impact. 

It's not necessarily branded as "web3": it's solving a massive pain, it's all that counts. 

Funds such as @firstcirclecap @SelmaRibica @Agnesog took notice. 

3/ Web2 companies need to steal Web3’s hiring and motivation tricks

The brain drain is real. 

There might be a slowdown, but web3 cos are well funded, and I've seen top talent flock into web3 without any offer, guarantee, package. 

This inflow of elite talent might actually  greatly contribute to make web3 mainstream.

What motivates them? 

This upbeat energy of building the future. 

The best way to describe it is to visualise Web3 as a whole new planet or continent: for builders, this means you can reinvent everything, every concept and shape it as you like


And this concerns all web2 founders: we need to work even harder to attract and retain top talents.

Sifted - Web3 from a Normie perspective

@GetLago is now available! 

We're building the Open Source Stripe Billing Alternative. 

Why Open Source & Billing? 

Our latest post on @hackernews blew up 🔥, 360+ comments like this one. Billing is truly a nightmare.

Billing is an engineering challenge. For some reasons, companies treat it as an Ops or Finance one. 
But it always ends on the plate of engineers. No, Zuora, Chargebee, Stripe Billing don't solve this. 
It's precisely described in this comment: 

So, the best way to build trust with engineers was to have complete transparency on our code, hence "open source". 

Also, billing is a litany of edge cases. Will a closed source SaaS solve them all? 

Probably not, that's why there are so many teams still struggling with their home-made billing system today. 

OSS enables the community to share and build on our API, and address this long tail.

Last, current billing softwares take a % on revenue, just because "they can". We resented this pricing and have high conviction another model can be found. 

What have we built so far? 
- Core API w/ 3 clients: Python, Ruby, Node.js
- “Lago Front”: an app to help trigger manual actions such as creating plans, billable metrics or performing, through the UI, any action available via the API

Our architecture is event-based: if you can track an event & its properties, you can bill on it. 
That gives you room to experiment a lot of pricing structures, as your product and market evolve. 


We have embedded billing logics, including:
- Dates
- Coupons
- Invoicing
- Add-ons
- Paying in advance or in arrears


The pricing stack is a team's sport, we're currently building partnerships with: 
- Payment gateways
- Invoicing, Accounting, Sales commission, Cash Collection solutions
- Authorization platforms
Any complementary solution of the Pricing Stack. Who should we talk to?

It's only the beginning, but our long term vision is to become
the billing standard for the next gen of software companies, especially PLG ones.

- Check out our @github repo here: https://github.com/getlago/lago

- Our public roadmap: https://github.com/getlago/lago/projects/2

You can read the unrolled version of this thread here: https://typefully.com/byAnhtho/Th3wGQk

Now available: Lago!

Billing might be way harder than getting pricing right. Why? 

It's an engineering nightmare 🤯

My co-founder @sarkissianraff1  😣 🤬 😊 gathered insights from: 

@GetQonto: our own experience
@Scaleway @Kdeldycke
@Pleo @arnon86
@Algolia @Segment
@UpflowHQ @AlexLouisy

🧵 here:


It's 100x harder than you think. This is not specific to our experience at Qonto, or even fintech. 

'Complexity compounds quickly. 

What should have been a 1 year R&D project ended up taking 7 years of my professional life, in which I grew the billing team from 0 to 12 p.

So yes, if you have to ask me, billing is hard. Harder than you think.' 
@kdeldycke ex VP Eng @Scaleway

@Algolia @bvnixon said it well: "easy on paper"

#2 Downgrades & Upgrades edge cases

For downgrades


#3 Usage-based computations

Some cos like @snowflake @algolia @aws are ahead and have gone full 'pay-as-you-go'. 

Others have or will adopt a 'hybrid pricing', a fix subscription cost, and a variable cost, based on usage, often called 'add-ons', 'overage'.

@segment prices on 'Monthly Users': meaning they need to track and count the users per account, constantly, and make sure to deduplicate them
It's a logic that needs to be developed and maintained, over time, and at scale:

@snowflake prices on the compute usage of data per hour. 
Its system is similar to an electricity bill, and the computation becomes even more complex for billing


#4 Idempotency

the ability to apply the same operation multiple times without changing the result beyond the first try

Meaning: retry to apply a charge, without double charging.
Simple in theory.


#5 Cash collection 

Revenue nightmare. You need to insist and recontact your client so that they pay you, without damaging the relationship.

Automations can help, but it's a very sensitive topic 


@UpflowHQ by @AlexLouisy is a platform that solely focuses on cash collection. This topic is no joke. 

It's what @LatticeHQ and @FrontHQ use btw! 

#6 The very best: the tax and VAT labyrinth

This is the decision tree: 


The engineering logic to be implemented will therefore look like this: 


To recap: the devil is in the details. 
And billing is not forgiving, 
- overbill, your customer will be mad, 
- underbill and you're leaving hard-earned revenue on the table. 

Full post here: https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers

We recently decided to open-source what we had learnt at Qonto, and to build the 
'Stripe Billing open-source alternative' 

* Open architecture: will fit any stack
* No lock-in of any kind
* No rent-seeker pricing, no cut on revenues

Check it out! www.getlago.com


Getting to your first 1000 customers looks like this. 

The litany of posts I found was pretty useless... except the one by
@darynakulya who co-founded @OpenPhone w/ @mahyarraissi

It's a 15-min read, or here are my notes: only actionable, no bs insights! 🧵

#SaaS #Growth

When @OpenPhone got into @ycombinator, they had 60 users. 

Stage 1: 0 to 1400 free users in 5 months. How? 2 channels

a) Facebook groups 
No promotional posts but asking the audience if they ran into the pb they were solving. Ask if they'd like to join the beta, without adding the link (sounds spammy)

b) Encouraging WoM
Engaging with users in-app, informing them when their feedback was in prod.

Stage 2: 0 to 100 paying customers

60 free users converted to paying the $9/plan. @darynakulya found the other ones through

a) Reddit: she monitored adjacent words and topics, engaged in conversations 
b) Facebook groups again, but different approach

No promotional posts, but she offered group admins to run Q&A sessions for their members on topics like customer engagement, building stronger customer relationships, and, of course, effective communication.

Stage 3: 100 to 1,000 paying customers

They joined @ycombinator and started cold outreach.

@) Sending 1000 emails a day did not work.

@darinakulya started breaking them in sub-segments, using PersistIQ. 

"You do have to invest more time into your cold outreach when you personalize your emails. However, the return on investment in terms of customer interest is worth it."

b) They also invested time getting a deeper understanding of users, the most useful question was: “How disappointed would you be if OpenPhone didn’t exist?”

They used this @typeform that triggered a @slackhq notification. That way, they refined the personas.


c) PR also helped. @techcrunch @producthunt

@darinakulya's advice: 
"If you choose to go down the media route, get targeted. Focus on the media sources your audiences naturally tune into rather than the national news sources."

d) Encouraging word of mouth again. How? 

rapid product updates + timely personal support, leading to glorious reviews 

My fav 💛 part of the article is how @darinakulya would do differently today. 


a) Share the mission earlier

"Quite frankly, people don’t care about your product. It’s the “why” behind your product that resonates with them, and that’s even more important if you haven’t launched your product yet."


b) Start cold outreach earlier

They started when the product was paying. It would have been easier when the product was in free beta

c) Building an audience before building the product 

"Customers are far more likely to purchase from a person they already trust than from a new startup with no recognition or traction."

d) Dive into customer data sooner

They lost 96% of their users when switching to paying. Embedding a @survicate survey into an email would have helped understand why. 

To wrap it up, the 4 questions we should ask ourselves:


The original blog post here: https://www.openphone.com/blog/first-1000-customers/ 

Thanks again @darynakulya! @OpenPhone path is super inspiring!

You can read the unrolled version of this thread here: https://typefully.com/byAnhtho/Dg7ljGK

Openphone - How we got to 1000 paying usrs

Complete noob to DAOs? 

We've all been there. 

Here is the cheat sheet I wish I had a few months ago, I only shared it w/ friends, but decided to open-source it!


"The beginner's guide to DAOs" by @ljxie @scalarcapital 

Her other guides are must-reads too. 

https://twitter.com/ljxie/status/1471313801307820032

1/n


"Community DAOs" by @patrickxrivera @viamirror

https://p.mirror.xyz/cVN3KOss0uqpZwxHQKtC4Syvn1RfXaxofFKHJuKLWS4

2/n


"The DAO of DAOs" @packyM @notboringco

https://www.notboring.co/p/the-dao-of-daos?s=r

3/n 


"The DAO landscape" by @Cooopahtroopa

https://coopahtroopa.mirror.xyz/_EDyn4cs9tDoOxNGZLfKL7JjLo5rGkkEfRa_a-6VEWw 

4/n

Follow these accounts to learn about DAOs by @Cooopahtroopa


https://twitter.com/Cooopahtroopa/status/1432403329422741504?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1432403329422741504%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fp.mirror.xyz%2FcVN3KOss0uqpZwxHQKtC4Syvn1RfXaxofFKHJuKLWS4

5/n

The reference for DAO tooling @daomastersxyz
🙌  @JuliaLipton @angelasanturb @WhiteFlamingo88 
@nelsontjordan

https://www.daomasters.xyz/resources 

6/n


Not strictly about DAOs but other basics to learn about web3: 

@Lijin's guide for non-technical folks 

https://twitter.com/ljin18/status/1479111931977867275?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed&ref_url=notion%3A%2F%2Fwww.notion.so%2Fgetlago%2FNew-to-crypto-and-DAOs-reads-e0ddaed098984b0fb7eb42d79b590e16

7/n 

Beginner guide to crypto @petergyang @odyssey_dao

https://creatoreconomy.so/p/curious-beginner-guide-to-crypto?s=r

8/n

What else should I add? 
Will share on a @github repo! 

You can read the unrolled version of this thread here: https://typefully.com/byAnhtho/uYYEmGR

Reading list - DAOs

Beyond memes, there’s still surprisingly little value-add content about product *distribution*. 

I finally found this 💎 by @may_habib @get_writer w/ Blake Barlett @openview.

Sharing my notes! 
#LearnInPublic #productledgrowth 

It’s common for founders to obsess on Product, but it’s only half of the job.
When I was at @ycombinator, partners repeated that ‘Product’ was kind of a comfort zone for founders. It’s much harder to go out there, distribute and face rejection.

1/n

@get_writer is @May_habib’s 2nd company, she built the muscle of switching:

FROM: ’Does it work’ mindset (Product)

TO:  ‘Does it work’ *and* ‘can we put in the hands of users’ (Product Distribution)

2/n

@May_habib breaks distribution into a 3-part framework: 
 
- How people find your product
- How they get to value 
- How users tell other people about your product

💛 it!

3/n

@Get_writer has product led growth, with only 1Ssales person. 

They use this shortlist of metrics: they should move *together* if 💩 is working:
- Overall traffic
- Visit &gt; trial
- Trial &gt; activated
- Activated &gt; paid
- By channel 

4/n

This means they don’t measure each metric separately. Which makes sense: 

For instance, if one teams own ‘traffic’, but the other ‘activation’, and if traffic goes up but activation goes down, what’s the output of the experimentation?

5/n

To @May_habib, hunting PMF is the #1 most interesting challenge.

There’s no silver bullet definition, but ‘user and dollar retention’ as often quoted by @LennySan are definitely to watch.

Read more in his newsletter:

6/n 

So the 2nd most interesting challenge is scaling and growth, 
and I wish all the best to @Get_writer!

Writing is indeed one of the only systemized business process, and the use of #AI and #NLP in their app is super impressive!

Try it out. 

7/n

Full link: https://podcasts.apple.com/br/podcast/may-habib-writer-why-founders-should-focus-on-distribution/id1356321172?i=1000557450883

Product distribution

I'm building a list of top *female* DAO operators, preferably *behind the scenes* ones.

@JuliaLipton @lijin18  
@brit @jaimeschmidt &amp; @bff are brilliant &amp; top of mind, I'm sure there are *LOTS* of other women worth following in web3.

Any idea? 
I'll share the list afterwards!🙏

I'll start:
@jocelyntypes 

@jeune_sage

@0xZakk
@roxinekee_ 

adding @ErikaBatista, I don't think you joined a DAO yet, but *community and vibes skills* would be awesome there! 💛