A Place Where People Share Ideas with the World

I didn’t come to this topic as someone who discovered a neural network yesterday and decided to “build a startup”.

I have about twenty years of experience in IT, more than ten of which were spent in a large bank. I worked with information systems, implementations, services, infrastructure, internal portals, CRM, and everything that usually sits between the user, the business, and the technical reality. Yet I was never a developer in the classic sense.

That’s probably why AI tools caught my interest not as a toy for code generation. For me they represent a way to finally quickly test ideas that used to get stuck between “I should do this” and “I need a development team”.

Another factor is that I live in the Netherlands. Here you can clearly see how international IT work has become. Even outside Amsterdam, on a small patch of land around you can find specialists from different countries, speaking different languages and working for companies in entirely other time zones. Sometimes it feels almost comical: a so‑called expat from Vietnam who lived in Russia now works in the Netherlands for an Australian company. And this is not an exception but everyday life.

When a developer shows a project, there’s a familiar route: GitHub, README, demo, documentation. It’s not perfect, but it’s understandable. Another developer opens the repository and roughly grasps what’s in front of them.

But for vibe‑coders it’s set up a little differently.

Someone might not be a professional developer. They open Cursor, Lovable, Bolt or Claude and explain in words what they want. “Make a form”, “fix the screen”, “check the error”. That’s how they build a product: through conversation, clarification, and new attempts.

Then a strange failure occurs.

The product already exists. It might be raw, but it exists. And presenting it properly is hard. GitHub is too technical. The landing page is too promotional. In the end the author has to choose between “here’s my code” and “here’s a nice screen”, when what they actually need is something entirely different: to explain what they did and why.

At first I thought I was creating a catalog. After a while I realized: there are already enough catalogs. The problem isn’t that there’s nowhere to put a link. The problem is that the project is hard to explain.

That’s how storevi.be came about. I would now describe it not as a catalog of AI tools, but as a place where a small project can be explained in human language.

And for me “human” here means not only simple words but also multiple languages. If an author describes a project in Russian or English, the platform should automatically help show it to people from another country. Otherwise the entry barrier rises again: it’s not enough to build a product; you also need to be able to tell people about it in the language of the future user.

Yes, a comparison with Product Hunt is inevitable here, because it’s known as a launch platform. But I’m not trying to create “another launch day”. I’m more interested in the moment before the big launch, when the author is still figuring out what they’ve achieved, but is already ready to show it to people.

Why GitHub and a landing page don’t solve the problem

GitHub is great when a developer looks at a project. But for someone without a technical background it’s more like a dashboard. There’s a lot of important stuff, but it’s not always clear what belongs to the product itself.

A vibe‑coder has a different need. They don’t need to start with “here’s my repository”. They need to start with a simple description: what I’m doing, for whom, and what already works.

With a landing page the opposite problem arises. It can look too good. You can write “automate your business with AI” and put a nice button. But what’s actually done remains unclear.

On storevi.be I decided to start with what vibe‑coders are already used to: a description in words. The author creates a card not through a long technical questionnaire, but through a story about the project. Then the system helps shape it into a proper format and asks interview questions.

The interview shouldn’t be templated. If you ask everyone the same thing, you’ll get another boring form.

I want AI to look at a specific project. If it’s a rental service, the questions should be about trust and real participants. If it’s a tool for testing candidates, the questions should be about assessment quality and model errors. The point isn’t a checklist, but to pull out the important details from the author.

First mistake: I started building a combine

The biggest blunder was almost classic. I started building a big product too quickly.

In my head everything seemed logical: projects, authors, articles, moderation, AI checks, trust score. On paper it sounds like a platform. In reality it’s a list of tasks after which you want to close the laptop.

I caught myself building infrastructure around a problem I hadn’t even proven yet.

I had to go back to the boring question: why does a person even come to storevi.be? To show a project, to find a project, or to understand whether a project can be trusted. Everything else should help with those actions.

After that the product became simpler. Not perfectly simple, but at least it stopped spreading in all directions.

Second mistake: AI started writing beautiful emptiness

I wanted it to be easy for the author to add a project. Not a huge form, but a normal description. Vaybcoders already work with AI like this: they explain, refine, look at the result, refine again. The project card should start similarly.

Then AI should help assemble a proper card from that.

The idea is good. But the first version quickly showed an unpleasant thing: AI loves to write convincingly, even when there are few facts.

The author writes something like: “we’re building a platform for automating decisions with AI.” AI happily turns it into a tidy text about an innovative approach, efficiency, and scalability. It’s pleasant to read. The benefit is little.

And in the product you can’t replace facts with smooth text either.

So I started shifting the AI editor in another direction. Its job is not “make it pretty”. Its job is to ask uncomfortable clarifying questions. Who is the user? Where can you try the product? What’s already done, and what’s just a promise?

In other words, AI inside storevi.be is now more of an interview assistant. It highlights gaps, offers phrasing, and automatically translates the card into the platform’s languages. This is important not for a nice “we have localization” tick, but for search and lowering the entry barrier. The author shouldn’t have to manually prepare a separate version for each language, and the reader shouldn’t leave just because the project is described in a language they don’t speak.

Trust Score turned out to be more dangerous than I thought

I wanted to add a trust rating. It seemed logical: if the project is open, the author is verified, there are screenshots, there’s a history, no obvious problems, then there’s more trust.

But as soon as a number appears, it starts looking too confident.

77/110 sounds solid. But a normal reader will immediately ask: why 77, not 54? Who decided? AI? Author? Why does popularity weigh so much, and author verification so little?

And those are the right questions.

So the trust score gradually becomes not a “project rating”, but a set of signals: availability, uniqueness, author verification, activity, potential. I think this is fairer – “here’s what we could verify, and here’s where it’s still empty”.

This part is still raw. But the mistake itself was useful: if the product talks about trust, it can’t hide behind pretty numbers.

What ended up being the core

Now the core of storevi.be is the project card with context.

Not just “here’s a link”, but a brief analysis: what it is, who’s doing it, what can already be opened, and what questions remain about the project.

For me this is not just theory. The platform already has several projects that I run and develop in parallel. They’re different: from an AI assistant for Asian cuisine and a service with interactive panoramic journeys to a leasing platform for small business. I keep them side by side because it’s clear how differently you have to explain the idea, stage, risks, and benefits.

I also added articles and discussions separately. The card quickly becomes dry, and the launch story becomes a living material.

The authors’ community appeared later. Not because the platform needs a community, but because after viewing a project you often want to write to the person. Not just to like, but to ask or offer help.

What hasn’t worked yet

I haven’t been able to prove that the platform itself is needed by a large number of authors. There is a working product, logic, cards, and first projects. But that doesn’t yet mean we’ve found a behavior that people will repeat consistently.

I couldn’t make the trust score sufficiently explainable. It’s already useful as an internal guide, but for an external person it still looks like “some kind of rating” in places.

I couldn’t fully eliminate the sense of a catalog. The first glance still reads cards and the project grid. So we need to emphasize the story and the author’s answers more.

And I still haven’t made the publishing process as simple as I’d like. AI interviews help when the questions come from the project’s core. But the author shouldn’t feel like they’re being interviewed for a bank.

What’s next

The immediate task is to bring trust into a normal shape: what’s verified, what isn’t, and where the risks remain.

I also want to tie cards and launch stories more tightly. I want a project to be more than a static page, but a living record: what changed, where we went wrong, what improved. You can already write an article about a published project and link them.

And of course we need authors. Without people it will just be a tidy demo. I’m interested not only in finished startups but in the raw stage—prototypes, experiments, and micro‑SaaS that honestly admit what they are.

Here the international context matters again. I don’t want storevi.be to be a platform only for one local scene. The product can be built by someone in the US, tested by people in Germany, discussed by Russian‑speaking specialists, and the first clients might even come from China. Therefore a project card must be understandable not only to “locals” who already know the author, but to people with different experience, language, and context. Automatic translation here is not a decoration but a way to give the project a better chance of being found via search engines.

What help is needed

If you’re building a small AI product, try adding a card and see what questions arise. It’s especially interesting if the project isn’t perfect yet.

If you’re a developer, I need criticism of the technical logic. Where do the checks look dangerous? Where can AI lie? Where does the trust score create false confidence?

If you’re a product person or marketer, look at the positioning. Is it clear why this is needed? Does it look like another catalog? What should be on the card to make you want to write to the author?

If you’re just a reader, ask a tough question. Preferably a specific one. That criticism is less pleasant but more useful.

Many people used to find it hard to create a product. Now it’s increasingly hard to explain why it’s worth looking at.

That’s the problem I’m trying to solve.