From a Facebook Group to a Listings Portal: What to Build in the MVP and What to Postpone

Plenty of niche markets in the Czech Republic don't have their own website. They have a Facebook group. People post offers and requests there, strike deals in the comments, and it works — until the group grows. Then offers start getting lost, nobody can compare them and the same questions come up every single week.
That is one of the best starting points for a small listings portal. Demand demonstrably exists, you know where to find your audience and you know exactly what frustrates them. In this article we walk through the process on our own project, PřenechámOperák / LeaseHandover — a Czech portal that also runs on odstupimleasing.sk and LeaseHandover.eu: what we built in the MVP, what we deliberately postponed and why the group remained the main source of users.
The starting point: a market that lived in the comments
PřenechámOperák is a listings portal for people who want to get out of an operating lease before the contract ends. They find a successor, the successor takes over the contract and the leasing company carries out the transfer. The portal isn't a used-car dealer and it isn't a party to the transfer. It connects people who would otherwise struggle to find each other.
Before it existed, this market lived mainly in a Facebook group called “Operativní leasing – poptávka / nabídka” (roughly “Operating lease – wanted / offered”) with about 1,300 members. The group did one important thing: it brought supply and demand together. But it had three limits that no group setting can fix:
- You can't filter offers. Anyone looking for an electric car with a monthly payment under a certain amount has to go through everything by hand.
- You can't compare offers. Everyone posts different details in a different order. One mentions a handover fee, another doesn't, a third quotes the price without VAT.
- They disappear within a week. The feed sorts by activity, not relevance. An older offer that is still valid is practically invisible.
In our article about the client with an NDA we recommended that a community of 47 people stay with a Facebook group. Here it's the other way round. The group is big enough, and its members are already running into the things a group can't do.
The group isn't the competition — it's a distribution channel
The most common mistake when building a portal for an existing community is trying to replace the group. People there are used to it, they have their contacts there and they have no reason to leave just because a new website appeared.
We went the opposite way. The portal solves what the group can't, and the group remains the place where people hear about it. Our first users came straight from there. Every listing on the portal has its own URL, so people can share it in the group and their offer doesn't get buried.
We cover how to get your first users without an advertising budget in general terms in How to get your first 100 app users. For a listings portal it applies doubly, because you have to attract both sides of the market at once.
What belonged in the MVP
The first version should contain only what removes the group's three limits. That means a structured listing, filters, comparison and a way to contact the advertiser.
The hardest part wasn't the code but deciding which numbers to show on a listing at all. When you hand over a lease, there is no purchase price. Two numbers decide: the upfront costs (the handover fee plus the leasing company's transfer fee) and the monthly payment. From those we calculate a third: the monthly cost including the upfront costs. Without it, a short contract with a high handover fee would look better than it really is.
That's exactly where the value lies compared with the group. Structured data isn't an extra form — it's the whole product. If you're building a portal for your own field, start here: which two or three values do people in the group keep calculating or asking about?
What we could leave out
For every feature we asked whether the first user really needs it, or only expects it because the big portals have it.
| Feature | The usual approach | What we did in the MVP |
|---|---|---|
| Posting a listing | registration with a password | just an e-mail and a link to manage the listing |
| Favourites and comparison | a user account | stored in the browser, no account |
| Payments | a payment gateway | automatic matching of payments from the Fio bank statement |
| Accounts for car dealers | a PRO plan from day one | postponed until the first dealer asks |
| Background jobs | queues and workers | webcron |
| Infrastructure | cloud | PHP and MariaDB on traditional hosting |
| Analytics | Google Analytics and a cookie banner | our own cookieless measurement, hence no cookie banner |
A few notes on the table:
- Registration is a barrier for advertisers. Someone who wants to post one listing doesn't want to come up with a password. An e-mail and a management link are enough to edit, extend or close the listing.
- A payment gateway only pays off above a certain volume. A bank transfer with a variable symbol (the Czech payment reference) that the system matches against the bank statement on its own is cheaper and faster to build for a small portal. We use the same principle on TvojeAplikace.cz.
- PRO accounts are a textbook example of a feature you invent, not the customer. Until the first car dealer gets in touch, you don't know what such an account should do. Building it in advance means guessing.
- Without cookies for analytics, you don't need a consent banner. The site is one step simpler for visitors, and you still know what you need to know.
The general rule from How much does an MVP cost applies here too: a feature you can handle manually or more simply for the first few months doesn't belong in the MVP.
How the portal makes money: one paid product
A listings portal has a chicken-and-egg problem. Without offers, no one interested shows up, and without interested people, no one posts an offer. Charging just to post a listing would stall the launch.
So the only paid product is a featured listing (TOP). Anyone who wants their offer to be more visible pays for it. Posting a listing stays free. Monetisation doesn't slow down the growth of supply — and at this stage, supply is what matters most. Other models, such as PRO accounts, will come only once someone shows interest in them.
If you're only just thinking about your own marketplace, we've summarised the typical problems and price bands on our custom marketplace page.
Measure the funnel, not the visits
Page views are almost useless for a portal. One person opens a listing five times, a bot opens it fifty times. Page views are not people.
So we measure the listing submission funnel:
- opened the form,
- didn't get through — at which field and why,
- submitted,
- confirmed their e-mail.
The second step is the most valuable. It shows you exactly the field where people drop off. Typically it's a detail people don't have at hand and have to dig out of their contract. You can get this data without cookies and without external tools.
Define the funnel before you launch. If you add measurement only after launch, you're missing data from the first weeks — and those are the most interesting ones. Whoever comes from the group first is the most forgiving user you will ever have.
One decision against the current: multiple markets from the start
In one respect we went against our own advice to “build as little as possible”. From the start, the portal is designed for multiple markets: three domains (prenechamoperak.cz, odstupimleasing.sk and leasehandover.eu) and five languages.
The reason is purely technical. In the app, language and market are two separate things. Translations live in dictionaries, and a language is switched on only once its translation is finished. Retrofitting this into a finished app is considerably more expensive than planning for it from the first line of code. That doesn't mean all the markets launch at once, though. What's ready is the architecture, not marketing for five countries.
If you're only toying with the idea of multiple markets, I wouldn't make this investment. If you know your market crosses borders — and with leasing contracts in the Czech Republic and Slovakia it does — it pays to plan for it right away.
Timeline, operations and where we are today
The first commit was made on 13 September 2026 and the portal went live roughly a month later. The fast pace wasn't mainly about fast programming. It was about everything we didn't build.
The same decisions keep running costs low, too. The portal runs on traditional hosting with PHP and a database, so we don't pay for usage-based cloud services. With no payment gateway there are no transaction fees, and with no paid analytics tools there are no monthly subscriptions. The fixed cost is mainly hosting and three domains.
After the first month, the catalogue has 17 active offers. That's still too few to draw conclusions about conversions, which is why we're not presenting the results as a success. Meanwhile, the group keeps working as the main distribution channel. Nobody has bought a featured listing yet. For a listings portal in its first phase, that's how it should be: supply first, money second.
Summary
A Facebook group with a growing market is one of the best starts for a listings portal. Demand demonstrably exists and your audience is all in one place. The approach that worked for us:
- Don't take the group's role away. Solve what it can't, and let it be the channel people come from.
- Structured data is the product. Find the two or three numbers people base their decisions on and make them comparable.
- Leave out everything the first user doesn't need. Registration, accounts, a payment gateway and features for customers who haven't got in touch yet.
- Charge for visibility, not for entry. Free listings feed supply, paid featuring feeds the portal.
- Measure the funnel from day one. You'll learn where people drop off, not just how many times a page loaded.
Do you have a similar community and wonder whether to turn it into a product? Get an indicative price in the configurator, or book a consultation. We'll tell you straight whether your own portal will bring you more than a well-run group.


