MeDo Review

Reviewed by Tom · Founder & lead reviewer

The problem it solves

There is a category of software that every small business needs and almost none of them get. A proper inventory tracker rather than a spreadsheet with a colour-coding convention only one person understands. A client intake form that writes to a database instead of an inbox. A booking board for a studio with four rooms. An approval queue that does not live in email.

None of these are technically interesting. All of them are quoted by contractors at prices that make the spreadsheet look sensible, because the cost is not the complexity - it is the fixed overhead of a project: scoping, hosting, authentication, deployment, somebody to call when it breaks.

MeDo attacks the overhead rather than the complexity. You describe the application in plain language and it assembles the working thing: interface, backend logic, a connected database, and a hosted URL you can send to a colleague. The spreadsheet workaround stops being the rational choice.

Who it is for

Two audiences, with different reasons.

The first is people who are not developers and have a clear, bounded need. An operations manager who knows exactly what the tracker should do. A clinic administrator who has been maintaining a booking system in a shared document for three years. These users are not short of specification - they are short of a route from specification to working software, and that is precisely the gap being filled.

The second is developers, using it for something quite different: skipping the empty repository. The first day of any small project is scaffolding, routing, authentication, a schema, a deployment pipeline. Generating a working skeleton and then taking over is a legitimate use of the tool, and for throwaway prototypes it may be the whole use.

It is not for teams building a product whose value is in its infrastructure. That case is addressed below, and the honest answer there is different.

How the pricing is structured

The structure here is unusually favourable to evaluation, which is the main thing to understand about it.

There is a free tier that includes a permanently hosted application URL. That is not a trial in the usual sense. A trial lets you look at a product; a hosted URL lets you put a working tool in front of the people who would use it and find out whether they use it. The distinction matters because the question you are actually trying to answer is never "does this builder work" but "does anyone want the thing I would build".

Paid plans address scale and custom domains - the things that matter once an application has graduated from experiment to dependency.

We could not confirm current figures against the live pricing page for this update, and young products revise packaging frequently, so read the current page. What should inform your decision is the shape: free to prove, paid to depend on.

Day-to-day use

The build loop is conversational rather than visual. You state what the application should be, watch it assemble, then refine by instruction: add a login, make the totals weekly, restrict this view to managers, add a field for supplier reference.

Within the class of applications this suits - forms, lists, dashboards, logins, straightforward workflows - that loop works. Small refinements land quickly and reliably. The experience the first time is genuinely disorienting, in the specific sense that the gap between describing and having collapses from weeks to minutes.

The pattern that produces good results is incremental. One change per instruction, checked before the next. The pattern that produces frustration is a paragraph containing six requirements, where something is misread and you cannot tell which instruction caused it.

Save the prompts that worked. Rebuilding a screen from a known-good description is a routine move with this class of tool, and having the description written down makes it a two-minute job rather than an archaeology exercise.

What it builds well, and what it does not

The boundary is sharper than the marketing of this whole category suggests, and knowing where it falls is most of what you need.

It builds well where the application's logic is mostly structural: records with fields, relationships between them, views that filter and sort, permissions that gate access, totals that aggregate. This describes an enormous share of real internal software.

It struggles where the logic is the product. Pricing rules with many interacting exceptions. Scheduling with hard constraints. Anything where a human would need to ask clarifying questions before writing the rule, because a model given an ambiguous rule does not ask - it picks an interpretation and implements it confidently.

The practical test before you start: can you describe the rule in two or three unambiguous sentences. If yes, expect success. If describing it honestly requires a table of exceptions, expect iteration, and expect at least one rebuild of the screen that contains it.

Hosting, portability, and what you are committing to

This is the consideration that deserves the most thought and usually gets the least, so it is worth being direct.

Applications built here are happiest inside MeDo's hosting, and export or self-hosting paths are limited. That is a characteristic of the category rather than a defect of this product, but it is a real commitment: if the tool becomes load-bearing for your business, your business depends on the vendor's continued operation and pricing.

For an internal tracker used by five people, that risk is acceptable and the alternative - a spreadsheet nobody trusts - carries its own. For anything with customer-facing obligations or regulatory exposure, it deserves an explicit decision rather than a drift.

The mitigation is unglamorous and effective: know how to get your data out, and verify that you can, before the application matters. Check the current documentation for export options as part of evaluation rather than as a thing to look into later, because later is when you will need it urgently.

The workflow this actually enables

The most valuable thing about this class of tool is not the code it writes. It is the decision sequence it makes affordable.

The traditional order is to decide, then build, then discover whether anyone wanted it. The cost of building is high enough that the deciding has to be done on argument, because nobody can afford to be wrong. Internal software gets commissioned in meetings on the strength of whoever is most confident.

With a free hosted URL and an afternoon, the order inverts. Build the rough version, put it in front of the four people who would use it, and watch. Most ideas die at this step, which is the point and the saving. The ones that survive have earned real investment, and you now have usage evidence to justify it.

Validate cheaply, build expensively only when proven. That sequence has always been correct and has rarely been practical. This is the tooling that makes it normal.

Limits and reasons to choose something else

Three reasons to walk away, stated plainly.

If your product's value is in custom infrastructure - unusual performance characteristics, specific compliance architecture, integrations nobody has built - then the right use of this tool is validation, and the eventual build is a real engineering project. Treat the generated version as a disposable prototype rather than a foundation, and plan the rebuild into the budget from the start.

If what you need is a richer version of a document or database you already maintain, a structured workspace tool may serve you better with less commitment. Notion is the obvious comparison, and for many internal use cases it is the more sensible answer.

If your need is connecting existing systems rather than creating a new interface, an automation platform like Lindy AI is the right shape of tool. Building an application to move data between two tools you already pay for is solving the wrong problem.

Alternatives and adjacent tools

There is no directly competing prompt-to-application builder reviewed on this site yet, so this section names its own gap rather than pretending otherwise. The category is crowded and moving quickly, and we will not score products we have not assessed.

The adjacent tools covered here solve the neighbouring problems. Notion handles structured information without requiring an application at all, and for trackers, directories and lightweight workflows it is often sufficient. Lindy AI handles automation between existing systems. Canva Pro covers the presentation layer when the output of your idea is a document rather than a tool.

When you do compare builders directly, two questions separate them more reliably than feature lists: what happens to your application and data if you stop paying, and how the tool behaves when an instruction is ambiguous. Our guide for solopreneurs covers how these pieces fit into a working stack.

Common questions

Do I need to know how to code? No for building. Yes, in a limited sense, for diagnosing - understanding what a database relationship is makes your instructions much more precise.

Can I use it for a customer-facing product? Technically yes. Whether you should depends on your tolerance for depending on the vendor, which is a business decision rather than a technical one.

What happens when it gets something wrong? You describe the correction. For structural changes this works well; for tangled logic it sometimes takes several attempts or a rebuild of one screen.

Is the free tier genuinely usable? Yes, including a permanent hosted URL, which is what makes real evaluation possible.

Will it replace developers? For the class of internal software currently quoted at five figures and delivered late, it changes the economics substantially. For software whose difficulty is real, it has not and does not claim to.

Should you use it?

The scores here reflect a product that does a narrow thing unusually completely. Ease is high because describing is easier than building. Value is high because the free tier includes a permanently hosted application rather than a countdown. Features are good rather than exceptional, which is the right mark for a young product whose documentation and templates are still filling in. Support reflects the same youth.

Use it if you have a bounded internal need and the current alternative is a spreadsheet everyone distrusts. Use it if you are a developer who wants to skip scaffolding. Use it, above all, if you have an idea whose main uncertainty is whether anyone wants it, because proving that for the cost of an afternoon is the strongest argument in the product's favour.

Do not use it as the foundation of a product whose value lives in its infrastructure. Validate with it, then build properly on the strength of real usage.

Best for

Non-developers who need a working internal tool, tracker or MVP - and developers prototyping faster than boilerplate allows.