When a no-code MVP is enough and when custom development is justified

A no-code MVP is enough when the platform can support the workflow you need to test and the requirements of the release you intend to put in front of customers. Custom development becomes worth evaluating when a mandatory requirement cannot be met through the platform's configuration or a suitable code extension, or when the platform does not provide the engineering control the release requires.

You need to judge two things separately: what the test can teach you about the product, and whether the implementation is fit for its intended use. Someone completing a guided task tells you little about whether they will return next week. Equally, a no-code application may remain useful beyond an initial test if it continues to meet the requirements.

Start with the question your MVP must answer

Write the product question before selecting a platform. For example: “Can an operations manager collect missing supplier documents without chasing each supplier by email?” That identifies a person with a task you can investigate. A request to “build a supplier platform” leaves much more undecided.

Then describe what must work for customers to try it. The manager needs access to the right records. Suppliers need to submit attachments and find out if something fails. These delivery requirements belong beside the learning question. If the first release is still too broad, start with what to build first.

For this decision, no-code means building primarily through platform configuration: arranging interfaces, defining records, and setting up workflows using the platform's tools. Low-code combines visual configuration with some code. Microsoft describes this distinction in its overview of low-code platforms. The labels describe how you build; they do not establish whether a particular tool meets your requirements.

Also distinguish a prototype from a working release. A prototype can help you explore an interaction without implementing every step behind it. A release used by customers needs the functions and operating arrangements required for that use. Either may involve visual tools or code. Neither route removes the need for scoping, design, or technical checks.

What a no-code MVP can help you test

Building a no-code MVP can give participants a workflow to try. What you learn depends on the task, the people taking part, and the behavior you observe.

Consider a hypothetical B2B product for collecting supplier documents. An operations manager requests a document, the supplier submits it, and the manager checks its status. An initial test might investigate whether both people understand what to do and whether the status view answers the manager's question.

Watch where the supplier hesitates, whether the manager recognizes an incomplete submission, and what help either person needs. Those observations can inform the interface. To investigate ongoing usefulness, you would need to see what happens when another document is due: does the manager return to the product, or resume the email process? A guided demonstration cannot answer that question on its own.

The table below separates observations you could make from questions they would leave open.

For each result, record the conditions. “The supplier completed the task after we explained the status labels” supports a different conclusion from unassisted completion. A payment for a heavily supported pilot also needs that context when you assess demand for a self-service product.

What a small test does not establish by itself

A successful task is useful evidence about that task. It does not settle every question about the application.

GOV.UK's guidance on making prototypes distinguishes code built to explore a design from code suitable for production, including security and traffic considerations. That guidance is about prototypes; it does not establish that all no-code applications are unsuitable for production. Readiness depends on the actual implementation and intended use.

Before expanding a test into a customer release, exercise the conditions that release will face. Try the relevant devices and record types, including simultaneous activity where it matters. A brief demonstration with one user leaves those conditions untested.

Check permissions separately from task completion. In the supplier example, a successful upload says nothing about whether another supplier could retrieve the document. Verify who can read or change each record, and what happens when a role changes. Review how the proposed configuration handles the data you collect, including retention and recovery, against your requirements and the platform's terms.

Connected services need failure checks too. Let a credential expire or interrupt a request in a test environment. Establish how someone will notice and resolve the failure, including a repeated notification or submission. Assign responsibility for support and updates. Another maintainer should be able to locate the workflow rules and explain how to change them.

Keep these checks tied to the release you intend to offer. A speculative future feature can wait; a requirement that already applies to the first customer's data cannot.

Choose between no-code, low-code and custom development

Compare actual implementation options against the same workflow and requirements. “We need integrations” is not enough to select a route. Identify which system must connect, what data must move, what can fail, and what the product must do afterward.

For each mandatory requirement, record whether the candidate has demonstrated it, failed it, or still needs investigation. A feature label on a platform website is a starting point for a check. It does not show that your particular configuration will behave as required.

Include the work needed to operate each option. Who will maintain the configuration? If you add code, who can test it when the platform changes? A custom application needs owners for its components too. Compare setup and testing effort alongside ongoing support and a possible handoff.

There is no requirement to graduate from no-code to a custom build at a particular milestone. No-code MVP development can continue while the implementation meets the product's needs. A low-code MVP may likewise keep a useful configuration and add a defined extension, with no planned rewrite.

Run a useful test before expanding the build

Define the decision the test is meant to inform. For the hypothetical document workflow, the immediate question might be whether users can complete the request and submission process without someone explaining each step. That calls for different observations from a test of repeat use.

Write what finding would affect that decision, then recruit people who perform the task in relevant working conditions. Record any important differences between the participants and your intended customers.

Give them a task to attempt and note where they need help. For the document workflow, an incomplete submission may be worth including if you need to know whether users understand its status. Keep what you observed separate from what participants say they might do later.

Record missing functionality and any assistance you provided. If someone sends reminders behind the interface, the test may show whether those reminders help. Automated reminders remain untested.

Use the findings to choose the next step. An unclear status might justify changing the interface and checking it again. Evidence that challenges the underlying need calls for reconsidering that assumption before expanding the build. Explain why you are continuing or stopping so the next person reviewing the test can follow the decision.

When custom development becomes justified

Consider custom development when you can name a necessary capability or control the evaluated approach cannot provide. Document the gap before choosing a replacement.

Continuing the hypothetical supplier example, suppose the release requires access to a specific document history, and the evaluated platform cannot provide it in the required form. First establish why that history is necessary. Then check whether a configuration change, a supported extension, or another suitable platform could meet the requirement. If those options do not fit, a custom component or application warrants evaluation.

Documents and permissions may be fully supported by the current approach. A rebuild needs a demonstrated gap, rather than an assumption that these features require custom code.

Document what you checked and why the unmet requirement matters. Include any extensions or alternative platforms you considered, with the reasons they did not fit. That gives a new team a basis for deciding which parts to retain and what would need replacing. Assign responsibility for maintaining the proposed solution before committing to it.

Assess custom development against those same requirements. Writing code does not by itself prove that the new implementation handles permissions, failures, or future changes correctly. The proposed build still needs a clear scope and verification.

If you need help turning an identified gap into an implementation scope, you can scope a custom MVP with Merge. Bring the tested workflow and explain where the current implementation falls short.

Prepare a handoff if the build route changes

Preserve what you have learned about the product, even if parts of the implementation need to change. Before a handoff, check that the receiving team can access and understand:

• Document the user task, including exceptions and any manual steps needed to complete it.
• Describe the data model and relationships the next implementation must preserve. Include identifiers and required history.
• Record permissions for each role, including administrative access and customer boundaries.
• Identify connected services and how their failures are handled. Name the person responsible for each connection.
• Verify the available export formats and what they contain. An export of records may exclude application logic or the interface.
• Check ownership terms and company control of the relevant accounts. Agree how administrative access will transfer without sharing personal credentials.
• Assign support and recovery responsibilities during the transition, including updates and unresolved issues.
• Pass on the test findings with their limitations and the decisions still awaiting evidence.

Check access and ownership against the applicable terms and agreement. These arrangements need verification with the platform or supplier.

Inspect a sample export before relying on it for a move. Agree how the receiving team will check that required records and relationships are present, and identify what would need to be recreated. Keeping the existing application available during a transition also needs an explicit owner and operating plan.

Questions founders ask

Can a no-code MVP be used by real customers?

Yes, if its implementation meets the requirements of that use. Check the actual workflow, permissions, data handling, integrations, and support arrangements. A prototype tested with sample data does not establish readiness for live customer data; evaluate the intended release separately.

How does low-code differ?

Low-code combines visual configuration with code where the implementation needs it. For an MVP, that could mean a defined extension to an otherwise configured workflow. Verify that the platform supports the extension you need and assign responsibility for testing, maintaining, and updating it.

When should I consider a custom build?

When a mandatory requirement remains unmet after evaluating configuration and suitable extensions, or when you need engineering control the platform cannot offer. Confirm the gap and compare implementation options. Reaching a milestone or gaining users does not automatically make a rewrite necessary.

Which no-code tool should I choose?

Choose candidates based on your workflow and required behavior, then test those requirements in each relevant configuration. Check data access, permissions, integrations, operating responsibilities, and export options. A tool that demonstrates these requirements for your product is a stronger candidate than one selected from a general popularity list.

If you are deciding how much to build, talk to Merge about the smallest useful workflow and the build route that fits your requirements.