Launch YC S21: Meet the Batch, Thread #4
164 comments
GamerPay (https://gamerpay.gg/) is a scam-free marketplace for gaming skins and assets.
46% of gamers trading skins have been scammed more than once for either their money or their skins (survey of 5,000 gamers). 50% of gamers are under 18 and this their first online trading/cash experience. We solve this problem by integrating with Steam and making use of escrow, validating all trades. We are regulated by European Financial Services, and have a compliant way of onboarding minors, with parental consent.
I am the owner of Scandinavia's largest Counter-Strike community, with 82k members. Not a day goes by where I am not contacted by young people who lost their money buying and selling skins. They often get depressed, either because they lost a lot of money, or because it was part of their identity. In one case, a young guy lost all the money he had received from his confirmation, roughly 5000 dollars. He was ashamed and afraid to tell his family and friends. In another case, one that really got to me, a 17 year old was persuaded to give his ID to "prove his legitimacy" in a trade. The scammer saved the picture with him holding his ID, then created a fake profile and scammed hundreds of others, getting the 17-year old in trouble with the police and attacked on social media.
We did extensive surveys, found that this is a surprisingly big problem (the gaming market is of course huge) and decided that something needed to be done. Current solutions were obscure, too expensive, or unavailable due to region or age.
Example of how it works with us: a young gamer from the UK meets a US gamer on Discord or Reddit. The US buyer agrees to buy the UK seller's item. They go to GamerPay where the US buyer pays for the item. We hold the money in escrow until it's validated that the UK seller has transferred the exact item. The UK seller receives the cash on to their bank account. There is no risk in who "goes first" with the money or skin. We charge a straightforward transaction fee of 5%.
One nice thing is that for the first time, safe cross-border trades are now available. We have seen sellers from Denmark (where we're from) connect with buyers from the US. We have also seen our first seller doing 100 trades in less than 6 weeks on our marketplace. We look forward to hearing your feedback!
46% of gamers trading skins have been scammed more than once for either their money or their skins (survey of 5,000 gamers). 50% of gamers are under 18 and this their first online trading/cash experience. We solve this problem by integrating with Steam and making use of escrow, validating all trades. We are regulated by European Financial Services, and have a compliant way of onboarding minors, with parental consent.
I am the owner of Scandinavia's largest Counter-Strike community, with 82k members. Not a day goes by where I am not contacted by young people who lost their money buying and selling skins. They often get depressed, either because they lost a lot of money, or because it was part of their identity. In one case, a young guy lost all the money he had received from his confirmation, roughly 5000 dollars. He was ashamed and afraid to tell his family and friends. In another case, one that really got to me, a 17 year old was persuaded to give his ID to "prove his legitimacy" in a trade. The scammer saved the picture with him holding his ID, then created a fake profile and scammed hundreds of others, getting the 17-year old in trouble with the police and attacked on social media.
We did extensive surveys, found that this is a surprisingly big problem (the gaming market is of course huge) and decided that something needed to be done. Current solutions were obscure, too expensive, or unavailable due to region or age.
Example of how it works with us: a young gamer from the UK meets a US gamer on Discord or Reddit. The US buyer agrees to buy the UK seller's item. They go to GamerPay where the US buyer pays for the item. We hold the money in escrow until it's validated that the UK seller has transferred the exact item. The UK seller receives the cash on to their bank account. There is no risk in who "goes first" with the money or skin. We charge a straightforward transaction fee of 5%.
One nice thing is that for the first time, safe cross-border trades are now available. We have seen sellers from Denmark (where we're from) connect with buyers from the US. We have also seen our first seller doing 100 trades in less than 6 weeks on our marketplace. We look forward to hearing your feedback!
The fact that you need to hand over a Steam API key is really worrisome, and the FAQ entry for it isn't all that reassuring [1]. You're basically just saying "no it's cool trust us". Are you encrypting these API keys? Do you delete them after each transaction?
It's kind of a honeypot if you're holding onto the keys. You don't have the ability to revoke them so if they're ever compromised it's on your users to revoke them before misuse.
It's worth noting that there's a ton of undocumented (by Valve) Web API methods [2]. If you just look at the official documentation [3] it misleads you into thinking it's a read-only API for fairly basic data. I presume that GamerPay is relying upon some of these undocumented APIs as part of their implementation.
[1]: https://intercom.help/gamerpay/en/articles/5313751-is-it-saf...
[2]: https://steamapi.xpaw.me/
[3]: https://steamcommunity.com/dev
It's kind of a honeypot if you're holding onto the keys. You don't have the ability to revoke them so if they're ever compromised it's on your users to revoke them before misuse.
It's worth noting that there's a ton of undocumented (by Valve) Web API methods [2]. If you just look at the official documentation [3] it misleads you into thinking it's a read-only API for fairly basic data. I presume that GamerPay is relying upon some of these undocumented APIs as part of their implementation.
[1]: https://intercom.help/gamerpay/en/articles/5313751-is-it-saf...
[2]: https://steamapi.xpaw.me/
[3]: https://steamcommunity.com/dev
Thanks for the feedback on the FAQ and thoughts. Agreed that the Steam API key is sensitive data and thus all keys, user data etc are secured by appropriate encryption. Same goes for cash transactions & wallets that are handled by partners that are compliant with the financial authorities (to prevent eg money laundering).
We work with the Steam APIs on a daily basis and yes some part of the documentation could be more up to date.. and it's not Stripe quality!
Why do you need the API key? Why not just do it like a traditional escrow service: you receive both the money and the item traded to a steam account you own. Then once both are received you send the money and you send a trade request giving the item to the receiver?
Using bots as middlemen imposes other challenges. First there is a 7 day tradelock of the item. Second bots are prone for scams. Third you cannot play with your skin in the meantime
Would that mean Steam takes their cut twice? Or can you "gift" items for free?
You can gift them for free
We need the api key to validate the state of the trades
I’m not in your target audience, but I love the idea and the backstory. This seems like a real strong niche that was due for some innovation. Best of luck!
Thanks a lot, and I truly agree.
I know there are a lot of disparate services like SkinBaron[0] for individual games. Is your value-add that you're regulated / you can act as a middle-man for any steam items?
[0] https://skinbaron.de/en
[0] https://skinbaron.de/en
Our main value adds is that we can allow minors to trade safely. You have to be 18 at Skinbaron. Another is that Skinbaron charges over 20 percent total.
Race to the bottom, ignoring the winner-take-all scenario where you do everything for everyone, when the next group comes in at 2% + copy pastes your entire website copy and you’ve already inoculated to the end market that this solution works, which they piggy back on to get traction....can you survive more than a few qualified competitors and actually make it to cash flow break even? And why won’t this be a “many make no profit” type of market that settles with many undifferentiated sellers with close to substinance level terminal margins?
Obviously marketplaces are great, your product market fit seems strong, and you have both demographics and GMV trends behind you; but you’re in a space with passionate people who might do things for free (like people host or participate in gaming forums or discords).
Even at a few engineers you’re burning cash for quite a while, but you’re touching minors (sorry, no pun) in highly regulated markets like Europe, so you probably need a few compliance dedicated FTEs. How do you resolve disputes where it’s not QUITE the $50k skin and they sue? Or do you require arbitration at signup?
How does this work in the first 3 years until you hopefully win? VC funded burn?
Obviously marketplaces are great, your product market fit seems strong, and you have both demographics and GMV trends behind you; but you’re in a space with passionate people who might do things for free (like people host or participate in gaming forums or discords).
Even at a few engineers you’re burning cash for quite a while, but you’re touching minors (sorry, no pun) in highly regulated markets like Europe, so you probably need a few compliance dedicated FTEs. How do you resolve disputes where it’s not QUITE the $50k skin and they sue? Or do you require arbitration at signup?
How does this work in the first 3 years until you hopefully win? VC funded burn?
It's an escrow + marketplace service. Your argument can be used against anything like eBay, Etsy, Poshmark, etc. You're assuming that the OP stagnates while copycats emerge around them, which is also a horrible assumption.
Also, "free" cannot host websites, hire workers, add features (as quickly). It's funny you mention that their service will require multiple compliance officers while you simultaneously think there's also someone who can do it for free because they're passionate.
Lastly, a skin is a skin. There's no "not quite like it" because it's a digital good, not a sandwich. I'm sure they'll use their retained lawyer when someone sues for 50k.
Overall, it sounds like you're not even against their specific product, but the idea of being a venture funded startup.
Also, "free" cannot host websites, hire workers, add features (as quickly). It's funny you mention that their service will require multiple compliance officers while you simultaneously think there's also someone who can do it for free because they're passionate.
Lastly, a skin is a skin. There's no "not quite like it" because it's a digital good, not a sandwich. I'm sure they'll use their retained lawyer when someone sues for 50k.
Overall, it sounds like you're not even against their specific product, but the idea of being a venture funded startup.
I’d flip it (rather tongue and cheek) and say that it’s you that doesn’t appreciate market places. And here’s why.
Saying eBay (your listed comp) that can sell (almost) anything, in almost every jurisdiction with probably minimal config change, at different $ values (you can buy a server on eBay), w/ both consumer and SMB sellers, and like importantly preceded this idea and implementation by a solid (guess) 15 years and along the way was the first and many technical / tricky problems for these types of models has the same business model as a vertical marketplace is kind of baffling. Let’s ignore take rate, how does your GMV scale to within two orders of magnitude at terminal compared to eBay selling skins? And how much cash did you use to get there? Is it even NPV positive to do that without knowing the cohort behavior (I’d bet the gamers are huge repeats, but they may be less loyal to Brand vs Product than say an Etsy seller; importantly you have no idea a priori). Sure gaming TAM is probably huge, but taking OPs words as written (and being kind they can or will likely pivot) the serviceable piece of the market that relates to sort of second order entertainment derivative goods is what? (I.e. if buying the game is the gating item, and is costly like some AAA titles currently are, clearly that has to somehow impact the skin market, although obviously in some cases it can be bigger). Maybe I was poor as a kid but a $70 entry price to a given market would have been debilitating to remaining disposable income. Maybe that’s changed (higher allowances or greater income variability growing those cumulative available $s for transaction).
Maybe I’m an idiot but if you put on a table 4 cards, each with the unit economics of each transaction and the cumulative economics of that “customer” as defined between your stated: eBay, poshmark, Etsy, and a business deriving value on partially the disposable income of minors in sort of fuzzy space that albeit is probably exploding.... from a distance the established ones sure look a lot better (but of course that’s survivorship bias vs a early high growth startup with unknown potential).
I’ve seen the economics of some of the booming gambling/online casino/sports betting businesses that are trendy now due in part to deregulation. Leaving aside the customer acquisition cost discussion (go check what fan fuel is spending per customer in the initial US deregulated states), and the compliance overhang will always at least somewhat drag on economics. It simply has to. This is sort of anecdotal and based on a podcast, but Coinbase has what seems to be a very large legal team; obviously not identical models but I can’t see PayPal having that many attorneys on staff. Ceteris paribus the lower complaisance overhang has to at least somewhat be a drag on margins.
Net Net, businesses are different, people are different, industries are different ...everything is different at a deep enough level. You can like some but not all marketplace businesses based on how they operate and the strategy they take and how mature/captured the underlying market is IMHO.
Saying eBay (your listed comp) that can sell (almost) anything, in almost every jurisdiction with probably minimal config change, at different $ values (you can buy a server on eBay), w/ both consumer and SMB sellers, and like importantly preceded this idea and implementation by a solid (guess) 15 years and along the way was the first and many technical / tricky problems for these types of models has the same business model as a vertical marketplace is kind of baffling. Let’s ignore take rate, how does your GMV scale to within two orders of magnitude at terminal compared to eBay selling skins? And how much cash did you use to get there? Is it even NPV positive to do that without knowing the cohort behavior (I’d bet the gamers are huge repeats, but they may be less loyal to Brand vs Product than say an Etsy seller; importantly you have no idea a priori). Sure gaming TAM is probably huge, but taking OPs words as written (and being kind they can or will likely pivot) the serviceable piece of the market that relates to sort of second order entertainment derivative goods is what? (I.e. if buying the game is the gating item, and is costly like some AAA titles currently are, clearly that has to somehow impact the skin market, although obviously in some cases it can be bigger). Maybe I was poor as a kid but a $70 entry price to a given market would have been debilitating to remaining disposable income. Maybe that’s changed (higher allowances or greater income variability growing those cumulative available $s for transaction).
Maybe I’m an idiot but if you put on a table 4 cards, each with the unit economics of each transaction and the cumulative economics of that “customer” as defined between your stated: eBay, poshmark, Etsy, and a business deriving value on partially the disposable income of minors in sort of fuzzy space that albeit is probably exploding.... from a distance the established ones sure look a lot better (but of course that’s survivorship bias vs a early high growth startup with unknown potential).
I’ve seen the economics of some of the booming gambling/online casino/sports betting businesses that are trendy now due in part to deregulation. Leaving aside the customer acquisition cost discussion (go check what fan fuel is spending per customer in the initial US deregulated states), and the compliance overhang will always at least somewhat drag on economics. It simply has to. This is sort of anecdotal and based on a podcast, but Coinbase has what seems to be a very large legal team; obviously not identical models but I can’t see PayPal having that many attorneys on staff. Ceteris paribus the lower complaisance overhang has to at least somewhat be a drag on margins.
Net Net, businesses are different, people are different, industries are different ...everything is different at a deep enough level. You can like some but not all marketplace businesses based on how they operate and the strategy they take and how mature/captured the underlying market is IMHO.
Thanks for your thoughts - you cover a lot of land:)
I sense a bit of apples and bananas here comparing a newly started vs super incumbents (that were once small too in markets that likely didnt make sense for everyone at the time:))
We think the skin markets deserve something similar to Coinbase for crypto -> a place where I can trade with full confidence, it's easy to use and has what I am looking for.
Again, thanks for the thorough toughts
I sense a bit of apples and bananas here comparing a newly started vs super incumbents (that were once small too in markets that likely didnt make sense for everyone at the time:))
We think the skin markets deserve something similar to Coinbase for crypto -> a place where I can trade with full confidence, it's easy to use and has what I am looking for.
Again, thanks for the thorough toughts
100% not fair. Good catch! And deeper I wondered if the comparison example really broke in terms of the “sidededness” of the market or whatever the term was in the (AndersonHorowirz linked?) book on evaluating marketplaces.
If anything the “manual” feel of the minors onboarding looks so much like AirBnb, etc, you have to wonder if the company is sort of bound to succeed due to start.
Good luck on your ramp!
Is there a to email/contact you privately? I have a case study that’s very very close in big famous investor funded adjacent market that went sideways due a tiny detail; it’s public but would be more considerate to talk 1 on 1.
If anything the “manual” feel of the minors onboarding looks so much like AirBnb, etc, you have to wonder if the company is sort of bound to succeed due to start.
Good luck on your ramp!
Is there a to email/contact you privately? I have a case study that’s very very close in big famous investor funded adjacent market that went sideways due a tiny detail; it’s public but would be more considerate to talk 1 on 1.
And what would prevent us from accepting minors as our clients or lowering our commission? Both would be possible with the push of a button and some changes in our TOS. We probably won't do either and there are reasons for that. Just trying to dismiss this point.
Interesting discussion overall...greetings from Hannes (CEO SkinBaron GmbH)
Interesting discussion overall...greetings from Hannes (CEO SkinBaron GmbH)
You are right, you could do that. It would mean some changes to your KYC flow, and probably also a few chats with the bank to stay compliant. Lowering comissions sure. I am not aware of your costbase but could be doable. Now that you are here, why do you charge so high fees? And what are your thougths about Netease looking towards the west?
NetEase's success will depend on their willingness to understand and adapt to EU mentality. There are many big failures of marketplaces that tried to expand to different continents, look at Rakuten's failed EU expansion for example. Also one of the reasons why we don't do an expansion to Asia or the US (yet).
So NetEase is the least of our worries for the future, macro factors and the success of CS:GO including Valve's strategic decisions with the game play a much bigger role than any competition in my opinion.
Why do we take high fees? We could obviously outsource employees and other expensive tasks to lower the cost base significantly, but it would not be needed. The margin is very good with our current cost basis already.
Raising our fees from 10 to 15 % was a decision made after OPskins and BitSkins both played themselves and went offline / took a pause. We had more inflow of users than we could handle. Now we can handle the inflow, but don't see a reduction from 15 to 10 % as the right decision to drive user growth. Of course if the market adapts as a whole and everyone takes a lower commission, we would have to do the same in the end.
So NetEase is the least of our worries for the future, macro factors and the success of CS:GO including Valve's strategic decisions with the game play a much bigger role than any competition in my opinion.
Why do we take high fees? We could obviously outsource employees and other expensive tasks to lower the cost base significantly, but it would not be needed. The margin is very good with our current cost basis already.
Raising our fees from 10 to 15 % was a decision made after OPskins and BitSkins both played themselves and went offline / took a pause. We had more inflow of users than we could handle. Now we can handle the inflow, but don't see a reduction from 15 to 10 % as the right decision to drive user growth. Of course if the market adapts as a whole and everyone takes a lower commission, we would have to do the same in the end.
Am I seeing this correctly?
Digital reskins of knives in CSGO sell for $200+ Euros?
Digital reskins of knives in CSGO sell for $200+ Euros?
Yes they're ultra rare and the lootboxes always cost money to open in CSGO.
Yes, and that is a very low price. Knives and gloves are most sought for. We see average basket sizes being around 150 euro
What do you think is wrong with existing solutions like OPSkins (RIP, played themselves), Bitskins, etc?
Most marketplaces fall under obscure or to expensive. And pretty much none of them have built a compliant way of onbording minors who suffer the most from scamming. So they are all 18 plus.
Is it not possible to sell being a US user? Cant get past "Payout & account information". Revoked my key for the current.
For the moment you cannot sell as a US citizen. We hope to silve this in the near future
changing currency doesn't seem to work for me, stuck in EUR.
Anyways, this is great. Between lootbear, csmoney, and steam marketplace, I think i like your model best since it translates directly to cold hard cash. However, last I seen this model in the wild, it got banned.. re: OPSkins. How are you circumventing that?
Anyways, this is great. Between lootbear, csmoney, and steam marketplace, I think i like your model best since it translates directly to cold hard cash. However, last I seen this model in the wild, it got banned.. re: OPSkins. How are you circumventing that?
OpSkins got banned because they tried to circumvent the 7 day tradelock, and they we also moving closer to the position csgoempire have today which is skin gambling. We dont want to be that. We want to do for skins, what coinbase did for crypto
But this is against TOS, isn't it?
Since when did rules/laws start mattering for vc-backed startups? Continue paying fines until you're large enough to bribe, I mean lobby, for the law to change. It's just cost of doing business.
It's very difficult to go after/shut down sites that breach ToS like this. See nearly every gold-selling site for any MMORPG in existence. They do sometimes get shutdown eventually but typically after many years and they often re-open with a new brand name.
It's very difficult to go after/shut down sites that breach ToS like this. See nearly every gold-selling site for any MMORPG in existence. They do sometimes get shutdown eventually but typically after many years and they often re-open with a new brand name.
Honestly it's just bittersweet that YC does due dilligence like this for gaming startups. I mean some of them are cool businesses (like this one), but I'm a little salty since selling items not through steam is absolutely against valve's TOS. Remember that startup that wanted to do an mmo with thousands of players, VR etc etc and the demo was a compilation of free assets in UE4..?
Ok, now back to work.
Ok, now back to work.
It is not against valves terms of service. They actually embrace the developement community around steam and their games
Valve only allows non-commercial use [1], and selling items not on steam marketplace is clearly against it.
[1]: https://store.steampowered.com/subscriber_agreement/ (2 A)
[1]: https://store.steampowered.com/subscriber_agreement/ (2 A)
This is for the steam client, and thi agreement is mainly aimed at content/game developers
Which service and API do you use to trade items then? Is it not steam?
I think that GamerPay might be in the clear, but they require Web API keys from users. The terms [1] of those keys don't seem to allow for sharing API keys with third parties like this:
> 2. License to Steam Web API & Steam Data. Subject to these Terms of Use, you may access the Steam Web API, implement the Steam Web API in your Application, and distribute Steam Data to end users for their personal use via your Application, all in accordance with the Steam Web API documentation. This license is subject to the following restrictions: [snip]
> You agree to keep your Steam Web API key confidential, and not to share it with any third party. This license is personal to you and specific to your Application. You agree that you will be personally responsible for the use of your Steam Web API key.
When you request an API key from Steam they ask you to include the domain of your application. GamerPay instructs users to just put their own username in that field.
[1]: https://steamcommunity.com/dev/apiterms
> 2. License to Steam Web API & Steam Data. Subject to these Terms of Use, you may access the Steam Web API, implement the Steam Web API in your Application, and distribute Steam Data to end users for their personal use via your Application, all in accordance with the Steam Web API documentation. This license is subject to the following restrictions: [snip]
> You agree to keep your Steam Web API key confidential, and not to share it with any third party. This license is personal to you and specific to your Application. You agree that you will be personally responsible for the use of your Steam Web API key.
When you request an API key from Steam they ask you to include the domain of your application. GamerPay instructs users to just put their own username in that field.
[1]: https://steamcommunity.com/dev/apiterms
Valve only allow non-commercial use of virtual items, you can only sell items through steam marketplace
This is not correct
No it is not
I'd love to see this made available to the Spanish market next, will follow and see how you do.
You can actually use it in Spain, Portugal, Brazil and more. However you have to live with it being in English for now
V cool. Is there a way to publicly verify a transaction went through? Or they send a screenshot?
They do it through a unique link from our platform. And once signed in as a seller you will get notifications and sms when you have a trade
I assume this is where the integration with Steam comes into play. Checking the seller's inventory and the buyer's inventory
Correct
We’re Aditya and Karan, the co-founders of Warrant (https://warrant.dev/). We build APIs and infrastructure to help developers implement authorization and access control in their apps.
Implementing flexible authorization that grows with your application is difficult. Many products only need authentication early on but eventually require authorization; however, adding complex authorization to a mature, high usage product is even harder. We’re building Warrant to better abstract the complexity of authorization and reduce implementation cost and maintenance drag for engineering teams.
Warrant abstracts your authorization rules and access control logic outside of your application so it isn’t coupled to core business logic. We adopted concepts from Google Zanzibar to make Warrant flexible enough to support any access control model. Authorization rules are easy to enforce in backend and frontend code at runtime through simple API calls. Both developers and non-technical users can modify access rules through our dashboard to change application behavior without needing to change code.
We’re taking a service-driven approach to authorization. As companies get bigger and build out multiple services, authorization logic needs to be re-implemented in the new services or some central service. Whether you’re a small startup with a monolith or a company with many microservices, we think decoupling your authorization and having a dedicated authorization service is the right approach. Check out our demo app (https://github.com/warrant-dev/warrant-demo-app-ts) for an end-to-end example of how to use Warrant.
Implementing flexible authorization that grows with your application is difficult. Many products only need authentication early on but eventually require authorization; however, adding complex authorization to a mature, high usage product is even harder. We’re building Warrant to better abstract the complexity of authorization and reduce implementation cost and maintenance drag for engineering teams.
Warrant abstracts your authorization rules and access control logic outside of your application so it isn’t coupled to core business logic. We adopted concepts from Google Zanzibar to make Warrant flexible enough to support any access control model. Authorization rules are easy to enforce in backend and frontend code at runtime through simple API calls. Both developers and non-technical users can modify access rules through our dashboard to change application behavior without needing to change code.
We’re taking a service-driven approach to authorization. As companies get bigger and build out multiple services, authorization logic needs to be re-implemented in the new services or some central service. Whether you’re a small startup with a monolith or a company with many microservices, we think decoupling your authorization and having a dedicated authorization service is the right approach. Check out our demo app (https://github.com/warrant-dev/warrant-demo-app-ts) for an end-to-end example of how to use Warrant.
While I think this is a cool idea, the thought of hitting the network via an API call at minimum once per request sounds ... less than ideal. That's a lot of latency add just to check authorization. And you go to all this effort to configure authorization in Warrant per-user and per-resource, why not just put it into your own tables?
Edit: and I just saw the pricing... 1k API calls a month? I'd quite literally hit that in minutes. :)
Edit: and I just saw the pricing... 1k API calls a month? I'd quite literally hit that in minutes. :)
Thanks for the feedback! Latency/perf is definitely top of mind. We're looking at different ways to improve it (caching, sidecar integrations, private cloud deployments), especially for large volume users. But we still believe that a service-driven approach is the way to go.
In terms of initial setup and configuration, I agree there's room to improve and remove friction. We're building tools and integrations that should just make this much easier.
We're also iterating on price and do offer volume discounts. So if that's an issue, reach out to us! ([email protected])
In terms of initial setup and configuration, I agree there's room to improve and remove friction. We're building tools and integrations that should just make this much easier.
We're also iterating on price and do offer volume discounts. So if that's an issue, reach out to us! ([email protected])
Depending on how much memory the rules take up you could use SSE in the server SDK. I believe that’s how LaunchDarkly works.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
Very cool! I wasn't aware of SSE. This could be very useful for our React SDK as well. Thank you for sharing :)
As a founder of a startup building an authorization product, I can definitely say it's super appealing to build this as a service! It makes for a an easier story around monetising it.
When we were building Oso [1], we were optimising for the best thing for developers, and reached the same conclusion as you... (a) It doesn't make sense to rearchitect your app to move all the data to a separate service, and (b) it's way less complex to build it in the application. That's why we're building Oso as an open source library instead. You get to leave your application data in the application, and don't need to worry about adding an external service to the critical path.
[1]: https://www.osohq.com/
When we were building Oso [1], we were optimising for the best thing for developers, and reached the same conclusion as you... (a) It doesn't make sense to rearchitect your app to move all the data to a separate service, and (b) it's way less complex to build it in the application. That's why we're building Oso as an open source library instead. You get to leave your application data in the application, and don't need to worry about adding an external service to the critical path.
[1]: https://www.osohq.com/
Seriously -- this looks *awesome.* Oso's policies look almost exactly like the Pundit policies in my business's Rails app, which is awesome to see.
How do you plan on monetizing, if you haven't already?
How do you plan on monetizing, if you haven't already?
Come on, isn’t it just a bit not ideal to go point by point in someone’s yComb announcement thread (which is sort of a happy event because historically a lot did cool things and grew really hot) re: someone else’s biz? Maybe you do a showHN the other company if it’s so differentiated to let these guys just starting out try to put their message out to the world.
Sorry didn’t mean to word that negatively btw. On mobile not at home.
Sorry didn’t mean to word that negatively btw. On mobile not at home.
I think it’s pretty normal for this to happen on launch and show HN posts (just like it’s normal for a fellow HN user to tell you that your startup can be cloned in a day.) We’re an odd bunch. :)
We don't usually let people change the subject to their own thing in someone else's launch thread. It's boorish.
We're a little less active about it in YC launch threads, though, because of the first principle of HN moderation: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu.... That's why I haven't said anything in the places this has happened in today's thread.
We're a little less active about it in YC launch threads, though, because of the first principle of HN moderation: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu.... That's why I haven't said anything in the places this has happened in today's thread.
Fair enough. Though I don’t agree that discussing or mentioning a competitor is changing the subject, especially when that competitor addresses some of the issues originally mentioned.
Thank you! Pundit is awesome, they did such a great job with it and we drew a lot of inspiration from it.
We're heavily focusing on adoption of the open source product right now for helping developers with application authorization. We do currently charge for things like support + consulting, but in the future we're planning on providing additional functionality through a service that would be more on the operational/security side.
We're heavily focusing on adoption of the open source product right now for helping developers with application authorization. We do currently charge for things like support + consulting, but in the future we're planning on providing additional functionality through a service that would be more on the operational/security side.
This looks really great! Would have loved something like this a couple of years ago before rolling our own, this would have saved so much time and effort.
Borrowing a lot of LaunchDarkly's playbook for feature flagging will serve you well here. Server Sent Events and providing a self host-able "relay proxy"[1] will be extremely valuable in terms of perf and redundancy.
[1] https://github.com/launchdarkly/ld-relay
Borrowing a lot of LaunchDarkly's playbook for feature flagging will serve you well here. Server Sent Events and providing a self host-able "relay proxy"[1] will be extremely valuable in terms of perf and redundancy.
[1] https://github.com/launchdarkly/ld-relay
I think this is interesting but I’m missing something. To me at least this doesn’t sound simpler than just using oauth to authenticate and then having a roles table etc on the backend to authorize. What would you say is the killer feature that would change my mind about this?
Thanks for the question! A couple of things that we think are killer features of Warrant:
- The flexible access control modeling. Implementing a basic RBAC scheme isn't too difficult with a couple extra database tables, but going further than that (fine-grained access control, inheriting access, etc.) is quite a bit of effort. With Warrant, you can model anything from RBAC to fine-grained access control and everything in between.
- End-to-end SDK support. There are many authorization libraries out there, but all of them seem to forget about the frontend. Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
- The flexible access control modeling. Implementing a basic RBAC scheme isn't too difficult with a couple extra database tables, but going further than that (fine-grained access control, inheriting access, etc.) is quite a bit of effort. With Warrant, you can model anything from RBAC to fine-grained access control and everything in between.
- End-to-end SDK support. There are many authorization libraries out there, but all of them seem to forget about the frontend. Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
> Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
This actually sounds really cool. It’s always a pain recreating JWT and setting up security between the backend and frontend. Doing this as a framework and an api seems like a good approach. Thanks for sharing.
This actually sounds really cool. It’s always a pain recreating JWT and setting up security between the backend and frontend. Doing this as a framework and an api seems like a good approach. Thanks for sharing.
I think its a service that acts as your roles table. So your service would query warrant with a user and an action and it would return whether that's authorized? I'm also a bit confused why someone wouldn't use something like Ory[0] at any scale where modularizing this out was important.
[0] https://github.com/ory
[0] https://github.com/ory
That’s correct, Warrant would act as your authorization service, where you can store access rules for your system and check against them at runtime to protect access to your application. Roles are a common access control model, but you can model much more complex use-cases like fine-grained access control as well.
Sorry, w.r.t my second thought, how would this differ from something like Ory Keto[0] or Oath Keeper[1]?
[0] https://github.com/ory/keto
[1] https://github.com/ory/oathkeeper
[0] https://github.com/ory/keto
[1] https://github.com/ory/oathkeeper
Keto + Oathkeeper together seem to be similar to what Warrant provides. One of our main focuses is providing great developer experience. We're continuing to build out the tooling around this, so stay tuned!
I'm not associated with the company or product.
If you sell to a midmarket or enterprise customer base, they regularly need custom stuff.
eg group X of employees cannot see group 1 of customers' data. Or to use a more concrete example: US employees cannot see EU customer data because of GDPR. But it's never that simple: more fine grained, or with other exceptions.
This stuff took up way more eng time than I mentally budgeted; I could see a use case for a service.
If you sell to a midmarket or enterprise customer base, they regularly need custom stuff.
eg group X of employees cannot see group 1 of customers' data. Or to use a more concrete example: US employees cannot see EU customer data because of GDPR. But it's never that simple: more fine grained, or with other exceptions.
This stuff took up way more eng time than I mentally budgeted; I could see a use case for a service.
Thanks for the response. I agree! That's exactly what we saw first hand at previous roles. Access control usually starts simple, but quickly evolves in complexity.
(Full transparency: I'm CTO/cofounder of Oso, a series A startup building an open source framework for authorization)
Super interesting how many companies are building authorization systems based on Zanzibar suddenly! This is a bit of a shameless plug, but I just wrote a blog post earlier today talking through how to build Zanzibar from scratch in ~150 lines of code: https://news.ycombinator.com/item?id=28076549
Not many people talk about how Zanzibar requires you re-architect your application around authorization when you really don't need to do that at all. Any sufficiently powerful authorization framework can handle the same flexibility. If not more, since most Zanzibar implementations can't handle simple attribute-based controls (e.g. anyone can read a document if its public). Which means you'll end up implementing a bunch of authorization logic in your app anyway.
---
Edit to add: I realise in hindsight I got a bit too absorbed in thinking about the Zanzibar part to say congrats on the launch! It's awesome to see the space heating up, and love to see more focus on the developer experience :)
Super interesting how many companies are building authorization systems based on Zanzibar suddenly! This is a bit of a shameless plug, but I just wrote a blog post earlier today talking through how to build Zanzibar from scratch in ~150 lines of code: https://news.ycombinator.com/item?id=28076549
Not many people talk about how Zanzibar requires you re-architect your application around authorization when you really don't need to do that at all. Any sufficiently powerful authorization framework can handle the same flexibility. If not more, since most Zanzibar implementations can't handle simple attribute-based controls (e.g. anyone can read a document if its public). Which means you'll end up implementing a bunch of authorization logic in your app anyway.
---
Edit to add: I realise in hindsight I got a bit too absorbed in thinking about the Zanzibar part to say congrats on the launch! It's awesome to see the space heating up, and love to see more focus on the developer experience :)
Thanks for the response! It is interesting to see the surge in popularity of Zanzibar. Completely agree that Zanzibar itself isn't too difficult to implement (especially since Google published a paper on it). It does provide great flexibility though.
I don't agree with your point that it requires developers to re-architect their systems or that it doesn't handle attribute-based controls well. If anything, I think Zanzibar actually helps developers enforce the best authz practices in their system. This becomes increasingly helpful as an application changes or grows in complexity.
To be clear, Warrant isn't just a Zanzibar implementation. We're building Authz as a service with devxp as the central focus.
I don't agree with your point that it requires developers to re-architect their systems or that it doesn't handle attribute-based controls well. If anything, I think Zanzibar actually helps developers enforce the best authz practices in their system. This becomes increasingly helpful as an application changes or grows in complexity.
To be clear, Warrant isn't just a Zanzibar implementation. We're building Authz as a service with devxp as the central focus.
Yeah, to be clear I think the Zanzibar authorization model is great! Super helpful to think about authorization logic in terms of relationships.
To give a simple example of an attribute-based control that is tough with the service model: if you want to express "anybody can read a document if it's public", then you need to push that "public" field into the service. Every attribute that you want to use for authorization becomes something that you need to either move or synchronise into the service. Or you leave that logic in the application.
To give a simple example of an attribute-based control that is tough with the service model: if you want to express "anybody can read a document if it's public", then you need to push that "public" field into the service. Every attribute that you want to use for authorization becomes something that you need to either move or synchronise into the service. Or you leave that logic in the application.
What's the consistency model for operations against your API? When my backend grants a user access to some resource, will all subsequent permission checks immediately grant that access?
If not, how are user signups supposed to work? If I create a user and set up their permissions in Warrant, will my users' first-time experience consist of a permission denied error?
If not, how are user signups supposed to work? If I create a user and set up their permissions in Warrant, will my users' first-time experience consist of a permission denied error?
Updates to the API are immediately reflected in subsequent access requests, so new users who sign up in your system would immediately have the appropriate access rules
This is the right idea. Implementation is necessarily going to evolve, but this is the right problem to be solving and doing authz as a service is the right way to do it. I've hacked around on a related concept (different implementation, guided by UMA2, unique use cases, etc.) and it's one of those services that is just necessary and will adapt to SaaS well.
Will watch progress closely. Key business piece imo will be getting libraries and plugins out for enterprise development platforms, and possibly creating a private tenant concept. Can absolutely see why this was included in the batch.
Will watch progress closely. Key business piece imo will be getting libraries and plugins out for enterprise development platforms, and possibly creating a private tenant concept. Can absolutely see why this was included in the batch.
Thanks for the feedback! Libraries and integrations are definitely on our list and we're also thinking about private tenant/cloud deployments (although still early on that).
Great idea. I thought of making a startup area as well, we called it AaaS (AuthZ as a Service) .
Take the plunge: https://www.field-guide.unusual.vc/field-guide-enterprise/bu...
Working on something else now, but that's a good article.
Congratulations on the launch, Aditya and Karan.
Building SaaS from India (assuming that you eventually will) is always going to be advantageous [0] given the comparatively lower wages and access to a global client-base. Apart form that, in what ways does warrant differentiate itself from authzed.io, another YC-backed startup? I see that both these services are influenced by Zanzibar, but I am particularly curious if DevX is warrant's focus? If so, what might be the current competitors missing?
Thanks.
[0] Given the Indian SaaS ecosystem is up and running and there does not seem to be dearth of talent, community (https://archive.is/B5OHl) or capital (https://archive.is/ZXvzL).
Building SaaS from India (assuming that you eventually will) is always going to be advantageous [0] given the comparatively lower wages and access to a global client-base. Apart form that, in what ways does warrant differentiate itself from authzed.io, another YC-backed startup? I see that both these services are influenced by Zanzibar, but I am particularly curious if DevX is warrant's focus? If so, what might be the current competitors missing?
Thanks.
[0] Given the Indian SaaS ecosystem is up and running and there does not seem to be dearth of talent, community (https://archive.is/B5OHl) or capital (https://archive.is/ZXvzL).
Thanks! Although I'm not sure I fully understand your first point. Are you asking if we specifically plan to build/hire in India in the future (we're based in the US) or are you saying that in general, building SaaS in India is advantageous?
And yes, devxp is one of our main focus areas. After dealing with authz at prev small and big companies, we're building the components/infra/plugins we believe will save app developers time across their stack. And in terms of Zanzibar, like others, we think it's a very flexible approach to modeling permissions and access control, so we're basing parts of our implementation on it.
And yes, devxp is one of our main focus areas. After dealing with authz at prev small and big companies, we're building the components/infra/plugins we believe will save app developers time across their stack. And in terms of Zanzibar, like others, we think it's a very flexible approach to modeling permissions and access control, so we're basing parts of our implementation on it.
Thanks for the reply.
> ...we're building the components/infra/plugins we believe will save app developers time across their stack.
I ask because I have been keenly following authzed's progress, after walking away particularily impressed with their pricing (which is 1/10th of warrant's?).
> Are you asking if we specifically plan to build/hire in India in the future (we're based in the US)
I am postulating that warrant'd have a leg up on competition because I presume its founders would be more receiptable to building/hiring in India...
> ...we're building the components/infra/plugins we believe will save app developers time across their stack.
I ask because I have been keenly following authzed's progress, after walking away particularily impressed with their pricing (which is 1/10th of warrant's?).
> Are you asking if we specifically plan to build/hire in India in the future (we're based in the US)
I am postulating that warrant'd have a leg up on competition because I presume its founders would be more receiptable to building/hiring in India...
Hey! Thanks for the mention!
Authzed is focused on delivering all of the capabilities of Zanzibar (rewrites, consistency, scalability) in a consumable form to everyone outside of Google. We've started with Zanzibar and are iterating from there, rather than cherry-picking particular concepts from the paper.
You can checkout our post on "What is Zanzibar" to learn why you'd want the whole package: https://authzed.com/blog/what-is-zanzibar/
Congrats to Warrant! There's plenty of room for innovation in the developer UX for permissions, especially with frontend code.
Authzed is focused on delivering all of the capabilities of Zanzibar (rewrites, consistency, scalability) in a consumable form to everyone outside of Google. We've started with Zanzibar and are iterating from there, rather than cherry-picking particular concepts from the paper.
You can checkout our post on "What is Zanzibar" to learn why you'd want the whole package: https://authzed.com/blog/what-is-zanzibar/
Congrats to Warrant! There's plenty of room for innovation in the developer UX for permissions, especially with frontend code.
We are building Titipku (https://titipku.com/) which is "Instacart" for local markets in Indonesia, where we help households to buy daily groceries from nearby local markets in their residence areas. The Covid 19 has made people unable to buy their daily needs from local markets, meanwhile merchants in local markets are also suffering and need help to sell their goods. We solved this by helping to on board all merchants in every local market in our application, households can make an order in a few minutes, and there are personal shoppers who will go to the local market, buy the order and deliver to buyers. For example a household in Kelapa Gading Jakarta can make an order to buy many products from many merchants in Mandiri Market Kelapa Gading as one single order, then Titipku will assign the order to a personal shopper who will serve the order until delivery to the buyer instantly.within 1 hour. You can see an intro video here: https://www.youtube.com/watch?v=0b6SXH0BR-w. Happy to answer questions!
This is amazing. I just forward it to my SO and we probably will try it.
We've been shopping weekly at a supermarket groceries store, think like Giant, Hypermart, or Lulu Hypermarket. We realized even though the experience is fine, this is not ideal. There are million small merchants that rely on daily income to be able to feed their family, so my purchases could be significant for them.
We've been shopping weekly at a supermarket groceries store, think like Giant, Hypermart, or Lulu Hypermarket. We realized even though the experience is fine, this is not ideal. There are million small merchants that rely on daily income to be able to feed their family, so my purchases could be significant for them.
Thank you, Karim. We are very happy for your support. Please give us some feedback. Let me know the name of your family or college so we contact them and monitor their order.
I'm from Malaysia and I once tried to do something very similar. What makes this better than other services like Foodpanda, Grab, and HappyFresh? What does Titipku do better?
Also what's your policy on non-halal groceries in the app? One of the things that put me off was seeing pork and alcohol on the front page, which implies it might get mixed with halal deliveries. Titipku implies that it buys "anything".
Also what's your policy on non-halal groceries in the app? One of the things that put me off was seeing pork and alcohol on the front page, which implies it might get mixed with halal deliveries. Titipku implies that it buys "anything".
We have feature that customer can order many products from multiple merchants in the local market. This order is treated as one order.
We give the sign for customer to inform which products that labelled as non halal. Thanks
Good to see more Indonesian startups. I wish you the best of luck. I'm interested on how titipku would fare against behemoths such as goshop, sayurbox etc.
Thank you!! You will do our best for Indonesia's local markets.
Nice to see an Indonesian startup. It's like Jastip but for groceries. Interesting.
Thank you. We have special promo for Indonesian Independence Day. Kindly try it!!
We are Anta and Karthik of Inai (https://www.inai.io/), a platform for setting up and operating your payment stack. We let you offer local payment methods, support multiple business models (e-commerce, subscriptions , platforms) and localise the checkout experience by region of operation.
Setting up and maintaining a payment stack, especially if you operate in multiple regions, takes months of developer time. Most merchants set up their stacks ad hoc, leading to loss of revenue (e.g. if you don't display Apple Pay in a certain way at checkout, Apple will penalize; same for Paypal) and wasted admin time (multiple dashboards for refunds, coupons etc). Working with a single payment provider locks the merchant in, as customer data is vaulted with the Payment Service Provider (PSP) making switching difficult. Meanwhile customer payment methods are exploding with newer rails like BNPLs (Buy Now Pay Later), open banking, QR code based and even crypto emerging rapidly
Karthik and I previously ran a DTC fitness business. Tailoring the payment stack to each market that we expanded into was a big pain. We spent weeks on every payment integration and our payment stack was a mess. We were after all running a fitness business and not a payments one.
At Inai, we provide a single unified API that connects to multiple payment providers (Stripe, Braintree), alternate payment methods (wallets, BNPLs etc). We make it easy to launch into new markets and to keep your service agnostic of PSP. For B2B companies, we make it easy to allow your customers to send invoice links and accept payments across cards and ACH.
We plan to give merchants a IFTTT dashboard to set up custom business logic (e.g. show Klarna, SOFORT, and cards in Germany but cards, Paypal, and Apple Pay in US). Merchants can view all transactions across providers, and very shortly will be able to manage chargebacks, refunds, and coupons, and get analytics on transactions (e.g. success rates by card/PSP, insights on why transactions were declined).
Payment orchestration as a concept is not new, but medium sized merchants were not being served well with the existing solutions. We found that many merchants in this category had a knowledge gap with respect to payments and therefore needed someone to hand-hold and deliver outcomes for them, so fixing this is what we are focussed on.
We are building this product for merchants so if you have a use case that is currently not being served by our product, we would love to hear from you. Your problems and pain points will drive our roadmap.
Setting up and maintaining a payment stack, especially if you operate in multiple regions, takes months of developer time. Most merchants set up their stacks ad hoc, leading to loss of revenue (e.g. if you don't display Apple Pay in a certain way at checkout, Apple will penalize; same for Paypal) and wasted admin time (multiple dashboards for refunds, coupons etc). Working with a single payment provider locks the merchant in, as customer data is vaulted with the Payment Service Provider (PSP) making switching difficult. Meanwhile customer payment methods are exploding with newer rails like BNPLs (Buy Now Pay Later), open banking, QR code based and even crypto emerging rapidly
Karthik and I previously ran a DTC fitness business. Tailoring the payment stack to each market that we expanded into was a big pain. We spent weeks on every payment integration and our payment stack was a mess. We were after all running a fitness business and not a payments one.
At Inai, we provide a single unified API that connects to multiple payment providers (Stripe, Braintree), alternate payment methods (wallets, BNPLs etc). We make it easy to launch into new markets and to keep your service agnostic of PSP. For B2B companies, we make it easy to allow your customers to send invoice links and accept payments across cards and ACH.
We plan to give merchants a IFTTT dashboard to set up custom business logic (e.g. show Klarna, SOFORT, and cards in Germany but cards, Paypal, and Apple Pay in US). Merchants can view all transactions across providers, and very shortly will be able to manage chargebacks, refunds, and coupons, and get analytics on transactions (e.g. success rates by card/PSP, insights on why transactions were declined).
Payment orchestration as a concept is not new, but medium sized merchants were not being served well with the existing solutions. We found that many merchants in this category had a knowledge gap with respect to payments and therefore needed someone to hand-hold and deliver outcomes for them, so fixing this is what we are focussed on.
We are building this product for merchants so if you have a use case that is currently not being served by our product, we would love to hear from you. Your problems and pain points will drive our roadmap.
Hi, very interesting segment of the market!
How do you compare yourself to Spreedly? How would you compete with their offering?
I think these solutions are really neat, but I wonder how you can handle some edge cases which I think are really difficult. For example, let's say I want to use credit cards with Adyen. Now after a year of this, I have a lot of customers with their credit cards connected to my business via Inai so recurring payments go smoothly. Now, Stripe comes knocking and will give me a much better price on credit cards. Can I just switch the backend to start routing card payments to Stripe? Will all the customers need to re-enroll their credit cards when trying to pay now? If not, then I guess you're managing the card data on you side?
I think this and Spreedly are interesting, but I can imagine that for large companies, you want more control over your payments flow even than what's provided here, which is why when compared to Spreedly, we personally went with VGS and do the PSP routing in our own system.
IF my assumption about that is true, then that leaves you with the smaller merchant market. Of those users, I think just sticking with one of the reliable PSPs with global coverage (Stripe/Adyen) might be simpler.
How do you compare yourself to Spreedly? How would you compete with their offering?
I think these solutions are really neat, but I wonder how you can handle some edge cases which I think are really difficult. For example, let's say I want to use credit cards with Adyen. Now after a year of this, I have a lot of customers with their credit cards connected to my business via Inai so recurring payments go smoothly. Now, Stripe comes knocking and will give me a much better price on credit cards. Can I just switch the backend to start routing card payments to Stripe? Will all the customers need to re-enroll their credit cards when trying to pay now? If not, then I guess you're managing the card data on you side?
I think this and Spreedly are interesting, but I can imagine that for large companies, you want more control over your payments flow even than what's provided here, which is why when compared to Spreedly, we personally went with VGS and do the PSP routing in our own system.
IF my assumption about that is true, then that leaves you with the smaller merchant market. Of those users, I think just sticking with one of the reliable PSPs with global coverage (Stripe/Adyen) might be simpler.
Hey - thanks much for your question.
Specific to your use-case on subscriptions - we have decoupled the subscriptions software layer from the payment rails. So yes, we can do exactly what you mentioned - which is switching providers for subscriptions without customer friction. Traditional orchestration companies will allow you to vault the cards and reuse them for recurring payments - but would require you to manage the logic around subscriptions (in your case).
With inai, we allow businesses to manage their subscriptions and associated payment logic from within our dashboard.
Thanks for your edge cases! If you are doing PSP routing in your own system, how exactly VGS helped you with Payments automation?
Hi, Paul here - head of engineering at Primer.io. There are a lot of "payments orchestration" companies floating around, but we think of ourselves as an automation platform for payments - Similar to Zapier in many ways.
I previously worked for Braintree/PayPal where I worked closely with Spotify, Uber, Ticketmaster and many of PayPal's marquee merchants on their payments integrations and payments strategies. We think about these things in terms of end-to-end payment flows.
You're outlining a scenario in which another PSP may give you better pricing at some point down the line. So typically, you'd rip out the Adyen integration and then go about integrating Stripe.. and you'd also need to request that Adyen migrate raw payment information over to Stripe, and hope they'd pass along all the respective network transaction information as well as any 3DS/SCA data that has been stored to ensure you don't see a drop in auth rates, or need to re-authenticate with 3DS or request CVV information on subsequent payments (lots of friction, lots of drop-off).
And that's just for cards. Apple Pay and other mobile wallets now enable vaulting, as well as other payment methods such as PayPal, Klarna, etc.
So you see that the issue here is bad separation of concerns for engineers. You should have custody of your payment method data, and be able to decide when and where to process payments (or indeed, pass payments data to other, independent downstream services). With Primer, we've decoupled every single area of traditional payments acceptance, enabling you to connect any number of payments, and non payments specific services using drag-and-drop workflows.
In your case, you'd simply change this route on your workflow from Adyen to Stripe, and voila.. everything just works - even the checkout! You may decide to get more detailed than that. Over time, you'll discover some PSPs perform better than others, that you can improve conversion or reduce risk by introducing third-party fraud providers, that you can optimise for cost and reduce cross-border fees with more refined routing and conditions... the list is endless!
In that sense, we've designed something akin to a developer framework for payments. A unified way of integrating and reasoning about payments completely decoupled from any specific providers. There are tons, and tons of security, infrastructure, and payments specific considerations that need to be made when building an agnostic platform such as this and would be happy to take any questions you may have about it.
Not to cause a fuss, but the reason for my posting this here is inai "borrowed" their concept from us after they signed up for a Primer account under their previous business, and set about ripping off every part of our product from the website to the job board! (All since updated... partially.) It is what it is :/
But Primer is built by payments folks and engineers who have experienced first-hand the complexities of payments as companies scale, and I'd be super happy to answer any questions you might have on solving more complex use-cases.
I previously worked for Braintree/PayPal where I worked closely with Spotify, Uber, Ticketmaster and many of PayPal's marquee merchants on their payments integrations and payments strategies. We think about these things in terms of end-to-end payment flows.
You're outlining a scenario in which another PSP may give you better pricing at some point down the line. So typically, you'd rip out the Adyen integration and then go about integrating Stripe.. and you'd also need to request that Adyen migrate raw payment information over to Stripe, and hope they'd pass along all the respective network transaction information as well as any 3DS/SCA data that has been stored to ensure you don't see a drop in auth rates, or need to re-authenticate with 3DS or request CVV information on subsequent payments (lots of friction, lots of drop-off).
And that's just for cards. Apple Pay and other mobile wallets now enable vaulting, as well as other payment methods such as PayPal, Klarna, etc.
So you see that the issue here is bad separation of concerns for engineers. You should have custody of your payment method data, and be able to decide when and where to process payments (or indeed, pass payments data to other, independent downstream services). With Primer, we've decoupled every single area of traditional payments acceptance, enabling you to connect any number of payments, and non payments specific services using drag-and-drop workflows.
In your case, you'd simply change this route on your workflow from Adyen to Stripe, and voila.. everything just works - even the checkout! You may decide to get more detailed than that. Over time, you'll discover some PSPs perform better than others, that you can improve conversion or reduce risk by introducing third-party fraud providers, that you can optimise for cost and reduce cross-border fees with more refined routing and conditions... the list is endless!
In that sense, we've designed something akin to a developer framework for payments. A unified way of integrating and reasoning about payments completely decoupled from any specific providers. There are tons, and tons of security, infrastructure, and payments specific considerations that need to be made when building an agnostic platform such as this and would be happy to take any questions you may have about it.
Not to cause a fuss, but the reason for my posting this here is inai "borrowed" their concept from us after they signed up for a Primer account under their previous business, and set about ripping off every part of our product from the website to the job board! (All since updated... partially.) It is what it is :/
But Primer is built by payments folks and engineers who have experienced first-hand the complexities of payments as companies scale, and I'd be super happy to answer any questions you might have on solving more complex use-cases.
Hi Anta
I'm (among other things) a fintech consultant specializing in payments; my company primarily works with Stripe, sometimes with Adyen/Worldpay/Xsolla.
Like you said, payments orchestration is nothing new. What differentiates you from any other middleman in the field?
I'll give you one example as a test scenario: A current client of mine is a small business incorporated in the US, doing business in both the US and South Korea with $10/mo subscriptions. They want to offer native South Korean payment methods in SK such as KakaoPay and Samsung Pay. I've had to set them up with Smart2pay (Nuvei) because, after months of negotiations, Adyen wouldn't take a contract with them because they're too small a fish to care about. In the US, they offer Paypal and Stripe but their current gateway middleman (Uscreen) takes an obscene cut and doesn't offer good subscription management features to make up for it.
Their current payment stack is inconsistent, hard to manage, lacks lots of admin features and costs them more than it should. If you can do something for them, I'll be super impressed :) (Email in my profile!)
I'm (among other things) a fintech consultant specializing in payments; my company primarily works with Stripe, sometimes with Adyen/Worldpay/Xsolla.
Like you said, payments orchestration is nothing new. What differentiates you from any other middleman in the field?
I'll give you one example as a test scenario: A current client of mine is a small business incorporated in the US, doing business in both the US and South Korea with $10/mo subscriptions. They want to offer native South Korean payment methods in SK such as KakaoPay and Samsung Pay. I've had to set them up with Smart2pay (Nuvei) because, after months of negotiations, Adyen wouldn't take a contract with them because they're too small a fish to care about. In the US, they offer Paypal and Stripe but their current gateway middleman (Uscreen) takes an obscene cut and doesn't offer good subscription management features to make up for it.
Their current payment stack is inconsistent, hard to manage, lacks lots of admin features and costs them more than it should. If you can do something for them, I'll be super impressed :) (Email in my profile!)
Sounds great- emailing you :)
Is this like an aggregator of aggregators given that Stripe, Adyen already aggregate several payment providers? What's the long game here if someone like Stripe starts supporting every payment method?
Hi we're Nishant and Pranav of Nino Foods, which creates and operates cloud kitchen brands in India focused on the premium market. Food Delivery in India has an average order value (AOV) of 4$ vs the U.S which is >30$. This makes it hard to run a profitable food delivery business In India. Our brands target the customers in India that order food above 7$ - which accounts for 50% of industry revenues and a majority of industry profits. This segment has 2.5 times more profitability, and stickier customers with higher expectations.
We launched 11 months ago by acquiring a Pizza chain in Mumbai-Francesco's Pizzeria, which had closed 5 out of its 6 restaurant locations and was running on fumes because of covid. We acquired the 1 active location along with the brand rights and converted it to delivery only. We set up a new brand-Nino Burgers , mostly to prove to ourselves that we could build a successful food brand from scratch.
We use hyperlocal data like - unfulfilled search engine queries on delivery platforms, highest selling menu items in nearby restaurants and highest selling toppings - to drive menu and pricing decisions. In the last 11 months we've understood how to grow sales on delivery platforms and we have designed kitchen layout, operations and SOP's to improve metrics that drive visibility on them.
Contrary to the negative sentiment shared by lots of restaurants in India toward platforms because of their 25% take rate - we have a Pro-Swiggy/Zomato attitude . These platforms make 3 times more money on orders through us than via brands with lower average order values. This aligns our incentives with them and gives us access to better data to grow and lower commission rates. Nonetheless, We still do 20% of our business via our direct channel which helps us understand customer preferences deeper and track loyalty.
We want to build category leading brands in food. A person orders food delivery 5 times a month in India. Our aim is for 4 out of those 5 orders to be coming from one of our brands.
https://linktr.ee/ninofoods has our instagram pages and an ordering website. We'd love to hear any thoughts, feedback and curiosities!
We launched 11 months ago by acquiring a Pizza chain in Mumbai-Francesco's Pizzeria, which had closed 5 out of its 6 restaurant locations and was running on fumes because of covid. We acquired the 1 active location along with the brand rights and converted it to delivery only. We set up a new brand-Nino Burgers , mostly to prove to ourselves that we could build a successful food brand from scratch.
We use hyperlocal data like - unfulfilled search engine queries on delivery platforms, highest selling menu items in nearby restaurants and highest selling toppings - to drive menu and pricing decisions. In the last 11 months we've understood how to grow sales on delivery platforms and we have designed kitchen layout, operations and SOP's to improve metrics that drive visibility on them.
Contrary to the negative sentiment shared by lots of restaurants in India toward platforms because of their 25% take rate - we have a Pro-Swiggy/Zomato attitude . These platforms make 3 times more money on orders through us than via brands with lower average order values. This aligns our incentives with them and gives us access to better data to grow and lower commission rates. Nonetheless, We still do 20% of our business via our direct channel which helps us understand customer preferences deeper and track loyalty.
We want to build category leading brands in food. A person orders food delivery 5 times a month in India. Our aim is for 4 out of those 5 orders to be coming from one of our brands.
https://linktr.ee/ninofoods has our instagram pages and an ordering website. We'd love to hear any thoughts, feedback and curiosities!
Congrats on getting an actual business out of the ground!
A few comments :
- On your delivery website, the first step is to choose a city, but you operate just in mumbai, so I can just select mumbai. If you could remove this choice before you open in new cities, it will make the flow of ordering one step shorter. It will also allow you to better market your local brand as the wording could be : order a burger in mumbai, ....
- The pizza ordering page offer images of the items to order, the burger page does not. Is it a deliberate choice? When ordering food I generally don't choose from unknown shop with no picture (but it's maybe a cultural difference as I am not based in india).
- You are operating on top of platforms (Swiggy/Zoomato), that can decide to move into the black kitchen business. Your only edge against that seems to be your brand, what are you doing other black kitchen are not doing to ensure that your brand get strong enough?
A few comments :
- On your delivery website, the first step is to choose a city, but you operate just in mumbai, so I can just select mumbai. If you could remove this choice before you open in new cities, it will make the flow of ordering one step shorter. It will also allow you to better market your local brand as the wording could be : order a burger in mumbai, ....
- The pizza ordering page offer images of the items to order, the burger page does not. Is it a deliberate choice? When ordering food I generally don't choose from unknown shop with no picture (but it's maybe a cultural difference as I am not based in india).
- You are operating on top of platforms (Swiggy/Zoomato), that can decide to move into the black kitchen business. Your only edge against that seems to be your brand, what are you doing other black kitchen are not doing to ensure that your brand get strong enough?
-good point, the direct channel website we have is built using a third party service so its not customisable. The plan is to set up our own platform where we can fully customize the flow and sell food from all our brands in a single order in the near term. Right now focus is on creating the best food.
-nope youre right , pictures are crucial in driving purchases, we'll fix that.
-interestingly Swiggy already moved into the business 2 years ago via a service called "Swiggy Access" where they created their own brands based on data. But it didnt work and they shut down all locations to shift focus back to their core business -logistics. In the longer term we plan on building brands with strong enough customer repeat rates to drive traffic to our own app/website and creating offerings exclusively available on our direct channel to reduce platform dependance.
-nope youre right , pictures are crucial in driving purchases, we'll fix that.
-interestingly Swiggy already moved into the business 2 years ago via a service called "Swiggy Access" where they created their own brands based on data. But it didnt work and they shut down all locations to shift focus back to their core business -logistics. In the longer term we plan on building brands with strong enough customer repeat rates to drive traffic to our own app/website and creating offerings exclusively available on our direct channel to reduce platform dependance.
First off, congrats on your venture! as a foodie I'm elated.
I realize that you're trying to create your own brand, my concern is:
- if it's a brand that does all cuisines, it is going to attract people mainly because of the price point, and not uniqueness
- if the idea is to build multiple brands, one each for a specific type of food: a brand for Pizza, another for Biryani, etc., then scaling each is its own demon
please correct me if I'm not understanding it right.
On a side note,
> But it didnt work and they shut down all locations
Do you have any knowledge of why it didn't work? I have a few thoughts around this, and have discussed this with a friend who's a restaurateur, but would love to hear from you!
I realize that you're trying to create your own brand, my concern is:
- if it's a brand that does all cuisines, it is going to attract people mainly because of the price point, and not uniqueness
- if the idea is to build multiple brands, one each for a specific type of food: a brand for Pizza, another for Biryani, etc., then scaling each is its own demon
please correct me if I'm not understanding it right.
On a side note,
> But it didnt work and they shut down all locations
Do you have any knowledge of why it didn't work? I have a few thoughts around this, and have discussed this with a friend who's a restaurateur, but would love to hear from you!
-we're creating multiple brands -each with their own identity. The common thread is premium. Target customers are restricted to those in a 10km radius of a kitchen. Aim is to build customer wallet share by understanding our set of consumers well and serving food to them across different food missions - meal to go , family meal, light meal, cheat meal. Efficiency comes as we consolidate the supply chain and infra at scale
-they scaled too fast because it would not have moved the needle for a company of their size otherwise. and its difficult to build brands customers truly love if speed and scale is the main focus imo, we focus on depth first, then breadth. -would love you hear your views too
-they scaled too fast because it would not have moved the needle for a company of their size otherwise. and its difficult to build brands customers truly love if speed and scale is the main focus imo, we focus on depth first, then breadth. -would love you hear your views too
Not the guy you are replying too, but the strategy does seem to have parallels to D Mart growth strategy vs Big Bazaar(Future Retail) .
interesting thought!
Would you be willing to share how much you acquired the pizza business for?
was not a cash deal. We paid x% royalty out of revenues for a year and gave the founder a small piece of our new co
Very interesting. Would you also share how does one discover such opportunities? I presume there's no marketplace for these things. Do you have to be in the industry and rely mainly on network connections or are there other means?
entirely network driven for the ones with high conversion imo
We are Jan and Anahi of Perfekto (https://www.perfekto.mx/). We offer imperfect produce in Latin America, helping to reduce food waste as otherwise the food would be thrown away. We offer a subscription box, delivered to your doorstep.
We started with fruits and veggies as 54% of them are wasted in Latin America, mainly due to two reasons: strict industry standards around aesthetics (too ugly, too small, too big, bruised, etc.) and inefficient supply chains (supply and demand mismatch, several intermediaries, no cold chains etc.). Meanwhile 8-10% of global greenhouse gas emissions result from food waste, and food demand is growing significantly.
I was working for a Swiss FinTech in Mexico City, but was not happy. I wanted to build something with a positive, sustainable impact. The food waste problem popped into my mind because growing up in a Swiss farming village and having worked as a waiter during my studies, I saw the effort in producing food and the amount of food we waste daily. I also realized there were not many people addressing the problem in Latin America. Further research showed that more than 1/3 of food in the region is being wasted. During that process I met Anahí, who started her career at Unilever and the past few years at Uber, where she led Grocery and Cornershop initiatives. Her father is a citrus producer so she was confronted with the problem of food waste pretty much her entire life and also wanted to do something about it.
We buy fruits and veggies from producers that otherwise are difficult or impossible for them to sell - the only standard is that they have to be fresh. We thereby create a market for these 'overlooked' products. Producers are not even offering imperfect products anymore because they think there is no market for it. When we approach them wanting to buy imperfect products they are surprised and distrust us. It takes some time for them to open up. Meanwhile, at least in Latin America, many people don't seem to know that this problem even exists. They don't know that so much food is being wasted for stupid reasons like shape or size and it blows their mind.
By sourcing our products directly from producers we shorten the supply chain. We maintain a cool temperature, which leads to less waste. We only buy seasonal and local produce to be as sustainable as possible. Thanks to the subscription model, we can match supply and demand to avoid over-buying stock that ends up wasted. This allows us to optimize logistics. Logistics is definitely the most complex thing about our business--it affects us across the board. For now we think we have figured out a good model to grow, but it will be interesting to see what happens and what will change as we become bigger!
I was working for a Swiss FinTech in Mexico City, but was not happy. I wanted to build something with a positive, sustainable impact. The food waste problem popped into my mind because growing up in a Swiss farming village and having worked as a waiter during my studies, I saw the effort in producing food and the amount of food we waste daily. I also realized there were not many people addressing the problem in Latin America. Further research showed that more than 1/3 of food in the region is being wasted. During that process I met Anahí, who started her career at Unilever and the past few years at Uber, where she led Grocery and Cornershop initiatives. Her father is a citrus producer so she was confronted with the problem of food waste pretty much her entire life and also wanted to do something about it.
We buy fruits and veggies from producers that otherwise are difficult or impossible for them to sell - the only standard is that they have to be fresh. We thereby create a market for these 'overlooked' products. Producers are not even offering imperfect products anymore because they think there is no market for it. When we approach them wanting to buy imperfect products they are surprised and distrust us. It takes some time for them to open up. Meanwhile, at least in Latin America, many people don't seem to know that this problem even exists. They don't know that so much food is being wasted for stupid reasons like shape or size and it blows their mind.
By sourcing our products directly from producers we shorten the supply chain. We maintain a cool temperature, which leads to less waste. We only buy seasonal and local produce to be as sustainable as possible. Thanks to the subscription model, we can match supply and demand to avoid over-buying stock that ends up wasted. This allows us to optimize logistics. Logistics is definitely the most complex thing about our business--it affects us across the board. For now we think we have figured out a good model to grow, but it will be interesting to see what happens and what will change as we become bigger!
First off, congrats for tackling a problem like this!
I'm wondering if there isn't also a big opportunity in selling this imperfect produce to food factories? Consumers have to be on board with big/small/misshapen veggies, but if I'm buying a strawberry jam, where the strawberries were chopped up in a factory, then it really doesn't matter what shape they had originally. Frankly, I'm kinda surprised if an obvious optimization like that isn't already in place - let those who care about the shape pay more for the pretty ones, and let those who don't save by buying the rest. But I'm guessing the existing supply chains that you are bypassing just isn't very conducive to that sort of thing?
I'm wondering if there isn't also a big opportunity in selling this imperfect produce to food factories? Consumers have to be on board with big/small/misshapen veggies, but if I'm buying a strawberry jam, where the strawberries were chopped up in a factory, then it really doesn't matter what shape they had originally. Frankly, I'm kinda surprised if an obvious optimization like that isn't already in place - let those who care about the shape pay more for the pretty ones, and let those who don't save by buying the rest. But I'm guessing the existing supply chains that you are bypassing just isn't very conducive to that sort of thing?
> Frankly, I'm kinda surprised if an obvious optimization like that isn't already in place - let those who care about the shape pay more for the pretty ones, and let those who don't save by buying the rest.
Oh but that's exactly how it already works in existing supply chains: "imperfect" produce gets allocated quite well with food manufacturers, restaurants and food halls, or gets donated to foster homes, hospitals, etc. And many supermarkets do in fact stock up with "imperfect" produce.
"Reducing food waste" makes for good marketing. Except it's not that true.
Oh but that's exactly how it already works in existing supply chains: "imperfect" produce gets allocated quite well with food manufacturers, restaurants and food halls, or gets donated to foster homes, hospitals, etc. And many supermarkets do in fact stock up with "imperfect" produce.
"Reducing food waste" makes for good marketing. Except it's not that true.
Thanks, very good point. Important to take into consideration though that we are operating in Mexico and aiming for the LatAm market where this looks different than in the U.S. or Europe where most food waste indeed happens at the consumer level. Contrary in Latin America, 72% of food waste occurs prior to the consumption stage and specifically talking about fruits and veggies 54% are wasted due to supply chain inefficiencies and imperfections. And that already considers the fact that some imperfect produce ends up with food factories etc.
Let me shed some more light on the situation in Mexico (and most of LatAm):
Certainly, imperfect produce is allocated to some extent to food manufacturers, restaurants, etc. - but not enough - the scale of the problem is just too big. Surprisingly, we found that even certain restaurants that wanted to source from us because they don't care about imperfect produce, ended up asking for standards around size or colour.
Another example is what my co-founder's father still lives daily - his limes or mandarines are wasted because of being too small, too big, miscoloured.
In Mexico, we have not seen any supermarket stocking up imperfect produce, not even the very forward-thinking ones, but agree that luckily this is happening in the U.S., Europe and other places, hopefully soon also here.
When it comes to donations, unfortunately less than 5% of food waste ends up with food banks. There is still much to be done on that front too.
We also talked to several farmers who tell us they have imperfect produce on their farm which they do not even pick because they know it will be hard for them to sell and so it's not worth for them to pay someone to pick it.
What is true though is that to leave an important mark we need to get scale.
Let me shed some more light on the situation in Mexico (and most of LatAm):
Certainly, imperfect produce is allocated to some extent to food manufacturers, restaurants, etc. - but not enough - the scale of the problem is just too big. Surprisingly, we found that even certain restaurants that wanted to source from us because they don't care about imperfect produce, ended up asking for standards around size or colour.
Another example is what my co-founder's father still lives daily - his limes or mandarines are wasted because of being too small, too big, miscoloured.
In Mexico, we have not seen any supermarket stocking up imperfect produce, not even the very forward-thinking ones, but agree that luckily this is happening in the U.S., Europe and other places, hopefully soon also here.
When it comes to donations, unfortunately less than 5% of food waste ends up with food banks. There is still much to be done on that front too.
We also talked to several farmers who tell us they have imperfect produce on their farm which they do not even pick because they know it will be hard for them to sell and so it's not worth for them to pay someone to pick it.
What is true though is that to leave an important mark we need to get scale.
Thanks! And love your thinking. To be frank, we have not had the chance to get enough insights on how strong the 'beauty standards' are in food factories. We know from one local chips maker that they do get potatoes that are too small for them and hence cannot be made use of. So it depends on the type of food product we talk about, but defenitely the standards in the food factories are lower than in the B2C space. We actually think we can start creating products like jam ourselves with fruits that are so mistreated that we cannot even include them in our produce boxes.
That said, the problem is also a bit educational. 1) many people don't know that imperfect produce is actually very common (as in supermarkets only perfect fruits&veggies are displayed) 2) some people think that imperfect produce is imperfect as they were genetically modified (which is not the case).
And lastly, the problem is also due to the existing supply chains. Supermarkets do not only optimize for looks but also size, for logistical and pricing purposes.
Apart from that, we do not only tackle food waste by offering imperfect produce but further only offering seasonal produce and shortening the existing supply chains.
That said, the problem is also a bit educational. 1) many people don't know that imperfect produce is actually very common (as in supermarkets only perfect fruits&veggies are displayed) 2) some people think that imperfect produce is imperfect as they were genetically modified (which is not the case).
And lastly, the problem is also due to the existing supply chains. Supermarkets do not only optimize for looks but also size, for logistical and pricing purposes.
Apart from that, we do not only tackle food waste by offering imperfect produce but further only offering seasonal produce and shortening the existing supply chains.
Hi HN, we are Bruno and Guilherme of Jestor (https://jestor.com/). We make a no-code tool for COOs that need to scale complex offline operations such as hospitals, hotels and kitchens.
At our previous company, a software development business, most of our clients asked us to build in-house tools like an "easy to use Salesforce" or a "lighter SAP" that would reflect their internal processes. They were tired of paying high prices for 20-year-old enterprise software that was slow and expensive to adapt to their operations. They would usually also say something along the lines of: "I don't want to depend on you guys, I need something that my operations team can adapt themselves". All of them were using some combination of spreadsheets and SAP/Salesforce, and were not happy. We decided to develop software to empower them to build their own tools for operations, thus killing our previous business.
We achieve this by providing essential functionality without code, and enabling more customized behaviors to be quickly implemented with basic scripting ("low-code"). We give operations teams a way of using relational databases, setting up permissioning rules, and creating dashboards, forms, tasks and automations. Low-code allows for customized behaviors and integrations such as customized UIs, which allows for applications to be run on top of our platform. Proptech companies are using Jestor to manage room cleaning operations (cleaners have a Jestor app on their phones and receive information about where they need to clean), and foodtech companies are using it for managing warehouses and logistics.
Most of our clients have field operations, like when a doctor visits a patient in their home, so everything we build is designed thinking of mobile use. For example, you can create no-code automations straight from your phone. Another thing that's really important is the ability to connect any data in your company, so you can choose to integrate data from multiple teams in Jestor.
We never liked the pay-per-seats pricing model, so in Jestor, so we only charge based on usage. We believe it's much fairer to pay according to the value we generate for the user, instead of their "team size". Also, the more people using Jestor the better it gets. We're very pumped to be here and looking forward to hear what you think! Please leave us your feedback, including criticism so we can improve!
At our previous company, a software development business, most of our clients asked us to build in-house tools like an "easy to use Salesforce" or a "lighter SAP" that would reflect their internal processes. They were tired of paying high prices for 20-year-old enterprise software that was slow and expensive to adapt to their operations. They would usually also say something along the lines of: "I don't want to depend on you guys, I need something that my operations team can adapt themselves". All of them were using some combination of spreadsheets and SAP/Salesforce, and were not happy. We decided to develop software to empower them to build their own tools for operations, thus killing our previous business.
We achieve this by providing essential functionality without code, and enabling more customized behaviors to be quickly implemented with basic scripting ("low-code"). We give operations teams a way of using relational databases, setting up permissioning rules, and creating dashboards, forms, tasks and automations. Low-code allows for customized behaviors and integrations such as customized UIs, which allows for applications to be run on top of our platform. Proptech companies are using Jestor to manage room cleaning operations (cleaners have a Jestor app on their phones and receive information about where they need to clean), and foodtech companies are using it for managing warehouses and logistics.
Most of our clients have field operations, like when a doctor visits a patient in their home, so everything we build is designed thinking of mobile use. For example, you can create no-code automations straight from your phone. Another thing that's really important is the ability to connect any data in your company, so you can choose to integrate data from multiple teams in Jestor.
We never liked the pay-per-seats pricing model, so in Jestor, so we only charge based on usage. We believe it's much fairer to pay according to the value we generate for the user, instead of their "team size". Also, the more people using Jestor the better it gets. We're very pumped to be here and looking forward to hear what you think! Please leave us your feedback, including criticism so we can improve!
Jestor looks great!
I hope you guys don't wait for ages until you put a heavy focus on product performance. Notion waited way too long with this and it was a great turn off to adopt the product. I've just tried out your project management template and it already feels slow. Please think early about query optimizations and caching on client & server-side. It a major competitor advantage from UX perspective.
Performance is extremely important. I say that because we use Jestor every day here, and if it's a bit slow we immediately try to understand why and how to make it faster. About templates, did you use it straight from the website or by installing into an account? I'm asking so I can check with the team and solve it asap!
I was installing it from the website just by clicking on the template. The installation was not what bothered me but the overall responsiveness and loading time. I’m based in Berlin, might have been the roundtrip time.
I believe the distance wouldn't affect the speed, but we'll check. Thanks for the feedback!
How do you differ from retool?
There are some core differences:
1. You can connect everything in Jestor. All your tools will be connected, instead of building lots of stand alone applications for each team/problem.
2. Jestor provides database functionalities, so you don’t need 3rd party services to store your data and link it to processes within the platform.
3. Our focus is no-code and non-technical teams, whereas Retool is closer to a low-code tool for engineers.
1. You can connect everything in Jestor. All your tools will be connected, instead of building lots of stand alone applications for each team/problem.
2. Jestor provides database functionalities, so you don’t need 3rd party services to store your data and link it to processes within the platform.
3. Our focus is no-code and non-technical teams, whereas Retool is closer to a low-code tool for engineers.
How do you differ from Airtable?
The main difference is scalability. Jestor is useful for companies once they grow, when tools for teams aren't suitable anymore.
We've built the product for hundreds of simultaneous users. There are 3 features that enable it: 1. Connect any table. You aren't limited by Workspaces. 2. Advanced Permissioning Tools. You can do it at the variable level, creating unlimited number of profiles. 3. Unlimited number of records, tables, dashboards, automations and users. They will consume actions, but there is no real limitation.
We've built the product for hundreds of simultaneous users. There are 3 features that enable it: 1. Connect any table. You aren't limited by Workspaces. 2. Advanced Permissioning Tools. You can do it at the variable level, creating unlimited number of profiles. 3. Unlimited number of records, tables, dashboards, automations and users. They will consume actions, but there is no real limitation.
[deleted]
Where did the focus on the “complex offline operations” niche came from? Interested to understand the product-market fit iteration process.
Also, congrats on the solid product. Keep up with the great work!
Also, congrats on the solid product. Keep up with the great work!
We struggled a lot to realize that complex offline operations are a much better fit for us. In the beginning we're trying to help "Any company with any problem", and we ended up building nothing for no one. That’s when we saw that our clients with really tough operational problems were extracting great value from all the features we offer. We saw this fit had two parts: the operations being complex and them being offline. The reason we focus on complex operations is because easy problems don't actually need a tool. For a small company without ops problems, spreadsheets or paper sheets will usually do the job. The offline part is because we built Jestor to run on any mobile device from day 1 (as any modern application should). And "real world problems' need to have the data on the field, not only on computers.
I may just be unfamiliar with the lingo, but I believe one of the items in the "For operations" drop-down list may contain a spelling error/typo. The list item currently reads "Heathtech", but the page it leads to reads "Healthtech".
You're correct! It was a typo and we now fixed it, thanks!!
Love the room cleaning operations example! Would have never thought of that operation use case for a no-code tool. Congrats Bruno and Jestor!
I love the cleaning example because it's something that's not considered "sexy", but that several hospitality businesses need to solve. Most tools want to only help with sexy topics like "movie production", "project management", etc. In my view, there are lot's of "non-sexy problems" that need to be addressed.
Nice idea...actually it will help many companies to transform their business process.
Thanks!
Congrats BannaT!
Hello HN! We are Antonio, Felipe, Joaquin and Francois, founders of Chipax (https://www.chipax.com/). We are helping SMBs (Small and Medium Businesses) in Latin America handle their finances. Chipax is self-serve online software that works with real-time data collection from the IRS and banks. We all know how painful and time consuming it is to manage finances and keep payables and receivables up to date. So we are shortening this gap with technology.
We got started in 2015 when our friend's business was about to go bankrupt. He asked us for help. Antonio used spreadsheets to figure what was really happening; their finances were a mess. These spreadsheets did the work, but they quickly became really hard to maintain and existing software solutions made the problem even worse.
We turned those spreadsheets into a web app to make it easier to work with. We shared the web app with some friends and then we realized this was a very common problem among SMBs, so we decided to found Chipax. Right now, we have >1000 paying customers between Chile and Mexico.
We focus on cash flow, the heart of the SMB. We sync invoices and bills, tax and bank records so you can reconcile and get AR and AP reports accurately faster. We automatically categorize invoices and bills to get simple yet powerful P&L reports to track company or project numbers. We automate reporting on what’s most important: cash flow, income statement, debts payable, etc. Our customers are not looking for complex solutions, robust AI models or overly advanced technologies. They simply want to know how their business is doing and have peace of mind to operate it.
We are very excited to be at this point, we have been reading HN for years. We’d love to speak to any of you that are curious about what we’re doing or if you have any ideas/challenges for us!
We got started in 2015 when our friend's business was about to go bankrupt. He asked us for help. Antonio used spreadsheets to figure what was really happening; their finances were a mess. These spreadsheets did the work, but they quickly became really hard to maintain and existing software solutions made the problem even worse.
We turned those spreadsheets into a web app to make it easier to work with. We shared the web app with some friends and then we realized this was a very common problem among SMBs, so we decided to found Chipax. Right now, we have >1000 paying customers between Chile and Mexico.
We focus on cash flow, the heart of the SMB. We sync invoices and bills, tax and bank records so you can reconcile and get AR and AP reports accurately faster. We automatically categorize invoices and bills to get simple yet powerful P&L reports to track company or project numbers. We automate reporting on what’s most important: cash flow, income statement, debts payable, etc. Our customers are not looking for complex solutions, robust AI models or overly advanced technologies. They simply want to know how their business is doing and have peace of mind to operate it.
We are very excited to be at this point, we have been reading HN for years. We’d love to speak to any of you that are curious about what we’re doing or if you have any ideas/challenges for us!
Congrats folks! With that much data you'll be able to build a great financial health profile of your customers. Are you planning to offer loans?
Viva Chipax!
Viva Chipax!
Hi! Yes we are planning on it :)
How did you worked around SII anti-API in order to get invoice data?
Congrats on your launch. May I check what is the best email contact to say hi to the tech founder?
Very cool!
We are Ali and Omair of Abhi (http://abhi.com.pk/). We are a financial wellness platform in Pakistan, focusing on providing early wage access to the salaried class.
Most employees in Pakistan live paycheck to paycheck, not having savings for emergencies or random bills. Many pay their bills late, as payroll disbursement often does not coincide with bill cycles, incurring hefty payment fees. Fewer than 20% of the population have access to formal credit; banks are stringent in their underwriting and have not been focused on consumer lending due to high returns on treasury investments. In a population of 220M, consumer finance products have a total value of less than $3.5B. Meanwhile the total value of monthly payroll processed in Pakistan is between $6B and $8B. Without access to credit, people turn to friends and family, try to get advances from their employer, or resort to loan sharks.
The idea for Abhi came from first hand experience of constantly being asked for money by friends and family and speaking to companies on how often they have seen requests for salary advances. We also have seen how it takes over 45 days to get a loan from a bank or get approved for a credit card. My cofounder Omair, who was working at Morgan Stanley, had also been studying the early wage access model around the world and the uptake it had in emerging markets. After running a small pilot with 400 employees, we decided to work on a B2B2C model to provide advances to consumers via their employers to reduce delinquency risk.
We partner with employers to offer financial well-being benefits that improve retention, productivity and employee engagement. Our mission is to help millions of people across Pakistan live healthier, happier financial lives. We do this by offering: access to their salary as it is earned; affordable advances; and engaging financial education. In surveys we have found employees using these funds for utility bills, home maintenance, fixing their vehicles, medical expenses, and weddings.
We provide instant access to earned wages to all employees of any company that has signed on with us, without the need for any documentation. We allow this through 4 touch points: a mobile app, 2 way SMS, WhatsApp, and a web portal. The funds get sent to the employee within a minute, to their existing payroll account held in any bank or mobile wallet in Pakistan. We also provide advances when needed, for which we charge a flat 2% transaction fee. These are collected on the next payroll, eliminating late fees and loan shark interest rates.
Most employees in Pakistan live paycheck to paycheck, not having savings for emergencies or random bills. Many pay their bills late, as payroll disbursement often does not coincide with bill cycles, incurring hefty payment fees. Fewer than 20% of the population have access to formal credit; banks are stringent in their underwriting and have not been focused on consumer lending due to high returns on treasury investments. In a population of 220M, consumer finance products have a total value of less than $3.5B. Meanwhile the total value of monthly payroll processed in Pakistan is between $6B and $8B. Without access to credit, people turn to friends and family, try to get advances from their employer, or resort to loan sharks.
The idea for Abhi came from first hand experience of constantly being asked for money by friends and family and speaking to companies on how often they have seen requests for salary advances. We also have seen how it takes over 45 days to get a loan from a bank or get approved for a credit card. My cofounder Omair, who was working at Morgan Stanley, had also been studying the early wage access model around the world and the uptake it had in emerging markets. After running a small pilot with 400 employees, we decided to work on a B2B2C model to provide advances to consumers via their employers to reduce delinquency risk.
We partner with employers to offer financial well-being benefits that improve retention, productivity and employee engagement. Our mission is to help millions of people across Pakistan live healthier, happier financial lives. We do this by offering: access to their salary as it is earned; affordable advances; and engaging financial education. In surveys we have found employees using these funds for utility bills, home maintenance, fixing their vehicles, medical expenses, and weddings.
We provide instant access to earned wages to all employees of any company that has signed on with us, without the need for any documentation. We allow this through 4 touch points: a mobile app, 2 way SMS, WhatsApp, and a web portal. The funds get sent to the employee within a minute, to their existing payroll account held in any bank or mobile wallet in Pakistan. We also provide advances when needed, for which we charge a flat 2% transaction fee. These are collected on the next payroll, eliminating late fees and loan shark interest rates.
Out of curiosity, does your revenue stay in Pakistan, or do you transfer it to a bank in the USA or elsewhere? I find it interesting I can use Wise to send money to Pakistan, but not from Pakistan. Just wondering if y’all have a similar challenge and/or how your deal with it.
Yes the revenue stays in Pakistan
There are restrictions on outward remittance from Pakistan except for special cases.A large remittance from a company account requires permission from the central bank. Hope this answers your question.
How do you make money? Models I've seen here are all essentially riba (interest).
Have you looked into sharia compliance, I would say it's necessary for your market.
Have you looked into sharia compliance, I would say it's necessary for your market.
We charge a 2% transaction fee of the amount of advance requested.
Yes we are a Shariah compliant product.
Very happy to see a startup from Pakistan, here! Best of luck to Abhi!
However, how many employers have signed up with you? What kind of salary ranges are you targeting?
However, how many employers have signed up with you? What kind of salary ranges are you targeting?
Thanks. We currently have access to an employee base of over 200,000 from the MoUs we have signed. We are currently piloting so will know shortly in what salary range the product uptake is highest. However we feel that the product will be most useful for those who are earning between PKR 25000- PKR 100,000/-.
congrats and best of luck! really happy to see pakistani startups getting in through yc.
Couple of questions:
Some amount of businesses in Pakistan are known to delay paying out wages too. Do you intend to deal with this problem?
It's hard to gather ground truth data in Pakistan. How did you go about gathering/verifying data?
Couple of questions:
Some amount of businesses in Pakistan are known to delay paying out wages too. Do you intend to deal with this problem?
It's hard to gather ground truth data in Pakistan. How did you go about gathering/verifying data?
Thanks. Yes we do intent to provide interim payroll financing to companies who have delays in paying wages. However this is based on us running a risk assessment of the companies who we provide this service.
We are working on a B2B2C model so we gather information from the employer. Further we run a title fetch on the account number provided by the employer to make sure that the account number pertains to the employee whose data has been provided by their employer. Leveraging the existing financial infrastructure in Pakistan allows us to reduce the amount of data gathering and verifications on the customers we service.
We are working on a B2B2C model so we gather information from the employer. Further we run a title fetch on the account number provided by the employer to make sure that the account number pertains to the employee whose data has been provided by their employer. Leveraging the existing financial infrastructure in Pakistan allows us to reduce the amount of data gathering and verifications on the customers we service.
@dang - I like this title structure better (instead of listing the companies in the title)
@dang, I very much agree. I think there needs to be less companies per batch though.
[deleted]
There are 9 startups in this thread. The initial order is random:
GamerPay (YC S21) - Scam-free marketplace for gaming skins and assets - https://news.ycombinator.com/item?id=28073552
Warrant (YC S21) - APIs for authorization and access control - https://news.ycombinator.com/item?id=28073557
Abhi (YC S21) - Pakistani fintech focused on Early Wage Access - https://news.ycombinator.com/item?id=28073555
Perfekto (YC S21) - Imperfect produce in Latin America - https://news.ycombinator.com/item?id=28073551
Chipax (YC S21) - Quickbooks for Latin America - https://news.ycombinator.com/item?id=28073556
Inai (YC S21) - Segment for global payments - https://news.ycombinator.com/item?id=28073554
Titipku (YC S21) - Instacart for Indonesia - https://news.ycombinator.com/item?id=28073549
Jestor (YC S21) - Tool-builder for COOs - https://news.ycombinator.com/item?id=28073550
Nino Foods (YC S21) - Cloud Kitchens in India - https://news.ycombinator.com/item?id=28073553