ceeker

Thanks. This is a fair point. I made up the example only to illustrate the idea. Since Stripe is considered some sort of benchmark here I was curious to see how they tackle all the learnings they will have over time...I feel it is very hard to think through all the future cases especially when you are just about starting out with your product.

For example, in financial services and insurance, regs change and what data we need to collect change and sometimes their dependency will change. I am curious what's companies that have grown substantially had to do to their APIs.

Can someone share how they handle versioning in their API when it comes to data model changes? For example `POST /users` now takes a required field `avatar_url` but it was not part of `v1`.

Since this field is validated in the DB, merely having `v1` `v2` distinction at the API layer is not sufficient. So I was thinking we will have to either 1) disable DB validations and rely on app validations or 2) run two separate systems (e.g., one DB per version) and let people 'upgrade' to the new version (once you upgrade you cannot go back).

Even though people refer to Stripe's API versioning blog, I don't recall any mention of actual data model changes and how it is actually managed

Can someone confirm if this can be used in a multi-tenant saas app environment?

Customers want to have their own SSO setup or user roles and instead of providing all those functionalities in the app, can we use Keycloak in front and the Customer can manage their own users/permissions via Keycloak?

So in essence:

Customer A: Have 5 users (login / password), 1 admin and 4 regular users -- admin can add or remove users

Customer B: Have an LDAP and would like to authenticate using it

Congrats on the launch. Your API looks very clean.

Do you support NuBank in addition to the big banks? I have heard NuBank has pretty aggressive anti-scraping approaches. Not sure if you support them or plan to in the near future.

Could you please share your reasons for looking at alternatives to Drools? I am in the process of evaluating Drools and it will be great to understand why people move away from it.

In case people from this project are still checking this thread. I am actually looking into Drools at this moment so the timing cannot be better...

I have a few questions:

1. Is this a new skin/interface for existing tools like Drools / jBPM or re-implementing that functionality?

1a. If new skin: is it fair to say, once the business application is built (there maybe bugs along the way due to the stage of this project), since the foundation is Drools / jBPM, we can expect production quality that we would expect out of Drools/jBPM?

2. What is the KIE Group? Is this owned by Redhat? It is very hard to tell by reading the footer.

3. Does the team provide consulting services to use these tools for an enterprise adoption?

I agree we need to companies that don't chase exponential growth. That being said, I am not sure if this advice is broadly applicable:

1. If you take VC money, they are not going to keep giving you more money if all you can show is linear growth. It may take a really long time for the company to become self-sustaining and just will not work with VC economics. Expecting them to change their mindset is not realistic unless the fundamentals also change.

2. If you don't need VC money, then you probably are not chasing exponential growth anyways. You have limited capital so you build a sustainable business (if your idea has legs) by chasing meaningful growth. So this article does not impact these companies.

3. If you are one of those rare companies that need some good amount of capital initially (hard to penetrate industry like healthcare or finance) but once established, maybe you can build a sustainable business without a lot of new capital. For this group this advice may make sense, find VCs who believe in linear but sustainable growth but you are definitely viable and the returns are still going to be attractive as you may need only 2-3 rounds of funding.

I would guess the number of startups that will fall under #3 is going to be really, really small.

In short, the article could have just argued for more bootstrapped businesses. But then, there may be many such companies already and we just don't hear about them... So maybe the article's point is to make more of those startups more visible so not everyone thinks they need exponential growth.. That just requires all consumers to crave stories that are ordinary so media companies can start writing less sensationalistic articles... maybe that's the billion dollar startup with linear growth!

This is the bit that you are missing:

>>Some restaurants were forced to add a surcharge on guacamole, or temporarily to scrap it from their menus altogether. Others swallowed the bill.

They could raise prices but they have chosen not to so far. They may have to in the future. That explains why their financials were not great.

Probably one of the best articles I have read about fund raising. It is much more tactical than the typical advice you see on this topic. First Round has a lot of fluff articles but this one is really worth reading.