Replit customer at Rokt on internal tool development and cross-team adoption

We spoke with a Replit customer at Rokt who has overseen the platform's adoption across their entire organization for building internal tools and automations.

The conversation explores how non-technical teams use Replit to create dashboards, training exercises, and specialized applications that wouldn't normally be prioritized through traditional development channels.

Key points via Sacra AI:

At a high level, how is Replit used at your organization today? What are the top few use cases?

We use it primarily for building internal tools. The entire organization has access and can use it to create automations and improve dashboards. It's not used for core product prototyping or anything like that. We've extended it across the entire organization so that whatever use cases are relevant to individual teams, they have the opportunity to build something that can make them ultimately move faster.

Could you share more about the types of teams using Replit and some specific examples of the tools or automations they've built?

Every single team across the organization is using it—our internal operations teams, product teams, marketing teams, sales teams, and people teams. Within our people team, they have a learning and development function where they built training exercises and games for people to dispute specific topics. The operations team builds dashboards to create a repository of different SQL queries that make database access easier. Marketing teams are doing things for event sign-ups and event mapping. We've given it to all the different teams, and they have dedicated people building these kinds of tools.

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

The biggest misconception is that people think it needs to be an end-to-end product development tool versus something that handles very bespoke use cases. It doesn't have to be something that's fully formed or fleshed out. It's actually something where an individual or a small team can make their life easier. You might use it for a period of time and then decide that it's no longer relevant. Because you can build so quickly, it doesn't actually cost you a ton to continue to work with it.

Who typically builds on Replit day-to-day in your organization? Are the same people who championed its adoption also hands-on with the tool?

It started within one team that was very focused on automation and more technical integrations. We saw so many benefits inside that team that they became champions across the organization and trained other teams. Now every single person in the organization has access to it. They just have to sign up and say they're interested in building something.

What tools did you consider before landing on Replit? What tipped the decision?

We didn't do a ton of evaluation. We had an early user who built something really effective using Replit, and they started pulling a couple of other folks in, and it cascaded from there. We saw it was solving enough use cases for us, and we worked with their team to help find a bespoke way to roll it across our organization.

Would you say the tipping point linked to that first team's success or did it also come down to something unique about the product itself?

It probably had less to do with the specifics of the product and more to do with the text-to-value or text-to-production opportunities. Had the first thing we used been Bolt or another tool, it might have met our needs just as well. Replit just happened to be there first. There's a long way to go for many of these tools to be enterprise-ready. We've had to force a lot of the management behind the scenes since they're growing quickly and falling into these use cases.

If you had to highlight one area where Replit is strongest for your needs today, and one area where it's weakest, what comes to mind?

The strongest aspect is that we can hand it off to anyone with very little experience. We can train them and give them some best practices, but we really encourage people to just tinker around. Once they have that moment where they can actually do something with these tools, that's probably the biggest benefit.

Areas for improvement are more on the enterprise readiness side—being able to have organization-level access rights and management, and integrating with existing tools. For example, we built dashboards related to our Jira instance and had to build out those integrations ourselves. Connections into other enterprise tools would be very beneficial, so the person building the tool doesn't need to work with APIs directly.

How well does Replit support deployed apps in production today? Where does it feel solid and where does it fall short?

It depends on your definition of production. For internal team tools, it's very solid with not a lot of risk. But if I was building a dashboard for a client, it would take a lot more for me to feel comfortable using Replit. With internal tools, there are always gotchas and edge cases that come up that need to get fixed quickly. Since you didn't go line by line through a set of requirements, there might be things you didn't think about that could pose risks for client-facing tools.

Do you typically keep apps on Replit once they're live, or do you migrate to something like Amazon Web Services?

The tools we're using, we don't have any intention of moving elsewhere. If something was going to be used across the entire organization and we saw tremendous value in it, we might rebuild it inside our core infrastructure to have a stronger and more scalable connection. We haven't really run into that yet because we're trying to solve a bunch of smaller problems with it.

What about infrastructure features within Replit? Things like hosting, scaling, security, and authentication—are these areas sufficiently supported for your needs?

There's obviously some concern within our teams around security risks. The good news is we use Replit's internal authentication for all of our applications. Since they're internal tools, they have to be within single sign-on inside our workspace, so the leakage risk is pretty low. That's one reason we keep it as an internal tool versus something external. From a scalability perspective, we're never going to be touching high-risk scale in terms of server and infrastructure because it's just internal, usually with a couple hundred users.

How far has Replit spread across your organization? Are there any functions that haven't adopted it, or is it universal at this point?

There's at least some usage of it in all teams. It depends on the different problems they're trying to solve. Everybody has access to it. The more technical teams or folks with more technical experience are adopting it sooner, but we're starting to see use cases across other teams and people who may have never touched code before being able to build things.

How does your team measure return on investment for Replit? Are there specific signals or metrics you watch for?

We generally watch to see if the people we give access to are currently using it, and we ask people to share their wins. We don't have a robust system around it. We're very active in using all the tools available to us and over-index on moving quickly. We'll probably evaluate that at a later date, but right now, we see enough value in the things coming up within the organization not to think about measuring it too closely.

Where does Replit clearly win versus traditional ways of getting something built internally? And where does the legacy or alternative process still have an edge?

The biggest win is when it's something that wouldn't necessarily get prioritized if it had to go through prioritization mechanisms and engineering teams. If you have something in a small team where you can make your life easier by a couple of hours per week, that's likely never going to rise to the top of a roadmap for any other team, especially when competing with revenue-generating features. Replit creates an opportunity to build things you would never have been able to get through before.

It also gives people an opportunity to explore something new that they may never have had the opportunity to do before. We talked about training earlier and building games—the only way to try something like that in the past was to identify other platforms with that tool already built. You didn't get a chance to explore on your own or bend it to your specific scenario.

Where it probably loses is with anything that needs to be very robustly rolled out. We're not going to build a system to track all our engineering and GitHub requests with it. If it's already a multi-use tool that fits across the organization, it's not likely something we'll use Replit to solve. If it's something nobody has had time for before and hasn't risen to the top of the roadmap because it doesn't affect enough people, those are the types of things that win with Replit.

If you had a magic wand, what would you change about Replit to make it more valuable to your team?

The thing I'm nervous about is there are great tools that have been built by individuals who went through the process of defining the scope, adopting the tool, and figuring out the corner cases—they know exactly how they got from point A to point B. If that person leaves the company after developing a valuable tool, how does somebody else pick that up easily and know the context?

Historically, an engineer would have access to the codebase, specs, comments in the code, and documentation. But now you just have this AI-driven tool that was created, and if anyone wanted to pick it up, they might not know the underlying architecture of how we got from text to something live.

Are there any examples of use cases where Replit didn't work out or where it started strong but fizzled?

We haven't had any clear failures. I think if I looked at the hundred or so tools that have been built, I'd bet only a handful get continued consistent usage because many were built as exploratory things. They tend to be pet projects that were point-in-time versus more bespoke long-term solutions. Maybe that's a good thing. We haven't made decisions going forward on whether that's the right approach or not.

Can you walk me through just one or two specific apps your team has built and what they do?

Let's use the training example. One thing our team does is create ad copy for advertisements, and we have many rules and policies for those. Our team built almost a Tinder-style training quiz where you could say, "Would this be approved or not approved?" so they could share that with account managers. We created examples, source data, and a leaderboard system, and it's part of everybody's onboarding. That's a great example of something that would never have been built before.

The other example is the Jira dashboarding tool. Jira has a lot of information around various teams and tasks, but their dashboarding flexibility is pretty weak. We've even ported that data into Tableau in the past to build visualizations because it's not what Jira is built for. In our case, we connected to the Jira API, pulled back all the information, and built flexible dashboards on top of it. The challenge is that the queries take a long time and aren't super efficient, and the people building those tools don't know enough about systems to manage caching and queries properly.

What is the rough breakdown in terms of internal versus external apps in your organization?

We're 100% internal. We don't allow any external access to our Replit apps.

Which use cases have been the most durable, staying relevant over 6-12 months? And why do you think that is?

The most durable use case is our dashboard where people can search a repository of different database queries that people have used over time. In many database tools, you can save your own queries and share them, but by creating an easy overview of what queries do, where data is stored, inputs, making it searchable, allowing people to reach out to authors and ask questions—it's one of those little things you would probably never build on your own, but it has clear value across the organization.

There's also some project management for small teams. Those have been durable because once a team shifts to them, they find ways to add features and data points to make it easier, making it more ingrained. What makes tools durable over time is being able to make them fit the exact use case of the team. That's different than most tools where you take something out of the box and try to fit your use case into it. With Replit, you can make tweaks in a very bespoke way as new information becomes available.

Which use cases turn over quickly or stay more experimental?

Everybody has access to the tool, so there are also a lot of personal use cases that get built—like news readers or personal tracking systems. We don't discourage people from doing that because it gets them comfortable with using the tool and learning how to build, but it does lead to a lot of bloat in our workspace.

Have you used Replit more for creating applications versus creating AI-driven agents?

Almost all of our situations today are just applications. We use tools like n8n to build more process automation flows, so we haven't used Replit in the agent approach.

When you pair tools like Replit and n8n together, what's the logic behind combining them?

I think it's about control. In n8n, you have a very specific process. You can go from point A to point B. Whereas Replit tends to navigate in a zigzag manner where you don't really know what you're doing from point A to point B. It gives the user more trust when they can build from a foundation and add to it. There's no tangible reason—it's just how problem-solving exists across our organization at the moment.

Can you walk me through a typical cycle from idea to deployment on Replit?

There's no typical cycle. The general process is that everybody has the tool. Someone has an idea or interesting thing, they play with it, then say "there's something interesting here, let me share with my team." They ask if it's valuable, get feedback, add features, and so on. It's an always-on exploration, not a roadmap of things to build. We might have a roadmap of problems to solve, and one question we ask is whether using Replit helps solve that problem.

How do you handle feedback, testing, or approvals before something gets widely shared with the team?

For most use cases, it's fairly lightweight. An individual inside a team goes to their team members and says, "I solved this problem, I think it could be valuable for the team. Here's access, here's how it works. What ideas do you have?" And it iterates from there.

There are cases where things reach a point where many people are using it, like the SQL query dashboard I mentioned before. It builds over time—imagine it like a wildfire where it starts with one user, they find a few others who find it interesting, and then it spreads quickly. Most use cases are specific to internal teams or organizations, so the scope it can expand into is typically not company-wide.

When it comes to iterating on tools once something gains traction, how do you manage things like versions or change history?

We kind of just let it ride. Whatever the builder of the tool says is best. There have been scenarios where we've accidentally rolled out changes and needed to roll back, but because it's all internal, it's fairly low risk.

What has been your strategy for onboarding non-technical users to Replit? Which approaches have worked best?

The biggest thing has been showing examples to folks where it's been useful. We have channels where people say "I built this, check it out, play around with it." The natural implication is somebody sees something similar to a problem they have, or they see somebody non-technical who solved a problem and ask how they did it. People are excited to talk about the experience they just had with a tool that gave them a superpower they never knew they had. Those feeling-oriented aspects of solving a problem in a way that wasn't possible before drive adoption.

Are there specific moments where users were surprised by what they could create without prior technical experience?

Almost everybody has that moment. I call it the "oh shit" moment with AI—that transition point between being an idea person and being an execution person who can make something actually happen. More than 80 percent of the people using Replit in our organization are folks with very little technical experience.

How predictable are your costs month to month or quarter to quarter for Replit?

We don't really monitor our costs at all right now. We've made a commitment as an organization that we're willing to spend pretty much any amount of money to become an AI-first organization. We'll have to answer ROI questions in the future, but right now, our goal is to drive adoption and see what value we can generate.

In the broader landscape, where do you see Replit clearly outperforming alternatives like Lovable, Bolt.new, Zapier, or n8n?

As a personal point of interest, their marketing seems really good. They do videos of their launches, give context, show examples, and really tell their story. I hear about Replit more than the others, followed by Bolt and v0. I listen to many technology podcasts, so it definitely feels targeted at individuals, solopreneurs, and tinkering enthusiasts from what I've seen.

What improvements or changes would you say are necessary for agent and app building with Replit to become more mainstream inside larger organizations?

I would say three things:

First, templates. Think about it like Notion where you can have templates for project management or dashboarding—a starting point to work from.

Second, integrations. Integrations to data sources like Jira, HubSpot, and Salesforce, allowing you to use that data effectively without having to think about APIs. It should be more like "pick and choose" rather than building the integration yourself.

Third, transition management. For tools to stay durable over time when people change teams, move up in the organization, or leave the company, you need ways to ensure valuable tools can be maintained.

Have you seen any of Replit's documentation or learning materials? Are those currently sufficient?

I don't think I've even seen any of their documentation or learning materials. I've used the agent or assistant to ask questions. Maybe that says something about the opportunity to improve since I've never even looked for them.

What is your IT or security team's current view of Replit's maturity in enterprise readiness? Have they raised specific concerns?

They let it go through the audit, so I think they felt comfortable with the base level of security, things like key management. We evaluated it from the perspective that it's always going to be an internal tool behind Replit's authentication, so there's relatively limited risk other than the code base getting leaked.

In general, our security teams are cautious about all AI tools because of data leakage risks and customer data concerns. I wouldn't say they're confident because they're probably always on edge, but the fact that they let us use the tool is a strong signal.

If Replit offered better handoff tooling like version history or documentation helpers, how far would that go towards solving the transition risk you mentioned earlier?

The documentation piece stands out to me—what is the tool, what steps did we take to build it, what trade-off decisions were made along the way? It's one thing for somebody to take the end state of something and bring it forward, but it's another to understand how certain things were implemented behind the scenes.

There's a big difference between handing off something from an engineer to an engineer because they can dig into it and understand what happens. In this case, if you're handing off from a non-technical user to a non-technical user, they think of it more like a narrative or storyline. They want to understand how we got from point A to point B. They can see what's on the surface, but they don't know what's under the covers.

If you were advising someone trying to launch their own alternative in the text-to-app space, what's the one thing you'd tell them to focus on that Replit doesn't quite nail yet?

Maybe it's not something they don't nail yet, but I'd advise trying all the tools and comparing them. Give a tool to each of the different teams and have them decide and share their stories. One thing we have now is we don't know what we don't know because we decided to build off an individual who found a tool and went through that wildfire approach internally. Maybe Replit isn't the best tool out there and there are things we're missing, but we've effectively decided to go with what we've got.

If someone from your team were to build a template or starter project that would save the most time for others like you, what do you think it would be?

Some kind of internal project management and status sharing tool that was very easy to adapt to your organization. That's probably the one I wish I had.

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.