tg3

Xkit | Senior UX Engineer | REMOTE | https://xkit.co

Software is eating the world, and that software is going to be connected together. Xkit is helping bring that future to fruition by building tools that make it easier for developers to add integrations to their apps.

We're hiring a Senior UX Engineer to help us define and deliver the user experience for Xkit.

We're a small team without a dedicated designer, so this role is responsible for determining the best UI/UX patterns to employ (using our existing patterns and frameworks where possible) as well as delivering them in the form of working, performant code.

This is a highly product- and user-focused role. We're looking for the rare combination of a highly capable React/Typescript engineer paired with a good UX and design sense.

For a full description, check out https://github.com/xkit-co/jobs/blob/main/senior-ux-engineer... or send me an email, trey at our main domain.

Xkit | Senior UX Engineer | REMOTE | Full-Time | https://xkit.co

Xkit lets developers add direct, native, embedded integrations to their SaaS app as easily as building a Zapier app. With one straightforward integration to Xkit, developers can add integrations to Salesforce, HubSpot, Zendesk, and others without writing any additional code. Most of the time, those integrations can even be added by non-engineers, like product managers and customer success managers.

We're hiring a Senior UX Engineer to help us define and deliver the user experience for Xkit.

We're a small team without a dedicated designer, so this role is responsible for determining the best UI/UX patterns to employ (using our existing patterns and frameworks where possible) as well as delivering them in the form of working, performant code.

This is a highly product- and user-focused role. We're looking for the rare combination of a highly capable React/Typescript engineer paired with a good UX and design sense.

For a full job description, check out https://github.com/xkit-co/jobs/blob/main/senior-ux-engineer... or feel free to email me directly, I'm trey at our main domain.

SEEKING FREELANCER | 100% Remote (one weekly meeting at 11:30am PT)

Looking for a Senior React/Typescript Engineer to help build out a new project at https://xkit.co (YC S18). We build developer tools to make it easier to add integrations to your app.

Small, fast-moving team; the rest of the stack is Elixir, PostgreSQL, running on AWS.

More details on the team and project here: https://github.com/xkit-co/jobs/blob/main/senior-frontend-en...

The specific framing of founders buying capital (dollars) is super helpful in understanding VC behavior, which is nearly are marketing.

VC’s sell a commodity product, money. In order to sell it, they add marketing, branding, and freebies - a bit like buying cereal with a toy inside.

Understanding that is the ultimate mental shift in raising money.

Great read. Two days I wrote about my own experience learning Elixir to build Xkit[1]. As I wrote there, the language guide is one of the best I've ever seen and is pretty much all you need to get started.

There are drawbacks of course (typing, deployment) but the pros far outweigh the cons for me so far. Here's to the next ten years!

[1] https://xkit.co/post/pivoting-with-elixir-how-i-learned-a-la...

I'm planning to build something like this with Next.js / Vercel. All of the changes will be managed via GitHub Pull Requests (so no need for any other authentication) with automatic deployment on Vercel.

I really wanted to like OAuth but implementing it is a nightmare!

Not only is the spec itself challenging, it leaves enough ambiguity and rough edges that most providers end up extending it some way that makes it hard to standardize. Most commonly: how to get refresh tokens (`offline_access` scope, `access_type=offline` parameter?), and how/when they expire (as soon as you get a new one? as soon as you've received 10 new ones? on a set schedule?)

And that's not to mention how OAuth gets extended to handle organization-wide access. Anyone that's dealt with GSuite/Workspace Service Accounts or Microsoft Graph Application permissions knows what a pain that is.

This is exactly why I built [Xkit](https://xkit.co), which abstracts away the complexity of dealing with all the different providers and gives you a single API to retrieve access tokens (or API keys) that are always valid. Not everyone should have to be an OAuth expert to build a 3rd party integration.

Thanks for the note on the typo, I've fixed it.

I'm happy to add other auth providers to our docs. Shoot me a note (trey@) with the instructions and I'll add it in.

Many developers want to have their integration catalog match the look and feel of the rest of their application, or they have additional configuration for their integrations outside of what Xkit provides. In these cases, building their own custom catalog using xkit.js makes the most sense.

Zapier is a tool focused on the user of SaaS products (e.g. I want to connect my Google Sheets account to my Mailchimp account). Xkit is made for developers (e.g. I want the users of my brand new CRM tool to be able to pull in data from Google Sheets).

Many developers start out by just adding a Zapier integration and telling their customers to hook up to other tools themselves. However, many companies find that having those integrations be native (rather than going through Zapier) is helpful with both sales and activation, not to mention the increased level of control you have. We're helping developers build those types of integrations.

Thanks for the kind words.

I agree we need to re-think our home page a bit. We initially focused on "OAuth" to really get specific about what we do, but it's had the unfortunate side effect of making us seem like an auth provider.

I like the idea of specific examples, and your headline ideas are great!

We have a Developer plan that's free up to 10 users. Our Startup tier ($50/month) is intended for early stage projects without significant funding.

If you have a project that can't afford our Startup tier for some reason, shoot me a note (trey@) and I'll see what I can do.

That's good feedback. We'll have to examine the native use-case a little more closely.

You can create an account and set everything up without ever talking to us if you prefer (that's the "Create a free account" link above the fold, https://app.xkit.co/sign-up).

Shoot me an email for more details on the SOC2 (trey@).

We're unlikely to support private cloud in the near term.

We have docs for it here: https://docs.xkit.co/docs/auth0-authentication

You can create a separate token specifically for Xkit or re-use an existing one.

We've had a handful of requests for native app support, so it's definitely something we'd like to do eventually, although we're more likely to start with Electron since it will be easier to port from our existing SDK.

That's good feedback on addressing the trust issue head-on, we'll work on that.

Hmm, there is an unfortunate resemblance there. Thanks for the feedback.

That's great! We support Intercom, Salesforce is coming soon, and I can look into adding Calendly too.

Re: staying motivated.

I was always a solo founder.

I think for me it starts with experience. I co-founded a startup when I was just out of college, and the ups and downs and challenges with staying motivated were by far the most important thing that I learned. Since then, I worked at two different startups and different stages and saw them go through good times (acquisition) and bad times (layoffs). So I think those experiences helped me keep myself level.

I also have a good professional and personal network of mentors, colleagues, fellow startup founders, family, and friends. My support system has been really important in keeping me going. YC has helped tremendously with this part.

And finally, I personally feel a lot of responsibility to spend my investors' money wisely. A lot of people believed in me and took a chance on me, so I feel I need to uphold my end of the bargain.

Long answer, and the full answer would probably require an hourlong therapy session, but that's off the top of my head :)

Xkit acts purely as an agent for our customers, we don't make use of the access granted ourselves (and as mentioned in another comment, we're happy to sign contracts to that effect). As a result, the consent screen and what users are aware of is the identity of the party they're granting access to - the Xkit customer, not Xkit itself.

As a side note, OAuth2 explicitly supports multiple clients and in fact recommends it if you are using the clients in different contexts. Google implements this pretty effectively imo.

Thanks!

a) Yes, I'm testing our Salesforce integration this week

b) While we don't have documentation for it yet, we support migration both in and out by loading and reading the current tokens for all of your users.

That's good feedback on our landing page, we've had the Auth0 comparison come up quite a bit, so we'll need to tweak it.

We don't exactly compete with Auth0. Their focus is on how you authenticate users, where we're trying to make it easy to add integrations to extend your product with data or functionality from other products.

There is some significant overlap, for example with OAuth tokens, but I'd say they work together more than they compete.

As for Office365: that's one of the integrations that's coming up soon for us. There are a lot of Microsoft Graph integrations that we'd like to add.

Yes, we absolutely sign contracts.

The access log is a great idea, we'll build that.

Yeah, Xkit is unfortunately also the name of a defunct Tumblr extension. We thought it was worth the (minor) collision.

Our github is https://github.com/xkit-co

That's an understandable position to take - these are sensitive pieces of information that provide a high degree of access.

We take the security side of this equation very seriously. All the tokens and credentials are encrypted (both at the database level and the field level) and access to keys and production systems themselves are tightly controlled. Our APIs are designed to prevent inadvertent leaking of credentials (e.g. it's impossible to retrieve client secrets from the front-end) and we have in place best practices to prevent things like XSS and CSRF.

But like many cloud providers, yes you have to trust us.

In the near future we'll work on some more public things (like a SOC 2) to make our specific policies easier to trust.

Yes, the integration catalog experience for a logged in user would be very similar to the My Apps screen in Zapier. (by default the styling is a bit different, but you can customize that e.g. if you prefer the list vs grid view)

ACH is a method for sending money between banks primarily in the US. Yes, unfortunately we're limited to 22 states in the US right now, but we're working to expand to more states and internationally in the coming months. We're working on publishing that information more broadly, thanks for the feedback.

I think we're working together in our support channel, but the email you received was in error - we're working to resolve.

Our partner has clarified that FDIC insurance is per user (per Tax ID) rather than for the whole platform

The product is very similar to the Square Cash app. The main difference is that when you buy Bitcoin with Sparkswap, the Bitcoin goes instantly (and without paying on-chain fees) into a wallet for which you hold the private keys (rather than a company holding the keys on your behalf). And that Bitcoin is available for spending on the Lightning Network.

The downside is that you have to be comfortable being responsible for the keys, which not everyone is.

Initial setup is definitely not as fast as we'd like it to be given that we have to do identity verification, both for fraud prevention and AML compliance. Once you've gone through that setup, the interaction is near-instant, and the Bitcoins go directly into your wallet.

Both Zap and the Sparkswap app are open source, which should reduce some of the trust you have to place in them.

The trust issue with fiat is difficult to get around, with both Sparkswap and any other service that interacts with the traditional financial system. By removing custody of at least the Bitcoin side of the transaction, we think we're taking a step in the right direction.

Overall your feedback is well-taken - there is certainly more we can do to reduce the number of steps and different pieces of software / service providers that users need to interact with to use Sparkswap.