Marc Laventure is the CEO and Co-Founder of Scalar and he joins us for a chat about API documentation, startups and accessibility. He also happens to be the latest guest whose technical background originates in hardware before morphing into product development.
Scalar is a service that allows you to document, discover and test APIs, which once again begs the question - is Fireside really just a podcast, or is it a way for Richard to discover services that will make his life as a developer easier? We may never know the answer. But when it comes to Scalar, Marc tells us of his very simple mission behind the company: making APIs as accessible as possible, to as many people as possible.
It started the way all good startups do, the founders realise that they all have the same frustration, (in this case it was badly documented APIs) and they set out to do something about it. After all, as Richard points out, good documentation can mean the difference between a developer wanting to adopt the service or not.
We should mention, that as impressive as all of this sounds, Scalar only launched a short month ago, though in that time they’ve amassed over a thousand stars on GitHub, as well as a great deal of positive early feedback. What’s clear from this chat is that we need to get Marc back on in a year to update us on this crazy journey he’s on.
Reach out to Marc here: https://www.linkedin.com/in/marc-laventure-75618a63/
Check out Scalar: https://docs.scalar.com/swagger-editor
Find out more and listen to previous podcasts here: https://www.voxgig.com/podcast
Subscribe to our newsletter for weekly updates and information about upcoming meetups: https://voxgig.substack.com/
Join the Dublin DevRel Meetup group here: www.devrelmeetup.com
Interview Intro
Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.
I am speaking to Marc Laventure, CEO and co-founder of scalar.com. Scalar.com is part of a new breed of developer relations focused products. In this case we’re talking about documenting APIs, which is difficult – if you’ve ever done it, you’ll know. Mark is a serial entrepreneur, and in the great tradition, he is scratching a personal itch. All righty, let’s find out how scalar.com works. [0:00:46]
Main Interview
Marc Laventure
Richard Rodger: [0:00:48] Marc, welcome to the Fireside with Voxgig Podcast. It is great to have you on today, coming all the way from British Columbia, I believe. Is it snowing yet? [0:00:56]
Marc Laventure: [0:00:57] I’m actually in San Francisco at the point of this call, but it is raining in Vancouver. [0:01:03]
Richard Rodger: [0:01:06] Let’s talk about your company – APIdocumetnation.com. That’s such a great name. No, wait – hold on a sec; you came up with a better name. [0:01:12]
Marc Laventure: [0:01:13] Yeah. We started with – we found the domain name APIdocumentation.com was available, and Cameron and I are super into domains. Makes sense with NameCheap in our previous startup. And we started with that and we still offer that. If you deploy on scalar, you get a free sub-domain, so you can get Voxgig.apidocumentation.com. But we eventually wanted to be a bit bigger than just API documentation, so we figured a brandable name would be better there, so now we’re scalar.com. [0:01:48]
Richard Rodger: [0:01:49] Yeah, which is awesome, sixletter.com. But they’re all gone, right? You have to buy them these days. [0:01:57]
Marc Laventure: [0:01:58] Yeah. They’re – definitely for the dotcoms, yeah. You’d be hard pressed to find a 12 – whatever the current dotcom price is, $12 for something like that, unless it’s random letters. [0:02:11]
Richard Rodger: [0:02:14] I see you have engineering books on your bookshelf, so I’m guessing scalar comes from the fact that you did engineering, math or something like that back in the day. [0:02:23]
Marc Laventure: [0:02:23] Yeah. I studied electrical and computer engineering at the- [0:02:27]
Richard Rodger: [0:02:27] There you go.
Marc Laventure: [0:02:28] Yeah, at the University of Victoria in Canada. I don’t know if many people know that school. [0:02:31]
Richard Rodger: [0:02:34] And it’s a tiny bit ironic, because scalars are ultimately the atoms of artificial intelligence mathematics, which is a place you guys are going and which we’ll – a subject we’ll come back to in a minute. We’ve just done the cold open, but let’s rewind a little bit for our listeners. And why don’t you take us through scalar.com, what you guys do? [0:02:58]
Marc Laventure: [0:03:02] My co-founder and I, Cameron, we had this hypothesis of, what if we made Stripe-level docs as a product? The bigger question there is, Stripe’s been around for a long time and their docs have been around. People love it; people love their developer experience. It’s really easy to get started with Stripe.
And we wanted to make APIs as accessible as possible for everyone, because not everyone has the same capital to deploy or bandwidth as Stripe does for their developer experience. And most of the time, if you are an API company, that’s the critical point for which people are onboarding. So, we’re trying to make APIs as accessible as possible. [0:03:42]
Richard Rodger: [0:03:43] Does that come from personal frustrations, dealing with badly documented APIs? [0:03:47]
Marc Laventure: [0:03:48] Yeah. It’s a mix of – there’s a lot of – firstly, every software company’s an API company, whether that’s internal or external. So not everyone’s able to –going to be putting the time and effort into making their internal docs perfect. For us, we saw that a lot of the times, just throwing Swagger UI or something at it was – would be good enough. But we figured we could take it with a much more modern approach and make that better.
I would say for me and my co-founder, I’m the engineering background and Cam’s a phenomenal designer, and he’s also HTML CSS wizard. And whenever he would try to lean and try and reach into any kind of API, he would often structure, so the – we’re trying to make it as accessible as possible for anyone. Because especially right now, there’s a whole new wave of developers and engineers, and always making things more accessible is a great thing. [0:04:54]
Richard Rodger: [0:04:58] There is a huge need for it, and you’re right that eyer company I s an API company. A lot of the work that we do is around helping people execute APIs, put them together. There’s an existing system and we have to help them build an API and SDK. And conversely, doing integrations.
We have one client where I think we’re up to our 16th integration, and this is across a wide range of APIs and SDKs. I’ll give a shoutout to Stitch.com because they have awesome documentation, and I would rank them number one of those 16. And then the 16th one – I’m not going to say who they are, but it’s an absolute pain to work with their stuff. And that’s with a direct line to the devs.
API documentation is a huge deal, and as a developer, it often makes the difference between the business adopting a service or not, because developers have a ton of power, ultimately to kill things they don’t like. And in terms of your clients, how have you seen the thinking there? Are you working with people that understand that they need really good documentation, or are you working with companies that have been forced into it because they’re getting such bad feedback. How much buy-in do you get from leadership and founders? [0:06:26]
Marc Laventure: [0:06:28] That’s a great question. We also = huge caveat – we launched a month ago. [0:06:32]
Richard Rodger: [0:06:35] You must have done customer discovery, right? Mom test, all that stuff, right? [0:06:38]
Marc Laventure: [0:06:38] Yeah, we did a lot of stuff before that, but the – and it was much more focused customer group. That’s the difference; it wasn’t that we were building in silos. It was more so – now we’re getting lots of inbound. And- [0:06:51]
Richard Rodger: [0:06:53] Marc, let’s talk again in one year’s time; let’s do it scientific. [0:06:58]
Marc Laventure: [0:06:59] We should definitely do it. But right now, we’ve been getting – I’ve been having so many sales calls and conversations with everyone from developer experience people on the team all the way up to CTOs, also product managers. It’s – the priority is there in the company; everyone wants to make this part of their business as accessible as possible. The onboarding time ideally is zero; they just get in very quick. They go in there, able to self-serve; it's simple.
And the ideal workflow too is, you alluded to it; you mentioned having a developer to chat with, with the API or something. And there’s a lot of great examples of founders that are selling APIs, being right there, helping integrate as much as they can, effectively being an integration engineer. And that’s one of the things we’re building towards too is, we have this AI integration engineer where you can converse with the API as if you’re getting help onboarding.
And there’s a lot of features that we’re building towards that that are meaningful and trying really had to reduce the onboarding time. There’s a lot of things to do when you’re running a company; there’s a constant prioritization problem. And for us to be able to take a lot of stress off, which is giving you beautiful docs and effectively an integration engineer and reducing the onboarding time is something that’s been a lot of pull for us. [0:08:29]
Richard Rodger: [0:08:30] Do you help people write the docs? Can I give you a Swagger definition? Or can you pull my GraphQL schema files and generate stuff? What’s the effort involved in getting up and running? [0:08:46]
Marc Laventure: [0:08:49] We start – the open source launch we started with was with OpenAPI and Swagger spec – you bring that in and we give you beautiful documentation. Also, we launched a feature around – we take that OpenAPI spec, Swagger spec; you write a few titles and it’ll populate the documentation for you. It gives you a really great starting point.
And it was something that Cam – this kind of ethos that Cameron and I have carried with it from the Launchaco – our first startup days. We want to give tools for people to get started and we know that it’s going to be a fantastic starting point, but it’s still going to – we’re still going to need that human touch from the beginning.
It’s like our free AI logo maker we built – unbelievable starting point; gets you super stoked. But you’re going to need a designer eventually to get that out. It’s the same kind of thing with documentation – it’s a fantastic starting point, but it’s going to need some human touches. [0:09:41]
Richard Rodger: [0:09:43] Documentation is super valuable in a lot of ways; it makes it easier to use whatever API you’re exposing. But I really like things like Versel let you give feedback directly in the docs. You can put in a comment – “I didn’t like this particular paragraph,” or “This was unclear” or “How exactly does this work?” Do you guys have features like that, or are you planning to have them? [0:10:09]
Marc Laventure: [0:10:10] That’s one of the most requested features, so we’re working on that. [0:10:14]
Richard Rodger: [0:10:14] There you go.
Marc Laventure: [0:10:16] It’s great. It was one of those things where – there was a pull request from earlier this year where we had it. And then it fell; it fell through. So, it’ll come back in the next cycle; I promise. [0:10:25]
Richard Rodger: [0:10:26] Yes, that’s a plus one for that one. I gotta ask – where do you see generative AI fitting into all this stuff? Because there’s this magic pixie dust feeling around this stuff that I just point out my code and I’ve got my docs. [0:10:43]
Marc Laventure: [0:10:48] It’s – there’s two sides to it too. There’s the ingestion, so how you’re taking in APIs or integration, and you’re trying to integrate. And there’s also the generative part there too. Because we’re going to be generating code snippets, or maybe things inside of your testing client or write inside of your IDE. And where we see the future of where we’re taking scalar to is the cohesion and amalgamation.
Right now, it's pretty stale and fragmented from what we’ve seen. You have documentation, testing and then code generation; it’s all separate. But what we’ve had a lot of success with and what we see, as we’re building towards to, is a really cohesive experience, where you have the documentation; you have the code generation; you have the querying. And it’s a really simple interface. That’s what we’re building towards. [0:11:45]
Richard Rodger: [0:11:48] Do you – the other side of it is, do you mostly focus on reference documentation or do you cover the other elements? One of the things in developer relations, one of the best practices, I guess, is facilitating different ways of learning. Some people learn best by sample apps; some people want to go straight to the reference docs. Other people want tutorials; other people want subject-focused blog posts. Do you – did you guys focus initially on one particular area or is the vision to help with all of those different types of content? [0:12:26]
Marc Laventure: [0:12:29] Interestingly enough, we have a full guide part of the product, so if you- [0:12:34]
Richard Rodger: [0:12:34] Awesome, very cool.
Marc Laventure: [0:12:35] Yeah. if you go to docs.scalar.com, we built a Notion-like editing experience. I don’t know if you’re familiar with Tiptap, but I can dive into how we built it too. Tiptap’s fantastic. We built a Notion-like editing experience; you can write long-form content. And then that lives alongside the references, because it’s just like you said; sometimes you want to go right into the end points, but other times, you’re maybe wanting to read the walk throughs.
And the nice part about the guides too is, we’re actively building our Git markdown feature. So, hopefully you’ll be able to – I’m not going to give a date yet, but we’re working on it – where you’ll be able to drop in a scalar file on your repo; point it to the markdown folder. And you’ll be able to get beautiful documentation right on scalar. [0:13:19]
Richard Rodger: [0:13:23] And the other – this is more of a personal itch. The other space where I find documentation challenging is if you’re an open-source maintainer. I don’t mean people who are maintainers of large projects, because they’re often supported by foundations and it’s relatively easy to get contributions. Companies sponsor technical writers, that type of stuff.
But there’s – I’m sure you’ve seen the XKCD comic of the – one little pillar of open source by – maintained by some guy for the last 20 years in Nebraska, that’s holding up the rest of the whole open-source stack. There are thousands and thousands of mid-tier open-source projects, where maybe the developer has – and it’s usually one person – has a GitHub Wiki, or they’ve put together a relatively comprehensive ReadMe on GitHub. But it’s still sucky documentation because your markdown doesn’t make navigation easy; it’s not particularly searchable.
And then you have people who’ve – maybe they’ve used something like VuePress – although I think it’s called VitePress now – or various other static site generators. Which are okay, but again, you’ve got to figure out how to host it and all that sort of stuff. What I find appealing in terms of your vision is this – maybe there’s no money in supporting individual open-source maintainers. But is that a demographic that you’re thinking about? [0:15:04]
Marc Laventure: [0:15:07] It’s something where – just to touch on a few things. We –everything we’ve built is in Vue.JS, so we’re big Evan You fans. Vite is great; VitePress is great. I’ve been – we’ve been using Vue since – right when it hit 2.0. We built Launchaco in Vue forever ago, so big Vue fans.
We see – we’re learning right now. We’re trying to figure out – because you’re right; there are – there’s so many factors of that. Such a – it’s a seven-dimensional kind of thing, because it’s like, are you using markdown, MDX; are you using DocuSource? Do you have your own things? Aare you – there’s lots of parts to it. Right now, we’re focused on starting with markdown and publishing to scalar, but as time goes on – I’m a big open-source contributor, sponsor, and we’re going to be able to find a way to let that happen. I’m not – I don’t know exactly how that would work just yet [0:16:14]
Richard Rodger: [0:16:17] I’d say go for it, because it’ll give you lots of those wonderful DQLs, developer qualified leads. Because those developers, they work for companies often. It’d be nice for open-source contributors to get a bit of love. Get a little bit more love; don’t you think? [0:16:36]
Marc Laventure: [0:16:37] I agree. That’s why we started with the launch of the open-source API references. You could – we have GitHub.com scalar/scalar. You can see our redocly and Swagger UI alternative. And you can – it’s MIT licensed, and it’s a huge thing we’re working towards. I would love to have, in the future, surrounding the guides and markdown, what that would look like – still need to figure it exactly out. [0:17:07]
Richard Rodger: [0:17:09] I know you guys are familiar with HackerNews because you did quite well on that a couple of years back. Did you see today Copilot for Docs? Did you come across that, was rated. This is where – I guess it’s GitHub’s attempt to do for code – do for documentation what they did for code, where they’re going to use generative AI and help you create documentation.
The place I’m going with this is, a lot of developers are now getting used to the fact that if I’m using React and I need to get some help with React, because – should I use –use callback, use memo, whatever. You don’t have these problems with Vue, guys. It’s much easier just to go to ChatGPT these days and ask a question and get a result or get sample code.
And what we’re finding with a lot of the people that we work with is, they’re starting – this is starting to bubble up. It’s not mainstream, but it’s starting to feel like it’s going to be a hygiene factor in 12 months, six months maybe, where if I’m offering an API, part of my documentation delivery has to be a chat interface, where I can just ask for sample usage. As opposed to the classic types of documentation we’ve seen up to now – the references and the tutorials and all that sort of stuff. Are you – is that a place you guys are going or what do you think. [0:18:47]
Marc Laventure: [0:18:49] Yeah, we have a chat-like interface right now for that. The interesting part that always piques my interest is having the ability for multiple interfaces for it. Like you said, it’s Grokable by how you want to go through it. Because maybe you’re right; maybe you’re fully in on this chat interface. But I oftentimes find it’s not just that; it’s not just one. Maybe that changes when we all have the neuro link and we’re – who knows?
But it's a great offering to have alongside your API docs at the current time, so we’re really excited about that feature that we have to offer. And again, it goes back to accessibility and making things accessible, so all for it – it’s fantastic. And some people, like I said, that might prefer docs; might prefer looking right into the source code, or having some sort of chat interface. Especially when you’re in the integration/discovery phase of a new API, it’s important to have a more fluid onboarding experience. [0:20:02]
Richard Rodger: [0:20:05] There’s another feature – I’m picking all these features from my goodie bag of features that I want – hoping you guys will build them. Just before we came on, I was telling you about the challenge I was having around a particular API that we’re working on. But as a user of APIs, one of the most frustrating things that I have is not being able to self-audit my inbound requests to the API.
If I submit a request to an API – now a few companies do this, but it’d be really nice if you have a log interface where you can look at those requests and you can see what happened. You can see why they succeeded or failed or what they did or cross links to the documentation – that type of stuff.
I know that would represent a deeper integration. That’s like documentation on – just-in-time documentation. Because it’s literally – I literally sent this request and it didn’t work, so I want to know right now. Are you guys looking at features like that, where it’s not just a documentation stack, but you’re going deeper into the implementation side? [0:21:22]
Marc Laventure: [0:21:23] Yeah, it’s a great feature. Stripe has that, where you plug in your API key, right into the docs. But then also, you can go and check to see what’s happening with all the requests coming through. It’s something where we’ve chatted about earlier this year. We’re at the wonderful part of a startup, where it’s a prioritization problem, so it’s been great.
But it’s really important, and as we get deeper into – just two weeks ago, we added the ability to – I should double check this – but to have the – you can specify the auth header at the root level. So, i’s step one there and then a deeper integration with whoever’s hosting the docs. We could provide something, like you said, an audit history for the user too. It’s not just – the user’d be huge.
Because right now we do have, in the client, where you can test requests. We do have a history, but that’s – you’re doing those requests through the interface. Whereas in the example you’re talking about is outside of that. I have an audit history, and that’s definitely something in the roadmap; I just don’t know how soon. [0:22:31]
Richard Rodger: [0:22:33] Yeah, that’s the toughest problem. But it’s a nice problem to have, when your users – potential users have a whole bunch of – you’re not trying to convince them that the idea itself is necessary. They can see – we need this, but we gotta prioritize which features we’re going to build first.
You guys are only starting on the journey; you’re a small team. I’m also interested in – and you’re going to be living in this world of developer relations, but I’m interested in how you, Marc, ended up in this place. because you used to code firmware for Tesla and you worked for IBM and you did all sorts of different roles within this industry. I’m interested in how – your personal journey to this point. Ultimately, was it always about developer tools? [0:23:27]
Marc Laventure: [0:23:30] It’s a fantastic question. Just a super-quick primer. I studied electrical engineering and – or electrical and computer engineering at UVic, so traditionally, more hardware, physics and then firmware level stuff. And when I came back from working at Tesla, I went to this Hackathon. I had never done any web development prior to this; it was all – if anything, Python was all related to data science.
And I ended up winning the Hackathon and that’s where I met my cofounder, Cameron; he was hosting the Hackathon. And we became pretty fast friends and then started hacking together. And he had this wonderful idea for Launchaco – startup website builder. That went fantastic. As we started building together, we started interfacing with – for me, that was a – you could think of even Unix commands as an API – it goes back; APIs go so far back.
In the meta sense, interfacing with him, but in the software world, hadn’t necessarily been too deep in until we started to accept payments or we were integrating with the NAM project or other APIs. And started learning – we started building our own APIs. And we were big into Firebase – that was super helpful way back in the day.
And when you’re doing that, we constantly felt friction with some APIs that weren’t as documented or as interfaceable. That spark lived with us as we grew. We launched the paid version of Launchaco after the number one on HackerNews and all that wonderful, amazing growth. And then at our time at Namecheap, when we were acquired, we – that got bigger. We started building more products, more services; those services were talking to each other. We built a lot of interconnected tooling.
We could tell when – for example, when I was building and I noticed that I wasn’t doing such a great job or it wasn’t easily interfaceable with the other team member – the other team members weren’t able to Grok what I was offering for this interface. Cameron and I had always been thinking about – even if we built documentation or use the existing documentation or solutions or testing, it still felt stale and fragmented.
So, we’ve always had this itch to – what if we were able to productize or offer Stripe level docs for everyone. Big open-source fans and users over here, so super excited that we got to release the open-source API references. And we feel like we did that; it’s been a very – I’m very grateful for all the wonderful feedback. And it’s been pretty surreal seeing the usage already. I don’t know if I directly answered that. I went off; I’m still getting over this cold. [0:26:17]
Richard Rodger: [0:26:17] No, I’m hearing the pain from all those API integrations with Launchaco. I feel you, man; I feel you, absolutely. And it’s crazy that it’s still that way, when Stripe has been around for quite a while and it is the archetype. It’s – this is the standard you need to reach. The – going a little bit meta, because this does go back into the domain of developer relations.
For a lot of practicing developer advocates, part of the challenge they face, especially this year, has been justifying their existence. And the poor quality of a lot of API documentation is another reflection of the fact that developer relations as a thing still doesn’t have massive buy-in from non-technical leadership and non-technical founders. I’m still waiting – previous guest of mine, a guy called Wesley Faulkner, his idea was that we need to get developer relations into the Harvard Business Review as – this is something that has huge business value.
Part of what we’re doing here is effectively advocacy around the importance of recognizing that if you have great API documentation and great accessibility, you’re making integration of your stuff way easier. Developers will choose what you’re building. And that – to go back to the DQLs, developer qualified leads, it has business value.
I would see scalar.com as part of that second wave of proper business validation for developer relations as an activity. Sorry, maybe I’m getting a wee bit philosophical here, but the question is, do you feel the same way? Do you feel you’re part of the next wave? Or are you too busy to think about meta stuff like that? [0:28:41]
Marc Laventure: [0:28:42] No. We have pure alignment there. Whenever Cameron and I build anything, we want to make – you go to it and you could just start using it. With Launchaco, the website builder, or the logo maker, it was one click and you were already making your website, your logo. It’s the same thing. If you go to docs.scalar.com, you’re right in the guided editing experience.
We made our app feel like – it is quite literally, you click Preview and that’s what your published site’s going to look like. For us, we want to minimize any time around you as the potential user for this product. You need to figure out if this is going to be what you’re going to need. For us, having no barriers going into it is so important.
And that gets applied to API onboarding too, if there’s all these walls for you to get in. You know – I need this shipping API; there’s no-one else can offer that. That’s different than if you’re trying to – exploring and trying things out. There’s also – there’s that – I agree with you 100%. A lot of – there’s definitely a wave of companies prioritizing a developer experience. It feels like – maybe I’m in the bubble, but it does feel like companies are putting a lot more time into that.
The other side of it too is the – we’re trying to not only minimize onboarding time for users to come into your API, but onboarding – trying to minimize the engineering time and design time, or any other people at the company, to make these APIs as successful as possible. There’s two parts to this, and we’re trying to do both. It’s – from a business standpoint, a lot of companies can see the quite literal – we reduce time for onboarding. They onboard quicker, have values there. Also, we reduce time to make these things better; then there’s value there too. [0:30:41]
Richard Rodger: [0:30:43] Yeah, it’s exciting. I think you guys are right time, right place at the moment. Thank you so much for coming on and talking – super interesting. I – out of my personal interest, I wish you well, because it’s definitely a service that I can see solving problems for me personally. That’s what you get to do as podcast host; you get to solve your own problems, which is great. Marc, thank you so much – this has been awesome. [0:31:12]
Marc Laventure: [0:31:13] Thank you so much, Richard – this was fantastic. I love chatting about all things dev experience, so this was wonderful. And it’s great to meet you. [0:31:19]
Richard Rodger: [0:31:20] Yeah, absolutely. We will talk again in a year’s time. Because I know you do the customer discovery bit, but I’m interested to hear, as people use it. Because it’s hard to product – what are the actual pain points? I’m super interested in those from a dev rel perspective. [0:31:36]
Marc Laventure: [0:31:38] We’re still early and we’re seeing a lot of great science and a lot of good usage. I know GitHub stars are somewhat bandied thing, but we had 1K in less than a week. And we really want some people using it, so yeah, super excited. In a year, it’s going to be great – we’re going to have so much stuff to talk about. We could do six months. [0:31:58]
Richard Rodger: [0:31:58] So many GitHub stars. You don’t need a new business model. You just need GitHub stars – it’s fine. Marc, thank you so much. Take care, goodbye. [0:32:04]
Marc Laventure: [0:32:05] Yeah, chat soon, bye.
Endnote
Richard Rodger: [0:32:06] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter, @voxgig. Thanks for listening. Catch you next time. [0:32:33]