DEV Community

fikuri
fikuri

Posted on

medo.dev the good, bad and ugly from my personal experience

So I joined the MeDo hackathon and used their platform for several days. At first, I thought it was just another v0, Lovable, or Bolt. But after building with it, I realized MeDo offers a very different way to prompt, build, and ship a product.

This is my personal review after around two weeks of using it: the good, the bad, and the ugly. I was genuinely impressed by the deep integrations and some unique features that I think many people might miss. But the platform also has rough edges that are worth talking about.

Background

In today's developer world, many programmers use tools like Claude Code and Codex. They are powerful and flexible. You can build almost anything with them, but you still need to manage everything yourself: setup, environment, dependencies, backend, database, deployment, and debugging.

Of course, you can ask Claude Code or Codex to help with that. But if you do not already know what you need, things can get messy fast.

For non-technical users, or developers who do not mainly build web apps, tools like v0, Lovable, and Bolt feel easier. You do not need to set up much. You prompt, and you see the output quickly.

But once you want to build a complete product, you still need more than a frontend. You need backend, database, authentication, AI APIs, image generation, payments, and many other services.

Yes, tools like v0, Lovable, and Bolt can connect to those things. But you still usually need to create your own Supabase account, connect it, manage API keys, register for OpenAI, Anthropic, GCP, or another provider, and wire everything together.

And then there is the classic problem: API keys. The same API keys people accidentally push to GitHub and then get abused by someone else.

That is where MeDo starts to feel different.

The Good

1. You do not need to open another service, mostly

At first glance, MeDo looks similar to v0 or Lovable. But the difference is that many things are already built into the platform.

Need a backend? It is already built in through Supabase.

Want to add an LLM? Just prompt it. It is already integrated.

Want image generation? It is already built in.

Want text-to-speech? It is already built in.

Want a weather API? It is already available.

Want payment? You still need Stripe, and you still need to register your business and get the API keys. So yes, the legal/business side still exists.

But overall, many services that usually require separate setup are either built in or available through plugins. I think this is MeDo's strongest USP. You do not need to manage and pay for many separate services. You mostly manage MeDo.

Imagine your vibe-coded app starts getting traction. If you use v0, Lovable, or Bolt, you may need to upgrade Supabase, top up credits on GCP or another AI provider, and manage other API services separately.

With MeDo, the experience feels more centralized. You pay and top up credits in one place. As a product builder, I think this is very useful, especially for non-developers who just want to build and publish a real app.

2. Deep backend and frontend integration

Because the backend and frontend live inside one platform and one codebase, the AI agent can understand more of the full product.

That makes building and debugging easier.

For example, I had an issue where a service integration returned a 403 error. The problem was not really in the frontend code. The backend had not redeployed with the correct key. The agent checked the Supabase function logs, looked at the backend code, understood that the problem was the backend not restarting, restarted it manually, and the bug was fixed.

That kind of end-to-end debugging is where MeDo feels powerful.

3. Plugins, plugins, plugins

The plugin system is one of the most interesting parts of MeDo.

The available plugins are diverse and keep growing. I saw plugins for exchange rates, global stock data, data analysis, Word documents, PowerPoint, and more.

To be clear, these plugins are not always like traditional third-party integrations where you connect an external service yourself. Many of them feel more like skills or templates integrated into the platform and database.

But because the model can use them inside the same environment, they become very useful. You do not need to manage every integration manually. MeDo handles a lot of that inside the platform.

4. Design direction and starter templates

I still think v0 is stronger for frontend design. That is probably the thing v0 does best.

MeDo is slightly below v0 in pure frontend polish, but I like that it gives starter references and does not always force the same visual style. It gives you enough structure to begin, while still leaving room to push the app in a different direction.

This part still needs more testing from me, but so far the design workflow feels promising.

The Bad

1. It is still buggy

The biggest downside, in my opinion, is that the platform still buggy. Maybe this is because it is new, but sometimes messages fail multiple times and you need to clear the context manually.

this can be frustrating in my personal experience.

2. The platform feels slow

The slowness is not always about the model generation itself. The platform UI can also feel slow.

Opening the plugin list takes a few seconds. Some images seem unoptimized or not cached well, so they load slowly again and again.

This is not a deal breaker, but it makes the product feel less smooth than it could be.

The Ugly

1. Language inconsistency

The platform still feels China-first in some places, with English as a second layer. Some parts of the UI are not translated, or the interface suddenly switches to Chinese.

Sometimes the model also replies in Chinese or uses Chinese placeholder text in the generated UI.

This is probably fixable on their side, but it stood out during my usage.
for example

2. Unclear model identity

MeDo has "fast" and "deep build" models. I assume they use their own proprietary model, although the behavior sometimes feels close to Claude model in my opinion.

The problem is that I do not know what model is actually being used. I do not know the benchmark, the strengths, the weaknesses, or how I should prompt it.

Should I prompt it like Claude? Like Codex? Like another coding model?

That uncertainty is annoying as a builder. I wish the platform was more transparent about what model is being used, or at least how users should think about each mode.

Final Thoughts

MeDo is not just another frontend generator. for me it is feels like the true "full-stack" development platform, you only need this platform to get your app from zero to one from above and beyond

It is still buggy. It can be slow. Some parts still feel rough for English-speaking users. But the core idea is strong.

Top comments (2)

Collapse
 
gokil_abis_46d8c348329e0c profile image
Gokil Abis

looks very interesting

Collapse
 
fikuri profile image
fikuri

u should try bro