DEV Community: fikuri

I make an app to help you make money while traveling

fikuri — Sun, 17 May 2026 18:07:57 +0000

This is a series of content I created for the Build with MeDo Hackathon at MeDo.
Read my first article about medo here full review about medo.dev

Introduction

In Indonesia, Jastip (concierge service) is very common. China has a similar culture called Daigou (buying on behalf).

The key similarity between Daigou and Jastip is one simple thing: "Access".

How Jastip works is basically someone from a different location with "access" to certain products offers them to others on social media. If people want to buy, the seller does not need to own the inventory or stock. They just need to be there at the store and ready to purchase. This Jastip service includes a service fee and sometimes delivery service. There are many kinds of products being sold, from snacks to luxury goods you cannot easily find in Indonesia.

People in Indonesia take this to another level by making it a full side quest while travelling. They plan a trip for fun, and to help finance the travelling, they do a Jastip side quest with many products, often from cross-country travel.

Then I found that China already has a similar culture with Daigou, but it is more focused on luxury items that are often hard to find in China or have some kind of rarity or reputation from the origin country (or so from what I read on the internet).

The interesting thing about China and Indonesia's Jastip/Daigou culture is how they operate. In China, Daigou mostly operates on WeChat livestreaming, and the storefront is built inside WeChat using mini programs.
On the other hand, in Indonesia, interaction and transaction usually happen on either WhatsApp groups or Instagram chat. It is very fragmented and causes multiple issues.

So to help my fellow Indonesians make money while travelling, I made an app to manage this kind of thing using medo.dev.

Show me the money

To motivate you to read further, let me put a motivational image for you.

Yes, the money. With this app, you can not only plan for travel, but also make some money with Jastip.

How, you may ask?

1. You can create a campaign

When creating a campaign, you set the starting date and end date of your Jastip.
But Jastip across countries is hard. You need to calculate currency, and I am also afraid of people doing hit and run.

Don't worry, this app handles the currency exchange automatically for you, and there is deposit payment for your buyer. They can use that deposit to buy from you later, but if they do not buy, you can redeem the deposit.

What's next after creating a campaign, you may ask?

2. You can open the campaign and check

Talk with the AI assistant so you are better informed about weather, currency, pricing strategy, adding products if you already have something in mind, or just reading the news in case something happens.

3. Talk with our smart AI agent

Our AI is not like ChatGPT or Gemini, where you need to give information about what you are doing, where, or when. It understands your Jastip context, and it is integrated deeply with MeDo's large language model.
You can also take notes for important information from the AI and check them from the notes tab.

4. Check who is already interested

Check your member tab to see who is already interested and has put down deposit money.
They actually pay with their debit/credit card (using MeDo Stripe skills). It will be yours to claim later.

5. Talk with your buyer directly

Instead of information scattered in WhatsApp and Instagram, you can interact directly here in the app. You can also send images if you want.

6. Lastly, download the invoice or just export everything into Excel for later.

You can enjoy your travel and manage the Jastip using our platform.

7. and heres from buyer side of the app

From the buyer side, the flow is browse campaign, join with deposit, send request, chat, and track the transaction.

Next is how did I make this app?

nd how did it only take me a week to do so...

1. Register to Medo.dev

Ok, MeDo is a full-stack AI coding platform. It sounds very much like a buzzword, but trust me, it is real. You may already have heard about v0, Lovable, Bolt, or Replit, but there is nothing like it. MeDo is more complete, and you only need MeDo (and Stripe apparently for payment).

2. Create new project

3. Next, you just wait until your idea is built

Here's the fun part. Medo.dev is actually not frontend first. It is product first. It will create the full product spec and requirements before it even starts coding. Everything is included, from what should be built, how the folders and system are structured, and what is out of scope, which is very important to make your product align with your vision.

You can edit it or not, it is up to you. Next, click generate the app and then wait.

4. PLUGINSSS (apparently now they call it skills)

The skill integrations in medo.dev blew my mind. In v0, Lovable, and Bolt, you are kind of forced to register for an outside backend service like Supabase. But medo.dev does this automagically, so you do not have to have a Supabase account and click connect or something like that. It just WORKS.

login just works
crud just works
upload image just works
realtime chat app just works
even payment using stripe is just WORKS

And it is not only the backend. Even LLM, image generation, video generation, text-to-speech, and speech-to-text are included. No need to juggle multiple providers, grab API keys, store them, then integrate them. IT JUST WORKS.

You can just pay using a single credit system for all of the services. No need to set up multiple payments or subscribe to multiple websites to get API keys anymore.

I was really blown away by the depth of the integration, so I started to dig into the code.

5. The LLM skills

So in my experience using the medo.dev LLM skills, the default is not really great, but you can just prompt it. Make sure to always prompt it to make the output token to the max.

You can also ask it to call tools, using other skills as tool calls that the LLM can invoke. My biggest problem with the LLM skills is that it seems to be hardcoded to Gemini 2.5 Flash, while there are already newer models like 3 Flash or later.

You can actually make an agent in the LLM skills, not just a placeholder. For example, I built this AI assistant to be able to talk to its own CRUD API, so it can change the title at the top on the fly in realtime by calling directly to the internal API. Mind = blown.

Some tips and tricks using MeDo

Based on my few weeks using medo.dev, here are some tips and tricks that helped me boost productivity and save credits.

Basics

MeDo gives you an integrated backend and frontend workspace. You can look at the code, but you can also access files, logs, and infrastructure directly inside the app.

A single Fast Build prompt costs about 15 credits, while Deep Build costs 30 credits. As of writing this, new accounts usually get 300 credits on registration and 100 credits from daily login. That is around 10 Deep Build prompts or 20 Fast Build prompts.

Tip 1: Put related tasks in one prompt

From my experience, credits are counted per message, not by how hard the problem is or how many tool calls it uses.

There are limits if you ask for too many things at once, but if the tasks are related, it is usually better to put them in one prompt. This helps you get more value from each credit spend.

Tip 2: When debugging, ask for logs and checks

When something breaks, do not only ask MeDo to fix it. Ask it to add logs and checks first so it can understand the real problem.

Example prompt:

What is the best approach to fix this [issue]? Please add logging and checks to help identify the issue.

This helped me a lot when a problem was not fixed in one run.

Tip 3: Ask for design suggestions before giving strict direction

MeDo can be overly eager when you give it very strict design direction.

In my case, I gave it a reference and told it exactly what I wanted, but it still tried to be "creative" and the result was frustrating.

What worked better was asking for a few options first.

Example prompt:

Give me 3 design variants for this particular [problem]. The goal is to [specific goal], and I prefer it to look like [your preferences].

This way, MeDo gives you a few layout and style directions first. You can then choose one, adjust it, or ask for another variant.

This saved me a lot of credits because I stopped forcing one direction through many follow-up prompts.

Tip 4: when stuck, try to clear the context before sending a new prompt

Sometimes you get that little annoying bug, whether it is frontend or backend.
In my experience, it always helps to use the clear context button before sending another prompt. Clearing context can make the agent think and do the task better and faster.

this is the button, don't mind my negative credits i overused it lol

So that's what I am building and how I am building it, with tips and tricks.

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

fikuri — Sun, 17 May 2026 13:58:57 +0000

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.

Kiro: the good, bad and ugly part in my personal experience

fikuri — Sat, 13 Sep 2025 14:58:39 +0000

As a developer who's worked with various IDEs, AI-coding tools, and agent-assisted workflows, I recently spent some time using Kiro. It bills itself as an agentic IDE that brings "Spec-driven" development into the mainstream. In this post I'll walk through what’s great, what's frustrating, and what downright exposes rough edges from my hands-on experience.

What is Kiro

Before we go into the pros & cons, a quick overview to set the context.

Kiro (by AWS) is an AI-powered IDE built on a VS Code core.
Its standout idea is spec-driven development (SDD). Instead of just vibe coding (talk with an AI to jump in and code), you start by defining requirements, then design, then implementation tasks.
Supports "steering" (steering files: product.md, tech.md, structure.md) to give context so the AI agent has real project context to work with. Kinda like rules to be honest but more transparency since Kiro shows you whats steering that loaded to context.
Hooks / agent hooks: automations or triggers that run on file events etc., to enforce standards, generate docs/tests, etc.

1. Spec

This feature basically gives you three documents requirements.md, design.md, and tasks.md that flow naturally from one another.

requirements.md is a collection of user stories generated from your prompt.
design.md is a technical guideline created using both the requirements and your original prompt, with some extra research to make sure it uses correct technical terms, diagrams, and architectural notes.
tasks.md pulls it all together, breaking the design down into actionable checklists with states like in progress, done, and failed.

The Good

In my month of working with Kiro, the Spec feature stood out as a surprisingly useful thinking partner. It's great at taking a rough prompt and slicing it into different perspectives-whether that-s from a user's point of view, from a developer’s perspective, or even through acceptance criteria. The benefit I felt from this structure was the ability to self-assess my own prompt and refine it into manageable chunks with clear success criteria. Sometimes I'd start with a very broad, messy prompt. Running it through requirements.md gave me a spread of user stories that became a kind of prompt inspiration engine that I could select, refine, or even pivot based on what it generated.
The design.md stage was also a game changer. It translated my vague ideas into more concrete, technical language. There were times when I didn’t know the exact term or pattern I needed, but the design doc filled that gap, often pointing me toward the right flow, architecture type, or even the correct jargon. It wasn't just generating code it was helping me learn more from it.
Finally, the tasks.md output turned that high-level thinking into a neat checklist. What I loved most is how it integrated with my workflow. For example, I could tell it to create a new branch and commits from the requirement, and it would produce proper branch names and git messages without me having to overly explain. When I started the tasks, it automatically followed the flow outlined in the spec. In practice, this meant I could automate my git flow through the spec alone, without hand-holding the AI every step of the way.
Another success case I had with the Spec feature was using it to create a design system, basically a UI template guideline. At first, it was just an experiment, because my app looked like every other vibe-coded project. You can’t just tell Kiro “make it pretty,” but you can be precise in the spec prompt. For example:

"Create a spec for a design system. Scan through the #codebase and transform every component into [your style]."

And it worked like magic. In one run, I transformed a standard shadcn look and feel into a full neobrutalist UI style. All from a single Spec. That moment genuinely impressed me. It felt less like AI throwing random CSS at the wall, and more like having a design system generator built right into my workflow. The neat part? You can even use images as references, and Kiro will generate a surprisingly solid design system spec doc around them.

The Bad

My first frustration with the Spec feature is how rigid the flow is. It only comes in three flavors requirements, design, and tasks. You have to follow them in that order. Let's say I just want a design doc. Nope, I have to generate requirements first. Or maybe I want to jump straight to tasks from my prompt. Again, not possible. I'm forced to walk through the same steps every single time. What frustrated me even more was the pricing model. Apparently, creating a spec is charged as a "vibe" request because it's generated through the chatbox. But… why? Specs are supposed to be structured, not casual chat. This means every time I try to refine or have a conversation about a spec, I’m burning vibe credits. That felt like paying extra just to use the feature the way it’s meant to be used.

The Ugly

The very first time I ran tasks, I noticed how over-eager Kiro was about testing. Unit tests? ✅ Integration tests? ✅ E2E tests? ✅ ✅ ✅. It was like Kiro assumed I was building software for a billion users with an enterprise QA department on standby. Meanwhile, I wasn’t even sure if I had the core feature right, and my vibe credits were burning away on a mountain of tests, half of which didn’t even pass. Instead of helping me move fast, I ended up with this over-engineered jungle of tests, no working feature, and a sinking feeling that the AI was planning for “999 updates from 999 developers” when in reality it was just me, alone, trying to get one feature working. Yes, this is tweakable via steering and that's exactly what I did. Pro tip: if you're not sure what you're building yet, strip out all the tests and optimizations from the design spec. Even if you are sure, limit them as much as possible. Otherwise, you’ll watch your vibe requests evaporate faster than you can say npm run test.

2. Hooks

Hooks in Kiro are basically automations that trigger on file events. They can enforce standards, generate docs, or even keep your tests up to date. Think of them as little invisible helpers running alongside your workflow.

The Good

Hooks shine when they take care of the boring stuff. Generating API docs when I change an endpoint, scaffolding a test file when I add a new module . Those things just happen without me lifting a finger. It really does feel like having a junior dev who quietly cleans up after me, making sure nothing slips through the cracks.

The Bad

The downside is that every hook run costs a full vibe request, no matter how small the automation. If the only available model is Claude Sonnet, I get why it’s expensive, but burning the same credit for a tiny linting fix as for a big multi-file refactor feels… off. I often catch myself hesitating to set up hooks for small, tedious tasks, because the “cost to benefit” just isn’t there.

The Ugly

Here’s where it got frustrating: hooks only trigger if you explicitly save a file or create a new one inside the editor. 🙃 So when I tried to drive automation from outside the IDE, nothing happened. I had a bunch of ideas for how hooks could turbocharge my workflow, but the "automatic" part turned out to be not so automatic. That killed a lot of the excitement for me.

3. Overall Agentic Experience

Kiro calls itself an agentic IDE, and it delivers on that promise in several ways: a chat sidebar, context management, RAG-style indexing of the codebase, terminal execution, and multi-file awareness.

The Good

The context management is excellent, especially with Steering. I found steering a far better approach than static rules or agent.md files. You can create multiple steering files and decide which ones apply to which folders or files, which gives you far more control. And then there’s the main course: the chat sidebar. This is where agentic coding really shines. Powered by Claude Sonnet 4, Kiro can handle long prompts, write huge chunks of code (I’ve seen it generate 2k+ lines in one go), and search context quickly with the #codebase keyword. With a clear, well-structured prompt, it rarely fails. When it works, it feels like coding with a diligent, context-aware partner.

The Bad

But the agent isn’t perfect. Terminal execution, for example, constantly hangs unless I type commands manually. And yes, it still insists on generating tests (sometimes too many). Those are annoyances, but the real headache is pricing. Kiro’s vibe requests sit in a strange middle ground. The free tier is generous (50 per month), but I’ve blown through all of them in a single 2-hour session. Each task the agent works on takes about 5–10 minutes, and with back-and-forth clarification, 20 messages is enough to wipe you out. The pricing feels confusing and opaque: it’s marketed like Windsurf, but tallies up like Cursor. Somehow landing in the worst of both worlds.

The Ugly

If pricing is the "bad" then the ugly part is how vibe requests are consumed by context summarization. Asking Kiro to summarize context burns 1 vibe request. Then re-entering a refined prompt burns another. It feels like the system punishes you for trying to debug or iterate quickly. More than once, I found myself losing momentum. Not because the AI failed, but because I was too busy watching my credits drain away. It’s a real buzzkill when you’re excited to implement a feature and the meter is working against you.

Verdict

Kiro is one of the boldest takes on AI-assisted coding I’ve tried. The Spec feature is structured and surprisingly educational. Hooks are powerful when they work, though they cost too much for small tasks. And the agentic experience is genuinely impressive, but dragged down by confusing pricing and rough edges in automation.

For medium-to-large projects, it feels like a promising glimpse of the future. But for fast-moving, vibe-coded sessions, Kiro’s structure, costs, and quirks can get in the way. It’s not the magic bullet for every dev, but it’s definitely one of the most ambitious steps toward making AI a true coding partner.

I believe more IDEs will soon offer features like planning, documenting, diagnosing, and generating checklists. Right now, Kiro is one of the few that does spec-driven development well, but if it doesn’t refine its approach and fix some of the flaws I’ve highlighted, it risks being left behind as the space matures. The competition is moving fast, and “good at specs” won’t be enough if the overall developer experience feels costly, rigid, or frustrating.