Developer copywriting mistakes to avoid, with Zach Goldie

Zach Goldie 0:00
Like everyone says ship code faster, it's empty. It's an empty statement. It's like, the aim of every dev tool pretty much is to help you ship code faster. You haven't told me anything about your tool at this point. Hi, everyone, you're listening to scaling dev tools. We're joined today by Zach Goldie, who is a dev tools, messaging consultant. Welcome, Zach. Hey, Jack, good to be here. Thanks for inviting me. I want to dive straight in to something that I find really interesting. We've had super bass on the podcast before a couple of times, actually. And one of the things that they shared was that in the early days, they were marketing themselves as real time Postgres. And things weren't, like taking off. And then at some point, they kind of they on a whim, they rebranded as like, open source Firebase alternative. And their whole trajectory just changed. And I think it was kind of the turning point for them. And you're an expert in this kind of area. And I wanted to hear why do you think that that worked? Yeah. Yeah, that was I listened to that episode. And it was definitely a fun little bit, because especially they are talking about like finding product market fit, and how when it clicks, things do often suddenly take off. But I think it was my suspicion. Most of the way I've heard people talk about product market fit is often in terms of kind of the feature set and the core like functionality of the product itself. Whereas this was more about why think of a bit more as kind of the message market fit or positioning fit, where, even though the product was the same, just the way that they talked about, it clicked more with people, even though it's the same features, which

is always a hard one to do. And like there's no like, I'm never going to pretend like here's the one way to do a thing. Because life's never that simple, especially in marketing. So the sounds of it is you often hear about kind of, you heard about pain points and kind of people's struggles, where there's definitely different dialect, like, what's the word different, like levels of pain that someone can feel about an issue, there's some things that we're like, even that we're aware of, but they're not enough of us to be a priority. We all have those kind of that saw whatever body part of like, oh, maybe we should go to the doctor and get it checked out. But life's busy, and I can't be bothered right now. It's like, even though we're aware of it, and we know it's kind of bothering us, we don't care enough to fix it. And we've kind of real time was a real time Postgres, maybe even it's like, yeah, maybe we could use that to build this feature that we had kind of had in mind. But then I'd have to learn this whole, like new bundle of stuff. And like, it's not enough of an issue for people to go yes, that's what I need. Especially if it ties into I don't know that area well enough, whether they're already kind of free open source, kind of whatever off the shelf things that people will be like, I'll just use that to get started. That will do for now. So it's kind of, are there already free options that we're doing that there's might have been better than the free options, but maybe people didn't care enough to upgrade? Which is the thing I see quite a lot. Is that like, you are competing a lot of the time against a free version. Yeah. So it's that, whereas the comm was open source Firebase alternative, clearly just hit more of an active pain point. That was frustrating people that was getting more of like, oh, yeah, I really, like need to make that change, because it's having actual implications for me in the short term. So it was more of a high up the to do list, which I'd be curious what, what made them decide on that path in general, because I don't think they talked about that aspect of the story. But I think finding that like, Okay, people say that this is a nice to have, but it's not resonating with them that much. Maybe we need a dramatic change is just such a core part of their story.

Yeah, yeah. Do you see a lot of companies that like kind of position themselves against like the big kind of player in the space?

I think often, websites often kind of, I think in terms of even if you're not doing it intentionally, there's an inbuilt way that you are talking when you are coming up with your website, which I think a very common default in, like b2b in general is to talk as if they're an eager first time buyer, as if they haven't used this kind of thing before. And they're desperately looking for a solution of the kind that you have, which is an easy trap to fall into. It's a bit of the kind of selling the drill, not the whole kind of vibe. It's like yes, clearly someone vaguely wants a hole already and they're looking for a Drill. It's like, I get that. But that's often not the case. It's more of a especially in things like dev tools, maybe they've already got an old drill, and they're thinking of upgrading to a better one. Because the first one they bought was just like a cheap and cheerful one, which kind of can drill some holes. But now they're looking to like, for whatever reason, drill through bloody titanium or something. So actually, what you need to send us the ability to drill holes in new toughened materials, which is a very different pitch. So yeah, I think a lot of doctors either pitch themselves as if they're a first time buyer looking like very much looking for a new solution, or the set like similar definitely looking for a new solution. But for probably using a computing software, like competing against data dog like ours, the cheaper alternative to data dog. That's like a thing that I've definitely seen in places.

Yeah. So where would you start? Like if you're, if you're kind of like a dev tool, and you've got a message, and maybe you've like, you feel like you've kind of invented something new for learners. A lot of the challenge comes because we're trying to like invent things. If you know it's not working. Yeah. How would you kind of go about landing on the right message?

Yeah. So I've, I've always viewed I think I'm weird in the marketing world. I like the kind of puzzle aspect of I like the kind of thinking about the customer and what they're doing, what they've tried already, why it's failed. And then think about product and kind of, what does it do? How is it different? So I always start with that kind of customer side? Which in particular, I think in terms of kind of, what's their current scenario of like, how are they already tackling the projects? Like? Are they often Yeah? Are they using a free version way of doing the problem? Because if so, what's the issue? Often you're not solving the end go, I'm gonna stick with monitoring tools. So the monitoring tools, the end problem that you're solving isn't like spotting downtimes. And like fixing those issues, because they've already got a way of doing that. The problem is that their way of doing that kind of sucks, or as expensive or as complicated, like, the problem is often the way that they're solving the bigger problem.

I see. So you're not trying to say, hey, we'll help you reduce downtime. We'll help you reduce downtime, at a cost you can afford or like, stop wasting money on

a hole, we won't give you 1000 dashboards that you don't know what to do with will like, maybe it's that, like, their current main option is overpowered and they don't like I've seen some tools that aim to kind of fill that gap between the free version versus the overpowered enterprise version. So you can be like, Look, we'll help you like, upgrade in the free version. But without all the like costs and complications and needing a whole team just to use the like, really expensive version.

Yeah, that's such a really, really valid point. Because I felt like a lot of us was want to feel like we are almost like the pioneers. And there are no other like, acceptable ways to solve this problem.

Yeah. Especially, I think a lot of dev tools are aiming to replace an existing step of workflow. A lot of the time they're not doing something that's completely new, which is like completely valid, it's a better way to do your CI workflow. It's not here's a whole new, completely different way to deploy your codebase. And even that would be replacing the old way of deploying code.

Yeah, that's dumb. Yeah, that makes sense. So let's say you kind of figuring out like, okay, the monitoring, so you're going to solve monitoring in a way that doesn't involve 1000. Dashboards? Yes. Then how would you think about how to kind of communicate that in a way that people would engage with?

Personally, as always a like, a tricky challenge does often involve talking people like working out, what is actually the headaches that they care about, in terms of monitoring solutions? In that case? What are the bits specifically that annoyed them? Because there might be some things that bothered you, but not them, I think is often the trap that people fall into. It's like, ah, yeah, this was really annoying me and then they talk to other people. I saw a discussion recently of a dude who'd made like, that was a CI tool that was all about like reducing the time for all the tests to run. And a bunch of responses on Reddit just like I'm quite happy having a 15 minute break whilst all my test runs it gives me a chance to go get a coffee. That's like it kind of is a problem but I think he needed to look at a different aspects of the area to Like, okay, this is the bit that we actually need to solve. So it always start there before looking at the Okay, so go always more into the details of say, Okay, it's easy to use, everyone says easy to use. It's one of my most hated phrases as either fast or easy to use or both. So that was a good like being on the programmer humorous humour subreddit, it was like the Batman slap with Robin saying ship code faster and Batman have been like, Shut up slap around the face, because one says ship code faster. It's empty. It's an empty statement. It's like, the aim of every dev tool pretty much is to help you ship code faster. It's like so many b2b tools, say, grow your revenue cycle. That is the aim of literally, essentially, every b2b like you haven't told me anything about your tool at this point. And yeah, in the comments for that meme, there was lots of discussions about like, the kind of what you say versus what people hear. That's like, use a ship code faster. They hear caveat, caveat caveat. It's like the, in ads, when you get the little asterix of like terms, like 80%, sale or Asterix terms or conditions apply, customers must purchase at competing stores only and wearing two items, or purple, or whatever, silly caveats. Like there's the developer equivalent of like, yeah, easy to use caveats, as long as you're using an ideal use case and have no conflicting dependencies, or these kinds of, we're actually gonna take a little bit. So I think at that point, it's okay, so hopefully, you've got your pain points. There's the things that people care about, and the aspects of your product that kind of match into that if like, okay, part of it is that the free version doesn't scale? Well. It's like, okay, you can just say, works at scale. But like, what does that mean? How can you? And I think there's a path there with, like, easy to use or scales or fast that people often I think, writer and instinctively, maybe, no, it's not that convincing. And you've got to like branches, you can go down the one that I think is more obvious, but less effective is kind of hyping up the language. Which is where you get these really fluffy statements. I've got

lightning fast. Yeah, there's,

I should really stop, like dissing on it circle CI on one of their pages, have the phrase, what is it deploy at the speed of creativity? Oh, yeah, I'm gonna hate that, guys. That's what like. And I think that comes from the sense of knowing that what you've written, isn't that compelling. So one kind of solution is to add some, like more exciting language about it, or explaining why that's a good thing. I think you often get the like, saves you time, and therefore you have more time to ship ship features, not fix whatever. Like I've seen there. So you have more time to ship features. That's quite a big one. It's like, that's explaining the obvious, guys. Yeah, so I think there's a big thing about over explaining the bits that are actually obvious versus under explaining that, how does it help you save time? Like, what steps does it actually let you skip? Might have got a Pio plant where they're all about API integration. It's like, it's not just, it's faster, let's just get like, so you no longer have to get lost in? Or is it kind of error handling and rate limiting? And all of these kinds of aspects, it's like, pull out the details of how it's faster, not try and explain why faster is good. Yeah. Which possibly sounds obvious once they say it, but I see that trap all the time.

Yeah, because there's not that saying fast is bad. Because like, for example, I see like bond, if you seen bond.sh. They're like, kind of rebuilding. I've not used by fingers, like kind of a, you know, alternative to using Node essentially. But like, everything is faster. And it seems like almost all of their marketing is essentially Jared the founder, like demonstrating, like, what features he What clever, like tricks is written into the code that make make it run way faster, and how fast you can write tests and stuff. And it seems to be really popular, that kind of stuff.

That's good. Yeah, it's always nice to see those evidence. And even evidence is a tricky one. Like that circle CI thing that I rip on has a little speed comparison of like, running it Built on them versus other things. But I'm like, you could be like, Oh, well, that was probably just like a one time use case that was probably tuned to their system. And it's like, it wasn't averaged over 100 different users self reporting, blah, blah. It's like, even there, like, providing evidence to get past that scepticism is kind of hard.

Yeah. How do you do that?

I mean, that's on a case by case basis, it's kind of it will be how well could you prove that it's not just like, you cherry picking data? Or what details can you give to say that like, maybe it's written on a faster language or something or in a different way or got more this, that or the other. Sometimes competing on specs is valid if your use just is more powerful, because x y Zed you can say? So it's a little bit of a hard one to give a blanket statement. But it's what I often end up doing a lot of it's like, going through like articles or technical articles or clients written like written go through maybe if they've had like YouTube webinar, or whatever is and they've like, talked it through in a more natural way. What do they mention that makes it faster? Or better or easier? Or like scale better? kind of pick through those details of exactly. Why does the claim that you say it's doing?

Yeah, this seems like these kind of hard things like when I've been working on, like a landing page for ideas, it's so easy to get caught in that trap of like, fast, by developers for developers stuff like meaningless things first.

Yeah, I think curse of knowledge comes into play quite a lot. If you've heard of that concept. Curse of Knowledge, I came across this. And I think it was made to stick by Chip and Dan Heath was the book, where they talk about, when you know what you're talking about, you can say a statement and you like, have the unsaid paragraphs of information behind it. Like I can say, I help my clients create pages that are more relevant to their readers. And I know what I mean by that. But that can mean a whole load of things to the other person and what they interpret that to mean, and can mean a lot of confusion, like what do you mean, by more relevant? Do you mean that sort of like personalise their names in there, or it can be interpreted in 100 different ways? Because I knew what I meant by that, like short phrase, but the other person doesn't. Yeah. And that comes into play a lot, where it's like, oh, yes, scale is more easily. It's like, you know, what you mean by that, and why it scales more easily and everything else, but the reader doesn't. Especially when you start adding slightly fuzzy words such as developer experience and their of improves developer experience. It's like, in what way? That's quite a big topic.

Yeah. So if someone was kind of working on like a landing page, they had a very short amount of time. So you mentioned like, going to speak to someone, or speak to like customers and train, obviously find something that seems to actually be important. But assuming they kind of have done that, like, how, how is there? Are there any kind of like, sort of things that you'd recommend just like working through? Or like, is it really case by case?

No, there's definitely I do have a whole slightly plug, I have a whole like messaging guide on my site that people can go read that kind of walks through this and not too long or format. So yet, a lot of the time the people I talked to clients do know enough about their customers, it's just that they haven't kind of pulled out and formatted the information in the right way. So like, talking to new people, or is isn't that necessary? I'd always start with like, okay, sit and think about the user, your ideal people will like what are they using already? What are they annoyed about? If they've tried something and it failed them? And now they might be sceptical about a new version that claims to do the same thing. Why would like? Because that's a whole, like, getting round that jadedness How do you get past that? I think, thinking about, like, take a while to think about the objections people might have, like, why might they go? Oh, that sounds good. But like, why might they doubt you? And how if you were talking to them face to face, like pretend you're just talking to them? Forget about writing website for a while. If they're to be like, Yeah, but how does or what does it do in this use case? Or what about if you I need to integrate it with like, think about all the ways that someone might be like, Yeah, but and what you would answer to each of those and then go from there into there like, okay, so what are like key like problem solution pairings? And what are the issue? And how do I solve it? I tell people, I find think it's quite a big challenge. But it's an obvious and easy thing to do of when writing website content, you're essentially doing two things at once. Because there's two stages in my head of there's deciding what to write about and how to write it. And pointing at my fingers. So everyone in the podcast can't see me doing that. But

yeah, I shouldn't. Alright, so I think

that's very hard to do both of those things at once, I would always say I can't do this on a screen, I have to do it still on pen and paper, have our sit there and jot out key points. And then like, they'll kind of then a few sub points for each one of like, what are the elements like, what's the evidence or the detail that would support that point of like, here's a claim. And here's the evidence and evidence to reinforce it.

And that's the, that's the what you would write about?

Yes, that becomes their claims essentially become the sub sub headings have like each section down the site, and the content becomes the evidence for that claim. I think it also becomes a bit clearer. If you're skipping that step. I think one thing I see on a lot of websites is you'll get a sub heading, and then one sentence that's relevant to that sub sub heading. And then a second little paragraph, that's actually about something different, that they didn't have space to mention anywhere else. So they're just going to mention it here. Is that bad, it's not ideal, it becomes a bit of a, the aim should be that people can get the general idea by getting the sub by just skimming the subheadings. I think it also makes it I've got a little gripe about, like, copy length and word counts where people worry about too many words. But firstly, people like developers will read several 1000 word articles about one nice little coding whatever, like tiny thing like, people do read if it's interesting to them. Yeah, there's a good, what's the name? There was a film critic, Roger Ebert at Bert, something like that, who has a quote about no good movie is too long, and no bad movie is too short. It's like, yeah, like the issue isn't just the amount of words on the page. It's, is it engaging and relevant? Like, as soon as something becomes a bit fluffy, or you get a bit lost of like, how these points relate to each other? And it's darting all over the place, you start skimming? Because why would you not start skimming at that point? And as soon as you've like, hit that fluff trap, you've essentially lost them no matter how short the rest of the pages. Yeah, this

is such a good point. I felt like so much of it is like laziness. Like when someone reviews when someone first looks at, like a site, you made landing page, a lot of the feedback you get, they're like, what's this? And then half the time I'm like, Ah, but I couldn't really think of anything to just put something in. Yeah, I definitely don't stand by the statement.

That's fair. And I kind of get similar things sometimes. And like, I saw, like, I did a second point to support that statement, just because otherwise that section will look too short. And they kind of sit down like, Okay, but what would actually be relevant? How can I expand this in a way that is meaningful? Like, I kind of get close to that myself? I think this just needs a little bit of extra text or a little less extra? How can I cut it down without making it just seem a bit fluffy? Kind of hitting that balance is a tricky one.

Yeah, this is really good. So and that is kind of, so you would start with that as the what, then what, what is the how?

The how, partly a matter of practice, partly, there's a lot of don't try to sound like a marketer, which sounds obvious. I don't think anyone does. That. There's a lot of how would you describe it to a person? Like, if you were talking across the table to someone, like imagine you were just writing it out? As you were talking someone in your head? What would you be writing? He probably wouldn't write the kind of sales style hyped up, like slightly empty claims, because, you know, you'd sound like a tool. Always. And I think that's why it kind of the business casual style of writing has propagated quite heavily across all of this as SAS market, even outside of dev tools, because it's just like, business speakers annoying. So always think about that. Always Think about how much do I need to pitch like the feature versus the benefit? Will it be obvious if I just say it does this? Why that's a good thing? Do I need to explain why that's a good thing or not? Which, yeah, they've already discussed that article. Yeah. Do you need to point out why the good thing is a good thing or not? There's always a big one. And if yes, do you need to like go up a ladder in terms of abstraction? Do you need to add a great client wells to do like Git hooks? And that was like, oh, yeah, we have automatic git hooks or something along those lines. And that was fine. But it was an obvious. That was one of the actually more unusual cases, like, there wasn't obvious why that's useful. They had to like point out that it meant that you could like, force your team to run local tests before deploying or something along those lines. It's like, sometimes, if that's more than a feature by feature base, is it innovative enough? That you'd need to point out the point of the feature? If not, can you just say some stats about it? And people will go, oh, it lets you like, not have to do this thing that I hate doing? You don't have to say why not doing the thing is good.

Yeah. And do you think about a specific person when you're doing this? Like, when you say like, oh, it's, it's obvious, or it's not obvious? I guess that kind of slightly depends, like who you're talking to, as well.

Yeah, to depend a bit on, I think that comes back a bit. Are you aiming for users already using an existing tool or someone trying it for the first time, because someone who's already using a competing tool might have come up against the bad version of this feature, know why it's annoying, versus someone who hasn't used like a feature of that style might not know really the point of it. So it will depend a bit on your target audience, I don't think of like an individual like, person sitting across from me, but I have that kind of level of familiarity in mind. That makes sense.

All that and any kind of like examples where like dev tools have just like really good copy pages that you would recommend, especially if it's like for a start up, so not like, you know, huge company where they have like a gazillion different product lines and stuff.

I feel like I should know some examples off the top of my head, but I don't unfortunately, like there's, I've definitely seen a lot, I just don't always remember the name of them, which is quite annoying. Now. I think it's hard to know, because it's hard to know without the context, partly because I am not a developer. So a lot of the time, when they say oh, it does this thing. As an outsider, like, that sounds cool. But it's only when like, talking to the clients that I am able to realise why it's good or bad.

or interesting. So it's not inherent, the obvious.

Yeah, like you can write copy that sounds good. And there's generally, I guess that's two factors of is it like well written, and generally kind of does well, in the whole, like balancing product versus features versus is it well targeted? And its pitch is a different layer? Like it's hard to know, are these problems that you're addressing actually problems that people care about? Yeah. Because even Yeah, especially not as a developer. But some, it's hard to know, without talking to, like the developers who made it. Some might be obvious to other developers, where you're like, oh, yeah, it says it does this, but I didn't care about saving 15 minutes of my CI time. Why are you talking about this? So the I think the question to me is more the priority of is it matching? The pain points and the priorities of people versus I kind of see words as a delivery mechanism? Like the words are there only to deliver that like, general high level pitch? Yeah, I don't care too much about them being like nicely written with good grammar or anything else.

But that doesn't matter that much. Compared to that's the

icing on the cake. That's the adjective clause that that's like the last 10% I do is the actual words themself.

Yeah, that that makes sense. How do you know if it's, if it's good?

That's always a tough one. I love a good AB test, even though they have their limitations. It's always satisfying to hear that kind of it's doubled conversions versus the old version of the page or something along those lines. is probably just the main key one. You can't really know without testing, I haven't got that far into doing user testing. But it isn't an area that I'm interested in. There's various, like b2b website, Review Services where they'll make a panel to kind of feedback on the site, which is quite cool. I've done that just a little bit. And it's quite nice to hear people go, Oh, yeah, that is kind of a thing that we struggle with. But even that does have its limitations of people aren't very good at saying why they don't like a thing. Yeah, people, like using music as an example of like, I can pay you a band that are kind of decent, but not that great. And you'll know that decent but not that great. But unless you're also a musician, it's hard to actually pinpoint why you might be able to be like, well, this thing is a bit out of tune or whatever. But even then maybe they are in tune. It's just like, unless you know about things like freezing, you might not know that it's because the drum is going to test itself. And it's making the whole thing drag. Like, you will know if something's good or bad, but not why. And I think that applies to websites as well. Like a lot of the time, people will be like, it's too expensive. I don't want to buy it. But what they actually mean is they don't really understand the point of it, or why it's worth buying, which isn't the same as it's been too expensive. Yeah. Which is a thing. That was actually a case with like a very old client who did the Online Guitar course, where he kept getting feedback. And it's too expensive. And I don't think it is, I think it's just not very, like pitched very well, or like, it hasn't really shown why it's worth buying. And without dropping the price. We reload the page and like, yeah, sales like shot up from weekly to daily or something along those lines. Yeah. So like the back was kind of valid in that it wasn't hitting the spots, and people knew that. But in the way that it? Yeah, like the details around that weren't quite right.

Is there kind of just like an argument as a startup, like, well, like barely anyone's using you have just like, trying loads of different stuff until it's so obvious that it's right, that you've heard, it's better than, you know, like you make like we've supervised like, I don't know, if they did an A B test, they probably wouldn't have had to do an AP test, by the sounds of it were like, suddenly everyone just started, it's like very obvious that

thing, definitely just do a straight swap if you've got low traffic, because you've kind of got nothing to lose at that point. Like you're aiming for a big enough change that it should be hopefully obvious. And even people who like their whole careers about a B testing will say, yeah, if you're getting only a few conversions a month, don't bother doing an A B test, because it'll take you six months to get a statistically significant like, result.

Yeah, so just throw stuff at the wall. So interactive people,

I think that's a danger of self serve stuff is that you're not talking to people, even if it's like, as a customer support thing. And I think people can do market research without pitching it as market research. There's a difference between like, Hey, can I talk to you on a course I can learn about your needs, versus just being like, hey, like, more pitching it as a support column, I want to help you make sure you like you're using the setup correctly, and do some small talk at the beginning. Like it's fairly natural today. So why like, I am curious about like, why you started using this and what you were doing before, like, that's kind of just natural, small talk before support. Cool. So do like onboarding, free onboarding, even though it's not scalable, just so that you can have that chit chat, stop? And do that bit of small talk, like, Ah, so what we're using before handmake. I'm curious why you picked this one over the other. And that's just being friendly,

I think is a really, really crucial point. I have not seen many companies do this. I've seen superglue. We've had them on the podcast. And they did as I was trying out their tool. And they did an onboarding call with me. And I don't remember when they asked me like, those kind of questions. But it was great, from my perspective, but if they'd have said, Can I do a question, you know, like,

market research, cool kind of thing? I don't know. Why would I want to do that? Even if you've offered me a $50 Amazon voucher, which

is? Yeah, kind of it certainly changes the dynamic because it's like, oh, actually, you having a call with someone who's really knowledgeable on this space, especially because it was the founder, the early stage companies, right?

Yeah. How can you make it sound like a good deal for them? Not for you, not just for you. Yeah.

Zach, if there was one thing that you would advise early stage dev tools to be doing or not doing? What would it be?

Think about your ideal users current scenario? Like that's the number one thing of like, what are they using already? How much does it bother them? Why does it bother them? Doesn't it like what aspects do they care about? Are they Are they even aware that like, security is quite a common word? Like, do they even know that they have an issue that could be fixed? Like, do they know that their website is being probed by malicious people? Or 100 times a day? Because if not, you're gonna have to start at like highlighting that issue, or have they written that offers like something that's just a bit inevitable that maybe they can't fix? And suddenly, they'll be like, Oh, wait, there is a solution. So yeah, always think about your potential users. What are they using? Even if it's like, are they doing it manually and kind of happy with that? Like, maybe they don't care about automating it, but maybe they do. Like, what's the change that you are suggesting? And how do you fit into that potential change? Pitch the upgrade if you need to pitch the upgrade? Don't put your? Yeah, there was one about keyboard SDKs recently, where that was in the slack group that were both in the DevOps lab group where they were saying about, was it in there maybe at someone else, saying about like, new app builders? aren't that bothered about using their keyboard SDK stuff? Because there's a free option? It's like, well, yeah, of course, he used the free option, but then you could come in later be like, Okay, so now you're getting tired of the free option. Here's now I should use a paid one. Which is a completely different, like, pitch to Oh, you're so you've started developing an app, why you should use our keyboard.

Yeah, so you're kind of acknowledging that there is a free version. But yeah, why is different?

Yeah. Why is your version fixing the problems and their current methodologies? So often? The pitch for dev tools?

Yeah. Yeah, that's a really good one. Zack, thanks so much for joining. You're most welcome. And thanks, everyone, for listening. If you're interested in learning more about Zack, I really recommend going to dx dot tips, and reading Zach's recent article about benefits layers. It's a really good read about messaging on dev tools. And I think there's a link in there as well to Zach's page, where you can kind of reach out to him as well. Very hard

to find is that godaddy.com Zack goldy.com.

Amazing. Thanks, everyone for listening, and see you soon. Bye.