Replit customer at BatchData on building internal tools for sales and marketing efficiency

We spoke with a Replit customer at BatchData who uses the platform to build internal tools like a custom CPQ system and social listening tools.

The conversation explores how Replit enables rapid prototyping and cost-effective alternatives to expensive commercial solutions, while also discussing its limitations for complex applications and the need for technical champions within organizations.

Key points via Sacra AI:

How is Replit used at Batch Data today? What are the top few use cases?

Replit has been primarily used to help with efficiency gaps within the company or create software that would otherwise be very expensive to procure or buy. One example of software we created, and this is the most elaborate example, is a CPQ (Configure, Price, Quote). CPQs are used for creating custom quotes for customers or prospective customers, allowing the salesperson to build a quote, get it approved, and send it. The issue we were running into is that our salespeople were creating very ornate Excel sheets and spending too much time building quotes. So I came up with a CPQ and built that out. It's a little more limited than some commercial solutions that cost $50,000-60,000 a year, but ours works for us.

The other use case is a social listening tool. We created a tool that notifies us anytime someone mentions certain keywords that are important to our brand or our brand name. It sends a notification into Slack so that we can be in those conversations.

We also built a series of calculators that we extracted the code from and put onto our marketing website. These are tools that other companies charge for, but we created them as a free resource for people.

What is the biggest misconception you hear about Replit in business environments?

The biggest challenge I see for people using Replit is that it doesn't do what they want it to do. At times, Replit can create a different problem while solving the problem you're working on, so you have to spend more time debugging or doing QA on that specific issue. If you know how to prompt it correctly, you'll get what you want out of it. Occasionally, it thinks it solved the problem when it actually hasn't, which can be frustrating. You have to pay close attention and give it guided advice.

There are methodologies you should learn for how to prompt Replit. You need someone probably semi-technical to really make the most out of it. I have yet to see someone who knows nothing about how websites or databases work be able to create something with it. You need someone to champion the product. It's not like ChatGPT where you could just buy licenses and say, "Go use this and make cool things." You need an internal champion that will look for business use cases and train people on how to use it.

Who typically builds on Replit day to day at your company? Is it the same people who sponsor and pay for it, or is there a different dynamic there?

For Batch Data, it's primarily been a chief executive role who sponsored and paid for it and who's championing it. Then one or two people who have technical ability and are in the operational aspect of the company and want to learn how to use Replit will use it as well.

The key thing is someone has to want to use a tool like Replit or be willing to learn to be successful with it. If you're just throwing the tool at people within your company and they don't understand why or how they're going to use it, then it's probably not going to be successful.

Which tools did you consider besides Replit? For example, Lovable or Bolt. And what tipped the decision in favor of Replit?

Before any of those tools, I tried out Retool, which is kind of a predecessor of some of these AI-IDE tools. Then I tried out LevelBull and Bolt. Where Replit has really gone above and beyond is it's a self-contained world, which has good pros and cons. From design to database to authorization, and deployment—which is actually one of the trickiest things to get right from a development perspective, especially when you're using a custom app or a modern coding framework.

When I tried out Lovable or Bolt, and I've revisited those over time, they were interesting in some ways, but I got from zero to one much quicker with Replit. Retool was interesting, but these other tools are a step above.

What would you say is the greatest product strength and what is the greatest weakness for your needs?

The greatest product strength is its ability to work through a "one-shot" idea. You put in a prompt and it does a reasonably good job at getting you 80 percent of the way there and showing you a prototype quickly. Fast prototyping is one of the best things about it above anything else because that is typically a convoluted process. If you want to get an MVP made, you're talking with 2-5 other people with a lot of iterations and meetings, and you get a lot of wasted downtime. Versus here's my idea, I type it out, and it does it for you. Then you prompt it to correct the things you want.

The greatest weakness is that depending on how complex the application gets, it can start to break down. It's just too much code to run through. I think they all suffer from this because it's working off of a context window. If you build up to a large codebase, it has to sync a lot longer every time you're using it, and then it can create more bugs. So there's a tipping point where it might actually become more problematic. You need to be thoughtful about what you're trying to build—are you trying to build it too big or are you trying to build something into Replit that maybe it's not really meant for?

How well does Replit support deployed apps in production today? Where do you see its strengths, and where do you notice gaps?

Deployment has been pretty smooth. The gap you might run into is the resource management side of it if you have a lot of users on an app. Just estimating the traffic cost—this isn't really a big deal for an internal application, but if you put something in production mode that gets traction and reaches the upper limit of what Replit might be capable of, that could become problematic.

For deployment for internal use cases, it has been smooth. They just put in a feature that allows you to buy your domain through Replit, but I would never do that. I think it's best to always have a separate centralized domain registrar for all your domains.

Do you generally keep apps on Replit once they're live? Or do you migrate to Amazon Web Services or another host? Why?

I've typically kept them on Replit because they're not super high-traffic applications, and it's not worth the effort to set up an AWS instance that is configured precisely for that tech stack and has another database and all that. There is potential to push directly to Git or GitHub from Replit, which is helpful, and then maybe pull that in somewhere else.

At the end of the day, unless you need some super robust scalable framework that Replit doesn't handle from a traffic perspective, I think it's better to just keep it on Replit, and the cost is fairly nominal. If you're getting into a high-traffic application, that could be a different scenario, but I haven't encountered that yet.

Tell us about the strengths and weaknesses of Replit in terms of infrastructure features that support created apps, like deployment, hosting, scaling, security, and authentication.

For authentication, they have Replit Auth, which is interesting although really kind of useless for a public application or even an internal application—I don't want people to have to mess with Replit Auth. You can ask it to put in a more advanced auth system, which does work pretty well. You're better off dictating exactly how you want the app to work. Is it functioning off a username, an email? You need to give it more specific direction.

In terms of publishing, that's really straightforward. You're basically just picking if it's auto-scale, dedicated servers, and all that. You can scale up those servers or machines and the CPU and RAM associated, which is helpful. The command it's running to actually deploy your system is all pretty straightforward and in the background, so someone doesn't need to be an expert in DevOps. Adding a domain is also pretty straightforward. It definitely simplifies the process of deployment.

How far has Replit spread across your organization? Which functions within Batch Data have adopted it and which have not? Why do you think that is?

For Batch Data, it's predominantly marketing and revenue operations—basically sales and marketing use cases. There's some amount of analytics use, but not as much. Product has not adopted it because they use more of an IDE like Cursor or GitHub Copilot. I don't think they're as interested in a solution like Replit. Our technical cofounder has experimented with it, but nothing at an operational level.

Why haven't they adopted it? Developers can be of the mindset that they don't need it, which they may not. They're used to just developing things. The product manager is actually a pretty good fit for this kind of product, which is when you get into people who are technical marketers or technical operations people—they fill that kind of product manager role.

I would find it hard to see someone in sales using it because of the nature of their role. They have to be hyper-focused on doing sales and not tinkering with building software. If you had a technical person in HR or finance, they might use it as well, but there are a lot of other tools out there for them.

How do you measure return on investment for Replit? What signals matter most to you?

I look at what it would cost to buy a solution that we could build internally. Very basically, if I take a CPQ that hooks into Salesforce, I'm spending at least $50,000 a year. If I can build it for a thousand dollars, that would be great.

With any software you buy, there's integration time, overhead to maintaining it, and you're subject to the whims of the software company. If they change something and it breaks, that's a problem. So there's the ability to build it internally for a small fraction of the price—that's a win on ROI. Then there's the ongoing maintenance. For a CPQ specifically, there's the ability to create and push more quotes to get us more deals.

For marketing use cases, you might be able to function with fewer people or improve your marketing presence in a way that wasn't possible before because you were missing a tool set that doesn't even exist or that you can't justify buying. Those are some of the ways I think about the ROI.

Based on that, what has been your experience with pricing changes, like usage-based pricing and checkpoints?

The recent changes to more meter-based pricing versus what I think was 50 cents per agent action make more sense, especially with LLM usage. Everyone has to spend more credits fixing problems. If I say, "Create a web form," but in the process it messes up the styling on the page, and then I have to say, "Now fix the styling on the page," that web form costs more. I understand it from a business perspective, but it's more frustrating from the standpoint of how it goes about actually improving it.

They also just announced a feature that will test your app for you. The implication of that has yet to be seen in terms of how it might lead you to spend a lot more on credits or burn through credits quicker. But ultimately, all of this is much cheaper than actually having to hire a developer to work on the thing you want.

Where does Replit clearly win versus legacy or alternative workflows and processes? Where do those still have an edge?

Versus legacy methods (someone hand-coding from scratch), the time for them to do that is enormous by comparison. You'd also need to involve a UI designer, which takes a lot of time too. Replit wins on time savings alone, but also in being able to create an MVP very quickly. Going into a presentation instead of explaining the thing you want to do, if you're able to have a working prototype which you could get very quickly (within 5-10 minutes depending on what it is), that's fantastic. From an executive level, you're getting to sell your idea in a much more concrete way.

Versus alternatives, it depends on the technical ability of the person. If you're using an AI IDE like Cursor or GitHub Copilot for generative coding, you may be less susceptible to bugs with those alternative methods where engineers are still primarily in the driver's seat but AI is helping them be more productive. That's probably still the preferred methodology versus having Replit build out a whole production-level application for an established company. It really comes down to who is using it and how they're using it—those are big distinctive factors.

If you had a magic wand, what would you improve first to make Replit more valuable at your organization?

I would have it not make any mistakes. That's the easiest one.

The other improvement would be the ability to dictate the UI design. They just came out with a feature called themes, so you can be more specific about how it chooses themes. There's a growing sentiment that a lot of these tools feel very similar, and having a more diverse design edge would make it better.

The last thing would just be the predictability of cost if you deploy something and get a bunch of traffic—that would also be helpful.

Over the next 12 to 24 months, what will determine whether you keep Replit, expand your contract, or migrate to another platform?

People using the apps that we develop in-house is really important. Also ensuring that security is maintained is another key factor we want to make sure it keeps up on.

Can you give an example of an app or agent you've built that unlocked unexpected value? Something where you thought it might be small, but drove surprising impact?

The CPQ is the best example of that, but another one is that I used Replit to build a copycat version of a product we already had to illustrate how easy that business was to replicate. That was making an entirely different case than using an actual application. Ultimately, it helped make the point that we need to be more innovative in what we're creating. If I can replicate one of our products, then so can others.

It also allowed me to think outside the box. Often when you buy software, you're stuck in the world of that software and limited by whatever support they give you. Usually you have feature requests that are "on the roadmap"—they may be one month out, they may be one year out, and you just don't know. If an application you're using has an API, and you're able to extract that information into a tool you're building on Replit, you can do so much more, and that's where it really gets interesting. It's all a matter of the data you have, the data you need access to, and how you need to manipulate and present that to the user.

What template or starter project would save your team the most time right now if it existed in Replit?

Analytics dashboards are really helpful for tapping into different data resources—like a BI (business intelligence) dashboard. A lot of places use Tableau, and Tableau is very slow and requires an expert to use effectively. The ability to self-serve data in a way that isn't incredibly expensive would be really helpful.

I could also talk about Model Context Protocol (MCP) if that would be helpful.

Sure. Go ahead and share about model context protocol and how that shows up in your experience.

There are two ways you can build an MCP. There's a local version, where you create a server locally, install a script there, and can access services like Claude.

I think a lot more people are going to try to use remote MCPs. That's where you can access the functionality of an MCP by logging into a service without having to run it on your computer. That's a much more user-friendly approach—not many people are going to be able to install custom packages and scripts on their computer as it's too technical.

We tried building an initial version of our MCP through Replit, and it was difficult for Replit to truly build it out the way it should have. It struggled with that, and this was very early in the MCP's history. But ultimately, if that's something Replit can help companies build out quicker, it could be a huge win. It helps them monetize their data and products in a manner that is superior to other methods out there.

Anything else you'd like to add?

Replit for marketing is actually quite powerful. You can set up landing pages very quickly and create marketing tools very quickly. The ability to embed those tools from a native feature would be really powerful. That's something I don't think Replit has quite grabbed onto yet—embedding these tools on a website. Everything is always published as a separate service, which makes sense, but the ability to actually embed a tool would be quite significant.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.