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 for asking questions about their codebase and brainstorming ideas. More and more, developers also take their use of AI a step further, generating part or even all of their applications' code with AI. When all the code is generated by AI, the developer's role is to design the software architecture, review the code and make corrections as 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 web 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 application requirements. Also, with many users likely accessing your marketplace across a wide range of devices and browsers, more work is needed to ensure a flawless experience across all interfaces. All of this likely means considerably more time for the founder to spec, plan, and test their ideal user flow, but it’s nothing that coding tools can't handle.

The more difficult challenge arises from the security risks and compliance requirements posed by user-generated content. 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 regulations such as the GDPR. As you’ll learn later, these are areas where I quickly ran into problems during my vibe coding experiment.

Interaction between users adds to the UX requirements of a marketplace, but the main challenge posed by this functionality is 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 user interactions to be smooth and effortless to deliver 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 interfaces need to be built for both sides in both web and mobile. It’s also possible that 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 that requires building everything from scratch.

Online payments are complicated regardless of context, but on marketplaces, the challenge increases because payments occur between users rather than 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 trust. While the customer of an online store usually doesn’t need too much additional convincing to trust the store they use, marketplace transactions require individual users to trust each other.

This is why most marketplaces need a trust mechanism in which they hold the customer's payment 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, with each country having its own specific legislation. A security aspect is also necessary to consider, because delayed payouts make marketplaces useful to malicious actors for laundering money 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 reliably launch, run, and grow their businesses.

While the promise of vibe coding threatens part of that value proposition, if it were to come true, we could significantly speed up our work towards achieving 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.

I conducted several experiments where I 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 capabilities were similar across the tools.

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

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 deliver a launch-ready app that 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 over the next few months, possibly in a more structured manner, by guiding several vibe coding tools through identical steps to build a marketplace. I look forward to sharing the results of that experiment as well.

In this first trial run, my approach was more iterative, so it felt most useful to summarize my findings into what worked and what didn’t.

First, my thoughts on areas where vibe coding worked really well.

Vibe coding is addictive, in the best possible sense. It offers several real benefits over anything we've seen before, especially for non-technical founders. It’s much easier and faster to turn an idea into a prototype that others (such as developers and designers) can 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.

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?

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

“Works great as a prototyping tool” may sound dismissive, given the grand promise of vibe coding.

However, being able to easily create a working prototype of something as complex as a marketplace app can be extremely powerful in the early stages. Especially if your idea is complex or you're not quite sure what the right solution should be. In the old world, such prototyping was done by wireframing and design tools. Compared to these approaches, being able to quickly create a working prototype that can store and retrieve data based on your actions is truly next-level.

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 by quickly sketching a few versions and vibe-coding them.

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). In the worst case, 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 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 total, my vibe coding experiment took over 60 hours, after which my marketplace application was ready for an end-to-end demo for my colleagues. I also shared it with several colleagues (technical and non-technical) for deeper testing.

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 revealed several critical issues in the core flow, meaning the app didn’t actually do its job of enabling transactions between people. After all the feedback from my colleagues, I estimated it would take 100–200 hours to reach a state in which all known bugs were fixed, and I could start considering going live.

The bugs and issues fall into two main categories: AI-created bugs, dependencies that introduce more bugs, and issues reported as fixed that actually weren’t. 

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. In 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 payment bugs that would be devastating to the user experience if they ended up in the live version. For example, bookings repeatedly reached the “confirmed” state while payments remained pending, breaking 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 a new dependency tied to availability, payments, or booking state. 

After one of my changes, a colleague 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 times in a row. Each time I tested, I 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 too optimistic. Given my background, I was able to give the AI very specific instructions informed by my knowledge of marketplaces. An average founder working on their first marketplace doesn't have this background.

Knowing that tools exist that can reliably get my business idea live, bug-free, in a matter of days and expand with code later (and I’ll shamelessly plug Sharetribe here), this considerable time investment doesn't seem to have gained me anything. 

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 that 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 tool 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.

During one of the demo tests, an engineer colleague discovered that the AI had failed to add protections to the marketplace's checkout flow. 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 worried me was that, even with my understanding of marketplace risks and best practices, I wouldn’t have been able to find this vulnerability in the code without access to a senior engineer with years of experience building secure marketplace platforms. It wouldn’t have come up in basic end-to-end testing: nothing was broken in the core marketplace flow that I could have spotted and traced back to this vulnerability.

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

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

I’ve also seen how much time our operations team spends wrestling with attackers targeting our customers, developing new strategies such as 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 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 continuously verify payout logic. 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'll get a million new users overnight. Your time is better spent elsewhere than on 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 so much what I know to be wrong as how much I don’t know. I'll 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 straightforward apps. I’ve already created lots of these for both work and free-time purposes, and I could even see myself running a simple vibe-coded niche SaaS application and charging people to use 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 a long time and requires significant technical learning, with no clear upside over using existing SaaS solutions. Even more importantly, running a vibe-coded live marketplace is risky due to issues with security, adaptability, and scalability.

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 involved in running a reliable marketplace: security, adaptability, scalability, 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 to build a unique user experience on top of our reliable marketplace backend, while 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 an experiment I conducted in Nov-Dec 2025 using the best models available 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 the simple bugs AI made will be outdated. I already saw rapid improvement between my first and last experiments: I conducted several, and the last one was the first time I could hand my colleagues a fully functional demo. The previous versions always got stuck on unresolvable bugs, which didn’t happen in the latest experiment.

Regarding the more fundamental issues of reliability, adaptability, and performance, I’m less certain. My biggest concern is security.

The more popular vibe-coding tools become, the more they will attract the interest of attackers, who will certainly be identifying their vulnerabilities and directing 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 every time, their data to be safe at all times, and the platform to always be up. Meeting those expectations requires either the technical skill to verify your code or a platform built by people who have that skill.

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 if 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.