[HN Gopher] Launch YC S21: Meet the Batch, Thread #4
___________________________________________________________________
Launch YC S21: Meet the Batch, Thread #4
Here's the fourth "Meet the Batch" thread - previous one was
https://news.ycombinator.com/item?id=28049500. I've given in on
titles (per https://news.ycombinator.com/item?id=28049881 and
sundry others). 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
Author : dang
Score : 90 points
Date : 2021-08-05 13:37 UTC (9 hours ago)
| ongtektjan wrote:
| 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!
| karimf wrote:
| 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.
| ongtektjan wrote:
| 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.
| langitbiru wrote:
| Nice to see an Indonesian startup. It's like Jastip but for
| groceries. Interesting.
| brunobannach wrote:
| 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!
| twojacobtwo wrote:
| 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".
| brunobannach wrote:
| You're correct! It was a typo and we now fixed it, thanks!!
| rescbr wrote:
| Congrats BannaT!
| jedberg wrote:
| How do you differ from retool?
| brunobannach wrote:
| 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.
| aviggiano wrote:
| Awesome! Keep up the good work
| brunobannach wrote:
| Thanks!
| erickcoser wrote:
| 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!
| brunobannach wrote:
| 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.
| dtran wrote:
| Love the room cleaning operations example! Would have never
| thought of that operation use case for a no-code tool. Congrats
| Bruno and Jestor!
| brunobannach wrote:
| 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.
| philippz wrote:
| 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.
| brunobannach wrote:
| 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!
| jheinvirta wrote:
| 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 Anahi, 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!
| m12k wrote:
| 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?
| jheinvirta wrote:
| 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.
| capocannoniere wrote:
| > 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.
| jheinvirta wrote:
| 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.
| martinlykkesuhr wrote:
| 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!
| telesilla wrote:
| I'd love to see this made available to the Spanish market next,
| will follow and see how you do.
| martinlykkesuhr wrote:
| You can actually use it in Spain, Portugal, Brazil and more.
| However you have to live with it being in English for now
| ibaikov wrote:
| But this is against TOS, isn't it?
| devrand wrote:
| 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
| martinlykkesuhr wrote:
| No it is not
| Nadya wrote:
| 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.
| ibaikov wrote:
| 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.
| martinlykkesuhr wrote:
| It is not against valves terms of service. They actually
| embrace the developement community around steam and their
| games
| lamroger wrote:
| V cool. Is there a way to publicly verify a transaction went
| through? Or they send a screenshot?
| martinlykkesuhr wrote:
| 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
| pacoWebConsult wrote:
| I assume this is where the integration with Steam comes into
| play. Checking the seller's inventory and the buyer's
| inventory
| martinlykkesuhr wrote:
| Correct
| xmaayy wrote:
| 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
| martinlykkesuhr wrote:
| 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.
| hamhamed wrote:
| 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?
| martinlykkesuhr wrote:
| 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
| FanaHOVA wrote:
| What do you think is wrong with existing solutions like OPSkins
| (RIP, played themselves), Bitskins, etc?
| w-ll wrote:
| Is it not possible to sell being a US user? Cant get past
| "Payout & account information". Revoked my key for the current.
| dinkleberg wrote:
| 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!
| martinlykkesuhr wrote:
| Thanks a lot, and I truly agree.
| devrand wrote:
| 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
| nishantnino wrote:
| 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!
| pierre wrote:
| 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?
| nishantnino wrote:
| -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.
| abhishekbasu wrote:
| 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!
| nishantnino wrote:
| -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
| anta81 wrote:
| 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.
| jsumrall wrote:
| 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.
| primerapi wrote:
| 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.
| anta81 wrote:
| 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.
| scrollaway wrote:
| 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!)
| anta81 wrote:
| Sounds great- emailing you :)
| aladhubhai wrote:
| 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.
| asukhwani wrote:
| Congrats on the launch guys. This is a real need!
| aladhubhai wrote:
| Thanks
| shayankh wrote:
| congrats! and best of luck!
| WasimBhai wrote:
| 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?
| aladhubhai wrote:
| 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/-.
| wizwit999 wrote:
| 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.
| aladhubhai wrote:
| We charge a 2% transaction fee of the amount of advance
| requested. Yes we are a Shariah compliant product.
| rorykoehler wrote:
| Using this model you can get better returns than payday loans
| get without the predatory aspect.
| shahryart76 wrote:
| 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?
| aladhubhai wrote:
| 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.
| Felipe_Urzua wrote:
| 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!
| jlhonora wrote:
| 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!
| Felipe_Urzua wrote:
| Hi! Yes we are planning on it :)
| jsmithfl wrote:
| Very cool!
| kkajla wrote:
| 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.
| samjs wrote:
| (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 :)
| kkajla wrote:
| 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.
| samjs wrote:
| 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.
| wizwit999 wrote:
| Great idea. I thought of making a startup area as well, we
| called it AaaS (AuthZ as a Service) .
| ignoramous wrote:
| Take the plunge: https://www.field-guide.unusual.vc/field-
| guide-enterprise/bu...
| wizwit999 wrote:
| Working on something else now, but that's a good article.
| sk55 wrote:
| Do you plan to create an SDK for Ruby apps any time soon?
| kkajla wrote:
| Yes, we plan to have a Ruby SDK soon!
| ezekg wrote:
| 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. :)
| akajla wrote:
| 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! (aditya@warrant.dev)
| samjs wrote:
| 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/
| ezekg wrote:
| 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?
| samjs wrote:
| 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.
| edgyquant wrote:
| 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?
| xmaayy wrote:
| 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
| kkajla wrote:
| 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.
| xmaayy wrote:
| 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
| kkajla wrote:
| 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!
| kkajla wrote:
| 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.
| brap wrote:
| This is neat, and I've given this idea some thought in the
| past. Glad to see it!
| akajla wrote:
| Thanks!
| motohagiography wrote:
| 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.
| akajla wrote:
| 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).
| ucarion wrote:
| 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?
| kkajla wrote:
| 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
| ignoramous wrote:
| 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).
| ignoramous wrote:
| * https://authzed.com/
| jzelinskie wrote:
| 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.
| akajla wrote:
| 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.
| ignoramous wrote:
| 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...
| mritchie712 wrote:
| @dang - I like this title structure better (instead of listing
| the companies in the title)
| Operyl wrote:
| @dang, I very much agree. I think there needs to be less
| companies per batch though.
| [deleted]
___________________________________________________________________
(page generated 2021-08-05 23:00 UTC)