asommer12's comments

Kable.io | Lead Engineer | Remote / USA | Full-time

Kable (YC W22) is the all-in-one toolkit for API companies. We build usage-based billing tools, embeddable dashboards, and product analytics for businesses building API products. We were part of Y Combinator last year (W22) and are looking for a Lead/Principal Engineer to join our team. Learn more at https://www.ycombinator.com/companies/kable/jobs.

Stack: Node, Typescript, Nest, Postgres, Kafka, Redis, Clickhouse

You: You love to build. You ask great questions. You are a team player. You are passionate. You're an engineer at heart, but you have some product manager in you too. You have a strong sense of how things should be done, and you don't hesitate to speak your mind. You are a 10x engineer, capable of getting more done than others and in a fraction of the time. You want to be a part of something great.

Apply: Email contact AT kable DOT io with a bit of information about yourself and let's chat.

Awesome product, awesome team!

[email protected] -- looking forward to chatting!

Stripe is great for payments, but they don’t make usage data super useful for data purposes — their primary use case is payments.

If you want access to your data for other business purposes - stakeholder data, embedded dashboards, alerts and notifications about usage, etc - then you’ll want a system more purpose-built for usage data than Stripe.

Check out https://kable.io. Kable is purpose built as a data and billing solution, where your data is available for purposes ancillary to payments.

[Disclaimer: I am a Kable founder, but what you’re describing is precisely what we’re built for. If you’d like to chat, either about Kable or about your design in general to build this in-house, I’d be happy to.]

Kable (YC W22) | Founding Engineer | Remote / US | Full-time | https://kable.io

--

Kable is building the all-in-one toolkit for API companies.

The world of software is changing. Subscription billing has given way to usage-based pricing, and API-first businesses are one of the fastest-growing segments in SaaS. Yet still most API businesses reinvent the wheel, stitching together gateways, usage data infrastructure, customer-facing dashboards, and payments.

Kable is a drop-in solution that handles everything from API security to usage-metering to customer-facing dashboards to processing customer invoices.

We're a small team of two in search of two additional Founding Engineers to join us. We're a highly-collaborative Remote-first team, well-funded by leading investors (Y Combinator and Matrix Partners).

Want to join us? Email me at [email protected] and let's chat.

This company/team distinction describes what we're looking for next in our implementation :)

Also, hey, I'm Adam, a very happy customer of PropelAuth at Kable.io. Andrew is an incredibly responsive founder, who has been a great partner in the launch of our own B2B business. High recommend from me -- PropelAuth rules

Our Test environment offers all of the functionality that our Live environment offers. You can get the entire Kable experience in the Test environment without registering a credit card. Only when you're ready to deploy Kable to your Live production environment do we require a payment method.

The goal here is definitely not a lock-in strategy. Our lack of clear pricing is simply the nature of being a brand new company who hasn't yet had sufficient time to work with customers to solidify the right price point. As we iron out our business model we'll absolutely make pricing more transparent on our site.

Of course! Our mission is to support developers building great products. Our goal is to help you grow, not hold you prisoner

We don't currently have any customers using Kable and GraphQL together. To be totally honest, I'm not a GraphQL expert, and I don't want to give you any false information, so unfortunately no, I don't have an example for you.

Kable can be accessed through our Node and Python libraries (more languages on the way) or over HTTPS REST API. I will have to defer to your design sense about the best way to leverage these technologies with a GraphQL API today.

Amazing idea, and actually something we're actively developing.

Soon you'll be able to connect Kable to any of your other data sources through Segment. Then, if your application is hooked up to services like Zapier, Amplitude, Mixpanel, etc, you'll be able to funnel data into Kable for billing purposes with no additional code.

Our goal here is to make it super easy to use Kable for billing no matter what your existing stack looks like

Thanks for the report!

That page is actually hosted by one of our partners, PropelAuth, who manages end user authentication for access our dashboard. (End user login wasn't core to our business at Kable, so we found a partner who could manage this for us.)

Highly recommend PropelAuth for anyone looking for user authentication, they've been an amazing partner!

Great feedback, thank you. From what I can gather, the biggest differences between Kable and Saasify are the target market and core focus. Where Saasify is focused on micro SaaS projects, Kable is aimed at helping the growing population of API-first businesses. And from a core focus perspective, where Saasify is focused on a wide range of developer needs (user accounts, marketing sites, documentation, etc), Kable is focused on the core elements of an API business: authentication, metrics, and billing. But there's definitely a good amount of similarity here, and I love to meet folks building in a similar space.

This comment encapsulates the inspiration behind Kable beautifully.

Developers I've spoken with have struggled to get up and running with AWS API Gateway or GCP Endpoints. They each had plans to evolve their pricing model based on business-specific metrics (like monthly active users, transactions processed, or requests to specific APIs), and they weren't able to get the per-contract or per-endpoint pricing flexibility out of these offerings that they wanted.

Kable's greatest strength is its usage metering and billing. Not every developer is going to need to outsource their entire API gateway, and that's alright. In the early days, this does help get to market faster. At scale, though, when billing becomes more and more complex, is where Kable's greatest strengths in billing shine.

The truth is that we're still iterating on our pricing model which is why it's somewhat vague on our website. We offer a few different pricing tiers that range from Free to $200/month to $800/month depending on your revenue and usage of the platform before Enterprise. If you handle very heavy traffic (millions of events recorded daily), we'll help build a pricing plan that makes sense for your business.

There are a variety of different storage formats behind the curtain at Kable. Some things (like stored invoices) are trivial to export. Others (like full request histories) might be a bit more complicated. That said, we never want to lock you in.

We will always support customers who need to export data out of Kable into another system.

Hey, glad to hear it!

You're actually not the first person who's asked for a Rust SDK. This is something that is already in our plans for the near future.

In the meantime, all of Kable can be accessed via HTTPS REST endpoints. I wouldn't recommend using Kable for authentication over REST due to the potential latency issues it could cause for your API. But all of our functionality around pricing, metering, billing, and invoicing can be accessed directly, even without a Rust library.

Check out our documentation for a closer look at the REST API. Would be happy to chat some more over email to help you get started until our Rust library is available.

Hey Dylan! A bit more context on each of your questions:

With regard to endpoint visibility, yes, totally. One of our strengths is the ability to even price different endpoints differently. If you have endpoints that are high-value that you want to track differently than other endpoints, you can simply tag it, and Kable will monitor that endpoint as its own dimension. So yes, you can see which customers are calling which endpoints through our dashboard.

With regard to tracking request payloads, this is something we do not currently support. We've given this some thought, and while we might change our position in the future based on customer feedback, we are currently not storing customer request data. The reason for this is privacy. We want to be careful about what information we store from our customers' customers, so we require developers to explicitly define what information gets recorded in Kable.

Finally, with respect to billing and analytics and authentication as separate features or products: *ABSOLUTELY*. You can use Kable for billing and analytics without using Kable authentication. We want it to be super easy to use both, but we understand many customers have other systems for managing API keys or other parts of the stack. In this case, we recommend using Kable's `record` method, and using us for our core competencies of billing and analytics.

Integrating Paddle (and other payment providers) is in our plans for the spring. Our existing customers have skewed toward Stripe, so we started there. If you're using Paddle today and want to get started with Kable, let me know and we can chat about prioritizing Paddle sooner

Ahh, a question I get a lot, thank you for asking :)

Stripe is a payments company -- they are great at payments. They offer a full suite of tools (like subscriptions) around payments. But this is not their core competency.

Usage-based billing has three core components: * Defining pricing plans * Metering usage to generate invoices * Processing payments

Stripe is great at processing payments. But when it comes to defining usage-based pricing plans, and especially when it comes to metering usage, Stripe is actually pretty weak.

Pricing in Stripe is pretty brittle. You create products which have price IDs, and your code needs to understand these concepts. To evolve pricing for a customer, or to define a new pricing plan for an enterprise contract can be a pretty tricky thing to do.

And streaming usage data into Stripe is actually something that Stripe's docs recommends against. They recommend you aggregate your own usage metrics and post them infrequently into Stripe. Again, payments processing, not usage metering.

Kable's sweet spot as it pertains to billing is the first two items in that list. Pricing plans are super easy to define, manage, and evolve in Kable. Usage metering is our core competency. You don't need pricing concepts or external identifiers in your code. You record the *core concepts from your app* and Kable handles the rest.