What you really need to implement in an MVP
When the list of requirements starts looking like an Amazon specification
Collecting acronyms like GPSR, DSA, GDPR, BDO, DAC7, P2B, accessibility, and 30-day price history in one place can easily lead to the conclusion that a small marketplace should build Amazon-scale infrastructure from day one: a separate complaint panel, a terms acceptance register, a product withdrawal module, a document repository, an elaborate product form, and its own seller verification system, all before the platform takes its first order.
That scope usually comes from conflating two things: the outcome the regulations require you to achieve, and the target architecture of a large platform. Regulations typically say you must be able to demonstrate, provide, find, block, transfer, or resolve something within a given timeframe. They rarely specify which database table it should live in or what the admin screen should look like.
In the previous article I covered the broad landscape of marketplace obligations in Poland, from GDPR through consumer rights to seller verification and payment security. I will assume you already know that and answer a different question here: how to translate those obligations into a reasonable MVP, without designing infrastructure for millions of listings. The full operational guide which I promised, organized by chapter, is available at appcrates.pl/marketplace-guide. Here I focus on a few places where the architectural decision carries the most weight.
IMPORTANT. This material is purely informational and educational. It presents the author's interpretation of general requirements and possible implementation approaches. It does not constitute legal, tax, or individual platform or product advice.
The principle that simplifies the entire project
For each requirement, it is worth asking five questions.
- Does this obligation apply to me right now? Some obligations depend on the platform's role, the seller's status, the product category, or the size of the business.
- What outcome do I need to achieve? For example, reproduce the terms text, accept a product report, identify buyers, or demonstrate a price history.
- Does the existing system already store the required information? Often yes, in an account, order, ticket, file, log, or in Stripe.
- What is missing for a credible record? Usually a version, timestamp, status, link to a listing, or change history.
- When will manual handling stop working? That is when a separate module and automation become justified.
If information has a stable identifier and creation timestamp, is not silently overwritten, and can be searched and linked to the right person, listing, or order, it usually suffices to extend the existing process by a few elements. There is no need to copy the same data into a separate compliance table to make it look more serious.
Terms of service: a version record without a separate compliance table
The platform must be able to demonstrate which terms were shown to a user and which version was in effect at a given moment. The law requires this, but it does not specifically require a terms_acceptances table or copying the full text of the terms into every order. A fuller description of the documentation obligation is in the previous article; here the point is how to record such proof without growing the data model, which I also develop in the documents chapter of the guide.
Each version of the terms can be preserved as an immutable file or CMS version, with its own identifier and effective date. An account or order then stores only the version identifier and the acceptance timestamp, and after a terms update the old text remains reproducible. If the account history already logs events, the version identifier can be added to it. If an order stores a checkout snapshot, the same mechanism can be used. A separate table becomes necessary only when the existing structure overwrites data or cannot reliably reconstruct the event.
It is also worth separating terms acceptance from marketing consent. The first is a statement tied to a contract; the second must be voluntary and revocable. A single mandatory checkbox should not handle both at once.
Seller onboarding: data from Stripe does not have to enter your database
A small marketplace often uses Stripe Connect or a similar solution. The payment provider runs the payment onboarding, verifies identity within its scope, and stores the payout account, as I described in more detail in the previous article, in the section on seller verification.
The marketplace still needs to know who is selling, what their status is, where they operate, what products they offer, and what role they play in relation to the product. A seller's bank account is still part of verification, but verification does not mean copying the full IBAN and KYC documents into your own database. In a simple model the platform can store the Stripe account identifier, the onboarding completion status, the status of payment and payout capabilities, the basic company data the platform needs, and the tax and product data that Stripe does not collect in the required scope. The full account can remain with the payment provider if the operator does not need it for a specific obligation of their own. Under DAC7, the account identifier is reported to the extent it is available to the operator, so collecting the IBAN solely to make it available is not necessary.
The scope of DSA obligations concerning business traceability may change as the platform grows. This is a good example of a requirement that should have a clear scaling threshold, rather than burdening every bootstrap from day one. The full process, including who to allow to sell at all, is described in the seller onboarding chapter of the guide.
A product card does not need a hundred fields
GPSR requires an online listing to contain specific information about the product, the manufacturer, the EU responsible person, and safety. This does not imply a universal form with weight, dimensions, composition, capacity, batch number, and CE certificate for every item. A more detailed description of the obligation is in the GPSR chapter.
A sensible form has two layers. The common layer covers a few elements needed for a typical physical product: name and photo, product identification, manufacturer, the EU responsible person if required, and any existing warnings or safety information. The category layer appears only after the product type is selected, described further in the category gates chapter. A cosmetic may require INCI and a responsible person; a toy requires CE-related information and warnings; food requires composition and allergens; a ceramic mug requires information appropriate to food-contact materials. A candle seller should not see a form designed for electronics.
A label photo can partially suffice, since a legible photo conveys composition, markings, and additional instructions. The most important data, manufacturer, responsible person, identification, and significant warnings, are better shown as brief text on the page too, so they are visible on a phone, accessible to a screen reader, and searchable.
Handmade items do not require inventing a factory batch number that does not exist. A one-of-a-kind painting, mug, or piece of jewellery can be identified by name, maker, year, and a unique item number. A used or vintage product needs a different path than new goods; the word vintage alone does not turn an ordinary used appliance into an antique.
One form can handle support, GPSR, and DSA
A contact point for authorities does not require a separate portal for officials. The simplest solution is one public contact page, one ticket backend, and a few clear case types: technical support, return or complaint, product safety, illegal listing or content, public authority or order.
For authorities, an alias such as safety@yourdomain.com or legal@yourdomain.com can be published, routed to the same inbox and the same table as regular tickets. What matters is that the contact requires no account, is kept current, leads to a person, and is properly handled. The GPSR contact point details also need to be submitted when registering the platform in Safety Gate.
For a product report, useful inputs are a link or listing number, a description of the risk, contact details, and an attachment. DSA additionally requires information allowing the alleged illegality to be assessed, and a statement from the reporter that they are acting in good faith, which I describe further in the DSA moderation chapter.
If every request in the system already has a UUID, that is the case identifier. There is no need to create a second numbering scheme just because a ticket was categorised as GPSR. The UUID should appear in the email confirmation and allow the content, timestamp, status, decision, and communications to be retrieved. A dedicated safety panel starts to make sense only when a single withdrawal covers many listings, batches, sellers, and teams, and the regular queue can no longer guarantee deadlines.
The buyer list can also be a query
When a product turns out to be unsafe, the platform must be able to establish who purchased it and communicate the relevant information. This does not require maintaining a permanent separate copy of a buyer list for GPSR purposes.
If order lines are linked to a product or listing, the platform can search for the relevant orders, export the result, and send a message. For products with batch numbers, storing the batch number is worthwhile; for one-of-a-kind handmade items, the identifier of the specific listing or item is enough. More on the obligation to identify buyers in a product withdrawal is in the GPSR chapter.
A useful test is checking whether, within a few hours, it is possible to trace from a product to the seller, all listings, and all buyers. The absence of that path typically comes from inconsistent links in the basic order model, less often from a missing dedicated withdrawal management panel.
BDO: status and role first, number second
A BDO form that asks every seller for their registration number and blocks the account if the field is left empty is simple technically, but does not match the actual scope of the obligation.
The first step is distinguishing between occasional private sales, unregistered business activity, a registered entrepreneur, an importer or entity placing a specific product group on the market, and an entity packaging and placing a product in packaging. A private individual selling their own used item does not automatically become a BDO-obligated entity. Someone running a properly conducted unregistered business is in a different position than a registered entrepreneur. A craftsperson-entrepreneur who packages their own product in a box and ships it to a customer may have packaging obligations despite small scale.
An MVP implementation is a status declaration, a few questions about imports, packaging, and product group, and a BDO field triggered only when the answers indicate such an obligation. The result of verifying the number can be saved in the seller profile. A packaging mass calculator is not needed immediately if the platform does not run its own fulfilment. A fuller description of thresholds and packaging obligations is in the BDO and packaging chapter.
DAC7 can start with a controlled export
DAC7 requires seller data, transaction aggregates, and annual reporting, but a full tax dashboard does not have to be the platform's first feature.
With a small number of sellers, a controlled process is a reasonable start: identity and tax data come from the seller profile, transaction and refund data from orders and Stripe, a reconciled export is reviewed quarterly, calculations follow a recorded method, and the final report, dispatch confirmation, and seller notification are archived.
A spreadsheet works well on its own if it has an owner, a version, change control, and the ability to reproduce calculations. Without those elements it becomes a risk, because manual reconciliation starts generating omissions or misses deadlines, and then automation is needed. The full reporting process, including deadlines and data scope, is described in the DAC7 chapter.
Security: protect what you control
If changing the payout account happens exclusively on Stripe's hosted screen, Stripe secures that operation with its own authentication and step-up verification mechanism. The platform does not need to replicate that screen or store the account just to add its own MFA. This section extends the general technical security checklist from the previous article with a concrete breakdown of what actually falls on the platform operator's side.
Local operations that can cause harm still need protection: the administrator account, role and permission changes, seller account ownership transfers, linking or changing the PSP account association, bulk price and listing changes, and removing or restoring a blocked product.
For a small platform, the minimum is MFA for administrators, restricted roles, updates, secure secrets, a log of significant changes, backups, and tested recovery. Monitoring can initially mean provider alerts and a daily review of the most important events, without building an in-house security operations centre. The supply chain security picture is similar, since it is primarily about hosting, cloud, payment provider, email, helpdesk, analytics, and software. A seller's courier becomes a full operator process only when the platform itself arranges delivery or fulfilment. The full scope of cybersecurity and NIS2 obligations is described in the dedicated chapter.
What really needs to exist before the first order
Before launch, a few working fundamentals matter: clear information about who is the seller for each item, a correct checkout with the full price, marketplace payments handled by the appropriate PSP, versioned terms with proof of acceptance, a product form with the required minimum and category gates, one ticket form with UUID, the ability to block a listing and find related orders, a withdrawal and complaint process with deadlines tracked, a decision on who is covered by BDO and DAC7, and the basics of GDPR, cookies, security, and retention.
Each of these points can be simple, as long as it actually works. A clause in the terms does not replace a field that needs to be visible before purchase; a checkbox without a version record does not create proof; a form no one reviews is not a procedure; and a backup that has never been restored is only hope. The full pre-launch checklist, in a point-by-point format, is in the go/no-go chapter.
What can wait until scaling
For a later stage it is usually possible to defer a dedicated GPSR case panel, automatic detection of similar listings, a separate complaints module if regular tickets meet the deadlines, a DAC7 dashboard if the controlled export is complete, a retention engine if a small database is handled periodically and correctly, an in-house KYC system when Stripe handles the relevant scope, an elaborate category rules engine as long as a manual checklist is reliable, and a central compliance panel if saved queries and a periodic report surface all gaps.
The threshold is straightforward: you extend the solution when the current process ceases to be reliable, misses deadlines, fails to provide the right permissions, or a new legal threshold expands the scope of obligations.
A compliant marketplace does not have to look like Amazon
The most important capability at the start is separating three things: what the platform must do right now, what a seller or a provider like Stripe can do instead, and what will only become necessary after growth, entry into a new category, country, import, or fulfilment.
A well-designed MVP fulfils requirements with the simplest solution that produces a credible result and a record of it. The platform can launch without technical debt born of chaos, and without the cost of infrastructure built for a scale that does not yet exist.
The full operational guide, with chapters covering GPSR, DSA, GDPR, BDO, DAC7, P2B, accessibility, payments, pricing, cybersecurity, and four marketplace models, is available at appcrates.pl/marketplace-guide. If you are building such a platform and prefer someone to implement these processes rather than translate them from regulations, see the marketplace build service.
Sources: GPSR, Regulation (EU) 2023/988. DSA, Regulation (EU) 2022/2065. GDPR, Regulation (EU) 2016/679. Polish Ministry of Finance, DAC7/DPI. BDO, official service. UOKiK, consumer rights and platforms.