Can you vibe-code an online marketplace?

Vibe coding is an exciting development, but it's not a viable way to build and run a real online marketplace business. I know this because I spent 60+ hours trying.

In vibe coding, the person developing the application describes what they want to build to a large language model, which then generates the required software code. The person developing the application doesn't need to edit or even review the code, which means this method of building software is also available to people who don't know how to code.

In this article, I’ll share a summary of what I learned in my experiment: what I was able to achieve (a demo that genuinely impressed my colleagues who’ve been working with marketplace technology for 15 years) and what I wasn’t (a platform I could launch as a business and use to reliably process real people’s money).

Before I begin, a bit about me so you can assess how closely my experience might map to yours: I'm Sharetribe's Chief Marketing Officer, so I believe I know more than most people about marketplaces. I’ve worked at Sharetribe for the past 10 years, run a marketplace podcast, and have a side hustle advising early-stage marketplace companies. I've also worked a lot with software developers during my 20-year career in tech, sometimes in the role of a product manager that specs projects for engineers and designers and reviews their work. I consider myself relatively technical compared to an average person, but I don't know how to code nor reliably review the actual code written by someone else. However, I have successfully built several simple internal apps and automations with AI coding assistants, as well as some simple hobby projects, such as The Marketplace Library.

If you’re considerably more technical than I am, it’s possible you might not get entirely blocked by all of the same issues I was—especially as in this article, I’ll also share the key aspects that make marketplaces complex so you can plan your process around them. On the other hand, if you’re a non-technical founder and know less about marketplaces, it’s likely that most of these challenges will emerge on your vibe coding journey as well.

The rise of AI is making the development of custom software significantly faster than before in two main ways:

• Helping people who know how to code be significantly more productive
• Letting non-developers create code through prompting (ie. vibe coding)

Nearly every developer uses AI today, at least as an assistant to ask questions about their codebase and brainstorm ideas. More and more, developers also take their AI use a step further, generating a part or even all of the code of their applications with AI. When all of the code is generated by AI, the role of the developer is to design the software architecture, review the code and make corrections if needed, and guide the AI in the right direction.

Our team at Sharetribe uses all these tactics to increase productivity. And if you hire a Sharetribe Expert to customize your marketplace with code, they will most likely use AI heavily in the development process. We've even seen them complete Sharetribe customization projects, without writing any code themselves, simply by prompting AI.

Second, there's the approach this article is about: vibe coding. While experienced software developers might use vibe coding too in some of their projects, what makes it particularly interesting is that it's also available to people who don't know how to write code. This means vibe coding could radically democratize software development.

Everyone who’s worked on a marketplace (as we have at Sharetribe for the past 15 years) will immediately tell you that a marketplace is one of the most complicated types of software applications to build and run. The complexity boils down to five key aspects:

1. User generated content
2. Interaction between users
3. Multiple user types and interfaces
4. Online payments
5. Holding money on behalf of other people

This means marketplaces pose an interesting challenge for vibe coding: if you can prompt your way to launching and running a marketplace application reliably without any software knowledge, there’s little else vibe coding wouldn’t be able to achieve.

Next, a bit more on why the five aspects need to work as they should, and why they might pose issues to vibe coding.

In simple applications, there's only one user, and they only use the application privately. A good example of such a simple app type is a to-do list. In contrast, on marketplaces:

• There are multiple users
• All the users generate content
• All (or at least most) of the content is public.

This difference alone multiplies the requirements for the application. Also, with multiple users who likely use your marketplace across all sorts of different devices and browsers, there’s more work needed to ensure the experience is flawless beyond testing it on your own browser. All of this likely means considerably more time for the founder speccing, planning, and testing their ideal user flow, but it’s nothing vibe coding tools would be inherently unable to handle.

The more difficult challenge arises from the security risks and compliance requirements user-generated content creates. For marketplaces to work well, signing up as a user and generating content needs to feel relatively effortless. This opens a great opportunity for attackers to abuse the marketplace for their purposes: spam is an issue we help founders with on a regular basis at Sharetribe.

User accounts with rich personal information also mean more compliance requirements stemming from regulation such as the GDPR. As you’ll learn later, these are areas where I quickly encountered problems in my vibe coding experiment.

Interaction between users adds to the UX requirements of a marketplace, but again, the main challenge presented by this functionality relates to security. A common attack against marketplaces is creating fake user accounts and using them for all kinds of malicious purposes, from sending malicious content to stealing email addresses and passwords to outright scam or money-laundering attempts through fake listings, phishing, or using stolen credit cards.

Again, the issue is particularly challenging to tackle on marketplaces because while preventing attacks is important, marketplaces also need to make user interaction smooth and effortless to offer their users a great experience. The combination requires a high level of expertise on the technical web security best practices and a deep understanding of the UX trade-offs that are and aren’t acceptable for enhanced security.

In a social networking application or a community forum, there’s often only one user type. Everyone has the same user rights and the same user interface.

Meanwhile, marketplaces are two-sided: there's supply and demand. The two sides might need very different user interfaces with different features to reach their goals. Most marketplaces operate as both web and mobile applications, so the two interfaces need to be built for each side. Or, it’s possible the vendors only need a web application while the customers need a mobile app, or vice versa.

Crucially, a marketplace also has a third user type: the marketplace admin. They usually need a complete user interface of their own where they can monitor and manage the marketplace, from users to content to transactions, even configuring aspects of the application.

This adds significant complexity and time investment to any method where you need to build everything from scratch.

Online payments are complicated regardless of context, but what increases the challenge on marketplaces is that the payments happen between users, not from a user to the app.

Security is once again the key challenge: payments between users create opportunities for malicious actors to steal payment information or try to make fake purchases. This is why applications that process payments from customers have strict compliance requirements in various countries, from strong customer authentication to accessibility. The challenge for someone vibe coding a marketplace from scratch is knowing the compliance requirements that apply to their situation, on the one hand, and understanding the UX needs that make payments feel smooth, secure, and reliable for the users, on the other hand.

A crucial complicating factor in marketplace payments is that while the customer of an online store usually doesn’t need too much additional convincing to trust the store they use, marketplaces require users to trust each other.

This is why most marketplaces need a trust mechanism where they hold the money paid by the customer until the provider has delivered the goods or services. This feature is called delayed payout or escrow.

Holding money that belongs to someone else is a heavily regulated area where each country has their own specific legislation. A security aspect is also necessary to consider, because delayed payouts make marketplaces useful for malicious actors for money-laundering through fake purchases.

I had an advantage going into my experiment because I knew these complexities upfront and was able to plan around them from the start to give vibe coding the best possible chance. Next, I’ll summarize what I found out.

At Sharetribe, our purpose is to democratize platform ownership. To reach it, we build marketplace software that lets founders launch, run, and grow their business reliably. While the promise of vibe coding threatens a part of that value proposition, if it came true, embracing it could significantly speed up our work towards reaching our purpose. So to be completely honest, when I started my experiment to build a rental marketplace entirely through vibe coding I was feeling equal parts excited and anxious.

To learn, we conducted several experiments where we used a few of the most well-known vibe coding tools of 2025, such as Replit, Lovable and Bolt.new. All three use Claude by Anthropic as their underlying AI model, so the core AI capability was similar across tools.

Most of the findings in this article are based on the most recent experiment conducted in Nov-Dec 2025, where I spent a couple of weeks building a prototype of an Airbnb-like peer-to-peer marketplace for renting saunas from other people.

My conclusion after these experiments is that while vibe coding produced a working prototype so impressive that it took many of my Sharetribe colleagues by surprise, it wasn’t yet able to give me a launch-ready app to which I could confidently invite real users to transact with real money.

This might change in the future. AIs evolve fast, and it’s possible that many things that weren’t possible in December 2025 will be possible by June 2026. I’m planning to repeat my experiment again in the next few months, possibly in a more structured manner where I guide several vibe coding tools through identical steps of building a marketplace, and I look forward to sharing the results of that experiment as well.

As in this first trial run my approach was more iterative, it felt most useful to summarize my findings into what worked and what didn’t. First, my thoughts on where vibe coding truly excels.

Vibe coding is addictive, in the best possible sense. It has several real benefits compared to anything we've seen before, especially for non-technical founders. It’s a lot easier and faster to get an idea turned into a prototype that others (such as developers and designers) understand. You can quickly iterate on your ideas because seeing them in a prototype often reveals gaps in your thinking or inspires ideas you hadn’t previously thought about.

I believe any marketplace founder would do well to use vibe coding for:

• Prototyping
• early design exploration
• describing requirements to a developer.

It will certainly be a tool in my toolbox for all these purposes from now on, and the improvement it offers compared to the old ways of wireframing and writing briefs is nothing short of transformative.

Any good vibe coding project starts with a great prompt. As I had already tried this several times before, I had a comprehensive prompt ready (which I'll paste below). Writing a strong prompt is where much of the real work happens, and the quality of your prompt shapes everything that follows.

Based on this prompt, the tools were able to spin up an initial prototype that looked promising and good.

I would like to create an online website/app, that allows people to rent each other's saunas. Kind of like an Airbnb for saunas. 

There are two different users, renters and providers, as well as as me, the admin of the entire platform. 

Renters should be able to: 
- look for saunas based on location 
- get an overview with details and a map to see the location, 
with prices on the map get more details per listed sauna and amenities 
- find availability 
- make a booking and possible amenities 
- make a pre-payment with a credit card (using Stripe) 
- send a message to providers 

Providers should be able to: 
- post a listing
- upload pictures and details etc. 
- set a price update availability on a calendar so that renters can see it. 
- accept and deny bookings 
- receive money on their bank account 
- send to and receive messages from renters and other things you might think are useful 

As an admin, I'd like to: 
- see which listings, users and transactions are on the platform
- have the ability to message all users 
- have the ability to ban users 
- receive a commission fee from each transaction 

Also, regarding the payments: it should have some kind of delayed payment function, 
so that renters have to pay beforehand but the providers only receive the money, 
minus my commission (set initially at 10%, but should be able to change that) 
after the renters have used the sauna (so money gets released 24 hours after the booking). 

Any questions?

While “works great as a prototyping tool” may sound dismissive given the grand promise of vibe coding, being able to easily create a working prototype of something as complex as a marketplace app can be extremely powerful in the early stage. Especially if your idea is complex or you're not quite sure what the right solution should be.

Furthermore, with so little work to get the first prototype working, you can quickly churn out several different versions of your idea and share them with others for feedback.

With these benefits, I’d argue it’s a good idea for anyone looking to build a new software product (assuming it has a visual element) to start their work by quickly sketching out a few versions by vibe coding them.

In the old world, such prototyping was done by wireframing and design tools. Compared to these approaches, being able to quickly create an actual working prototype that is able to store and retrieve data based on your actions is truly next-level.

Vibe coding tools let you explore color schemes, layout styles, and UI structures based on written prompts. You can, for example, ask the system to “create a minimal landing page with soft colors and a pricing section,” or to “add a clean product gallery with filters.” This helps founders refine the look and tone of their marketplace without touching design software.

But a word of caution: while tinkering with the design is a lot of fun, focusing too much on the visuals is often not the right thing to do in the early stage (unless aesthetics are deeply important to your target audience, which could be the case e.g. for a platform for fashion experts or designers), and it can derail you from your main focus of validating the merits of your idea as quickly as possible.

Even if you end up working with someone who knows how to code to build the actual application (we'll get to why you might want to do that in the next section), vibe-coding the initial prototype can be a great way for you to communicate to them how you'd like the application to work. Instead of providing a written spec, you can show something that actually works exactly the way you want it to.

I was able to iteratively build a marketplace prototype that worked and retrieved data. So, why is it that I claim I wouldn’t be able to reach a minimum viable version I could launch to real users?

The main reasons boil down to time to launch and reliability. More on these challenges next.

In its entirety, my vibe coding experiment took over 60 hours, after which my marketplace application was ready for an end-to-end demo to my colleagues. I also shared it with several colleagues (technical and non-technical) for deeper testing.

Many of my colleagues were truly impressed by what I showed them. The standard marketplace user journey worked well, and even the first challenging exceptions (“Can you show if the booking calendar updates correctly if the customer cancels the booking after the provider has already accepted?”) worked like a charm.

Unfortunately, a closer look at how things work under the hood and the issues revealed in my colleagues’ tests revealed several critical issues in the core flow, which meant the app didn’t actually do its job in making transactions between people possible.

After all the feedback from my colleagues, my estimate was that it would take at least 100–200 hours to get to a state where all the known bugs were fixed and I could start to consider going live.

Much of that time would go into debugging issues the AI created. In one of my experiments, the AI agent marked core features from my requirements as completed early on, including listings, availability, and bookings. But when we tested end to end, several basic actions failed. Listings couldn’t be edited, time slots couldn’t be added, booking couldn’t be entirely completed.

Upon further inspection, it turned out these failures traced back to missing connections between features that need to work together as a single transactional system on a marketplace. To the booking flow of my sauna marketplace, repeated fixes were needed due to abandoned pending bookings, race conditions, and premature time slot locking.

There were even critical bugs in payments that would be devastating for the user experience if they ended up in the live version. For example bookings repeatedly reached a “confirmed” state while payments stayed pending, which broke the cancellation logic. In other cases, a Stripe payment succeeded on the backend but the interface showed “processing” because webhook updates were missing or payment intent handling was incorrect.

Even more challenging than repeatedly fixing numerous visible bugs was that each fix revealed another dependency tied to availability, payments, or booking state. After one change I made, a colleague testing the marketplace pointed out that I had accidentally broken two features that had previously worked: location search and availability management. I hadn’t even noticed they were broken.

Perhaps the most frustrating thing about the experience was the AI declaring issues fixed without them actually being fixed. Throughout my most recent experiment, the agent declared "Fixed!" dozens of times. After one particularly stubborn booking error, the AI declared the issue fixed seven consecutive times. Each time, I tested and hit the exact same error. A user notification system went through sixteen iterations of "Fixed!" before notifications actually appeared. This pattern of confident false victories was one of the defining experiences of my vibe coding journey: you report a bug, the AI assures you it's resolved, you test, and it's not. Without the ability to read and verify the code yourself, you have no way of knowing whether "Fixed!" actually means fixed until you test every single thing again.

I stopped after 60 hours, not because I gave up, but because the pattern was clear: each fix created new problems faster than it solved old ones. And if I were launching a real business, I wouldn't have another 200 hours to spare.

I also can’t shake the feeling that for an average founder, 60 hours for a demo and 100-200 hours to fix bugs is actually too optimistic. Given my background, I was able to give the AI really specific instructions based on my knowledge of marketplaces. An average founder working on their first marketplace doesn't have this background.

Knowing that tools exist that can get my business idea live reliably, without bugs, in a matter of days (and I’ll shamelessly plug Sharetribe here), this considerable time investment also seems to not gain me anything. Especially when I know I can later expand on that platform as much as I want with custom code.

So all the fixing and refixing bugs would only slow me down on what actually counts: getting my business live in front of real people so I can start growing, iterating, and building my competitive moat.

Finding all the bugs in the basic marketplace logic I first assumed to be working well leads to another, potentially even more severe conclusion: that even if I got my vibe-coded marketplace to a state where I can reliably launch it, I wouldn’t be able to feel confident that I can also reliably run it.

The reality is that vibe coding has made building software cheaper, but not maintaining it. The cost of maintaining software, which is where most of the work and money go in any serious application, hasn't decreased, or at least not as radically. You could even argue that it's higher, because the AI has made architectural decisions you weren't consulted on, don't fully understand, and might not even agree with if you could see them.

This comes down to three things: security, adaptability, and performance.

In one of the tests on the demo, an engineer colleague discovered that the AI had failed to add protections to the checkout flow of the marketplace. This meant that any user with some technical skills could call the API directly, change the transaction price, and, for example, book an expensive sauna for one dollar.

The reason this got me worried wasn’t so much that this single bug was discovered—I’m relatively certain that with a bit of research and more careful prompting, I would have been able to fix it.

What did worry me is that even with my understanding of marketplace risks and best practices, I wouldn’t have been able to find this vulnerability in the code if I didn’t have access to a senior engineer with years of experience coding secure marketplace platforms. It wouldn’t have come up in basic end-to-end testing: nothing was broken in the core marketplace flow I could have spotted that would have traced back to this vulnerability.

So if this crucial bug slipped by me, how many others are there? It would be completely impossible, at my level of technical skills, to know if the code created by AI protects my users from attacks.

Attacks against marketplaces are more and more common these days, and, based on our experience, they are increasingly targeting small marketplaces in addition to the big ones, exactly because fraudsters know smaller, early-stage businesses are likely to overlook web security best practices.

I’ve also seen how much time our operations team spends wrestling attackers that target our customers, coming up with new strategies for things like custom API rate limits, IP address-based limits, and phishing message filtering algorithms. And, mind you, this is work they’re doing to combat attacks against platforms built on Sharetribe, which our senior developers have built with full adherence to rigorous security guardrails.

I don’t identify as a particularly risk averse person, much less a perfectionist (all my simple personal websites are now vibe coded, for example), but this experience did get me seriously worried for founders launching marketplaces that handle real money on top of technology they don’t know how to vet for vulnerabilities.

Launching the initial version of a marketplace is only the first step. From there, successful founders constantly adjust, update, and iterate on their product based on what they learn from their users. We’ve seen founders who change their transaction flow with the Sharetribe transaction engine dozens of times over the course of building their business

Based on my experiment, I came to the conclusion that vibe coding has fundamental weaknesses here.

The core problem is that iterative prompting obscures what actually changed and why. For example, I wanted to change the notification logic from user-based conversations to booking-based conversations. In the testing stage, we discovered that this change forced the removal of earlier database constraints I had established. This then triggered a chain of complications I hadn’t anticipated and couldn’t fully trace when I tried fixing them.

Had I understood the consequences up front, I might have made a different call. But the problem is that this type of change is very typical, even routine, for a marketplace. It’s a realistic assumption that I only realize booking-based notifications would work better after seeing real users interact on my platform. If every improvement update carries a hidden risk of unpredictable ripple effects, I might feel blocked from doing the necessary iterating and testing a marketplace concept needs to mature and grow.

At another point during my experiment, the payment system broke. When I reported the error, the agent asked me where I had deployed the backend functions, how I had deployed them, and what environment they were running in. My answer: "How would I know this? You coded this." The agent had built the entire system, chosen the architecture, and even hardcoded a database ID (the wrong one, as it turned out). Yet when something broke, it turned to me for answers about its own decisions.

These aren’t isolated examples. The longer I worked on the marketplace, the more different parts of it fell quickly out of sync with each other. There were functions handling booking logic that were still looking for data fields I had removed weeks earlier in a different part of the system. And the rules controlling who could see and access what data had accumulated so many overlapping layers that they started contradicting each other. I only noticed both problems when something broke. Without the ability to read the code, there's no way to know how many inconsistencies like these are sitting in my system at any given moment.

This connects to a broader structural issue: vibe coding tools make it very hard to maintain separate environments for building, testing, and production. Serious web applications run these three separate instances precisely so that they can safely test changes before they’re published on the live platform for real users. With vibe coding, that separation is difficult to set up and even harder to maintain, meaning changes tend to go straight to the live environment.

When financial calculations are involved, the stakes for getting things right are high. In a marketplace, even a simple transaction has several moving parts: what the customer pays, what you take as commission, what the provider receives, and what the payment processor charges on both the payment and the payout. Plus potential discount codes, taxes, delivery costs, refunds, currency conversions… The math gets complicated fast.

Get any of this wrong, and you may face legal liability. In standard software development, automated tests verify payout logic continuously. I could vibe code these tests to my marketplace app, but without the ability to read and verify the code myself, I’d have no way to know they actually cover everything.

First, a word in favor of vibe coding: there’s a limit to how much early-stage founders should worry about the scalability of their Minimum Viable Platform. In most cases, it’s highly unlikely you get a million new users overnight. Your time is better spent elsewhere than overengineering scalability. So a simple argument that “vibe-coded platforms aren’t scalable” is a bit reductionist.

Yet, when marketplaces work, they can really work. That can mean I could suddenly get into trouble if my architecture can’t handle my growth. I'm doubtful that simply telling the AI to refactor the architecture to handle a bigger load will end well.

As Ben Werdmuller observes in his insightful analysis about vibe coding, " It takes real engineering skill to craft a prompt that will do the right thing and result in a strong architecture.–– To properly architect a system, there’s a lot you need to consider. This includes performance, scalability, and the ongoing overhead of maintaining a project and keeping it safe: nobody wants to rely on software that proves to be slow, insecure, or impossible to update. You also need to assess the technical implications of a project: are there technical standards that the project should be adhering to, or battle-tested best practices that the design should take into consideration?"

Again, the challenge isn’t as much what I know to be wrong, but how much I don’t know. I will have no idea how much traffic my platform can actually take before it can no longer take it. Will it crash or slow down already with 100 concurrent users, or when there are more than 1,000 listings in the database? It's difficult to vibe-code tools that would test your marketplace for things like scalability and performance.

In my experiment, I discovered many ways in which vibe coding can help a non-technical marketplace founder: it's great for prototyping, design exploration, and communicating requirements to developers. I also see endless use cases for it building simpler, less risky things like websites, automations, internal tools, and simple apps. I’ve already created lots of these for both my work and free time purposes, and I could even see myself running a simple vibe-coded niche SaaS application and charging people for using it.

But my conclusion is that marketplaces are still too complex to be vibe coded entirely from scratch by non-technical founders. First of all, it still takes quite a long time and requires significant technological learning, with no clear upside compared to using existing SaaS solutions. Even more importantly, running a vibe-coded live marketplace is risky for issues related to security, adaptability, and scaling.

This applies to founders using Sharetribe, too. Sharetribe's open developer platform lets you extend your marketplace with custom code, and we see more and more non-technical founders applying vibe coding to their Sharetribe marketplaces.

If you vibe code on top of Sharetribe, the good thing is that Sharetribe takes care of 90% of the issues related to running a reliable marketplace: security, adaptability, scaling, and performance. This makes vibe-coding design changes or feature customizations low-risk. Building something more complex (e.g. a completely unique user interface, integrations to third-party systems, or changes to the structure and data model) on top of Sharetribe’s infrastructure still requires technical expertise.

However, if you're a software developer who can review the code, AI can already make you considerably faster at customizing your Sharetribe marketplace. We’re also developing Sharetribe in a direction where even non-developers could do more with AI: using vibe coding for building a unique user experience on top of our reliable marketplace backend where the truly complex parts (payments, trust, security, compliance) continue to be built and maintained by humans.

I conducted my vibe coding experiments throughout 2025. Most of the information in this article is based on the experiment I did in Nov-Dec 2025 with the best models at the time.

But the industry is changing fast. It’s likely that a year from now, many if not most of the things I said in this article about the speed of development and simple bugs AI made will be outdated. I already saw fast improvement in between my first and last experiments: I conducted several, and the last one was the first time where I could get a fully functional demo to hand to my colleagues. The previous versions always got stuck with unresolvable bugs, which just didn’t happen with the latest experiment.

With the more fundamental issues related to reliability, adaptability, and performance, I’m less certain. My biggest concern is security:

The more popular vibe coding tools become, the more they will gain the interest of attackers, who will certainly be figuring out their vulnerabilities and directing their attacks against them. When you're running a business that is operating other people's data and money, you need to either know enough about security yourself or have the backing of someone who does.

But security isn't the only gap. A marketplace that can't handle growth, or where every update risks invisible breakage, isn't a foundation you can build a business on. Real users expect their payments to work each time, their data to be safe at all times, and the platform to stay up always. Meeting those expectations requires either the technical skill to verify your code or a platform built by people who can.

I don’t see vibe coding changing this fundamental dynamic of how running an online marketplace business works. But I'll be the first to update this article when it does. I'm planning to repeat my experiment later this year, and I genuinely hope the results surprise me.

What vibe coding can already change is how founders explore, prototype, and communicate their ideas before they build. And that alone makes it worth every founder's time.