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
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!
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
[0] https://skinbaron.de/en
Digital reskins of knives in CSGO sell for $200+ Euros?
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?
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.
> 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
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.
Edit: and I just saw the pricing... 1k API calls a month? I'd quite literally hit that in minutes. :)
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! (aditya@warrant.dev)
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/
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
- 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.
[0] https://github.com/ory
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.
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 :)
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.
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?
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.
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).
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.
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'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.
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".
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.
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.
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'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!)
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!
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?
-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.
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'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?
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.
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.
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!
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.
Also, congrats on the solid product. Keep up with the great work!
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!
Viva Chipax!