Turning a Prototype into a Drupal System

What a prototype is for

A prototype helps test whether a feature serves the business goal and whether people can use it. A working demonstration gives you a reason to continue, but security and integration still need review before production.

The mistake I see most often is treating a successful demonstration as evidence that the implementation is ready to become part of the existing system.

What follows is what I look for when a prototype has to become part of Drupal. Your developers may have built it. You may have vibe-coded it. The checks are the same.

The three questions

I review compatibility, asset isolation and security before planning the integration.

Is it compatible

Drupal manages configuration and it manages content, and it keeps the two apart on purpose. Configuration is the shape of the site and moves between environments. Content fills that shape and stays where it is.

A prototype stores its settings wherever was convenient: a table it created, a file next to the code, constants in a class. In a prototype this is fine. Inside Drupal it means two systems both believe they own the site configuration. Only one of them can be exported, reviewed and deployed. The settings outside it have to be changed by hand on every environment, and they drift as soon as somebody forgets.

Content stored outside Drupal’s content system does not automatically benefit from its access control, revisions, translation, search indexing and cache invalidation. Those features need explicit integration or separate implementations, or the site goes without them. The missing revision history may only become obvious when an editor asks why they cannot undo a change.

Is it isolated

The second question is what the prototype leaks into everything around it.

Prototype assets are written for a page where nothing else lives. The CSS assumes it is the only stylesheet. The JavaScript assumes it owns the document. Attached globally inside Drupal, which is the easiest way to attach them, that CSS now reaches every page and that JavaScript runs where it was never tested. The resulting conflicts can appear on other pages, making them hard to trace back to the integration.

Drupal’s library system lets you limit where assets load. Assets are declared as libraries and attached to the thing that needs them. Prototype assets almost never arrive that way. Moving them is small work. Leaving them creates a class of bug that keeps coming back.

Three more things travel in with the assets:

• Minified libraries with no source or version information. These are harder to inspect and update. When a vulnerability is reported, you need to know which version you have.
• Hard-coded strings. Text that bypasses Drupal’s translation mechanisms creates extra work for multilingual sites. Editorial text kept in code also requires a deployment to change.
• Theming that ignores the theme. A prototype styled with its own colours and spacing looks correct once. It does not follow theme settings, so it stops matching as soon as anything around it changes.

Is it secure

Drupal’s security model is strong because it is consistent. Entity access decides who may see and change a thing. The form system issues tokens. Twig escapes output unless you insist otherwise. The database layer keeps queries parameterised. The value is in the consistency, not in any single mechanism. Custom code needs to use these mechanisms consistently too.

Prototypes often receive less security review because they are built for a limited demonstration. What I find is rarely exotic. A route with no access check, because the only user was the developer. Output printed raw, because it was their own text. A query built by string concatenation, because it was faster to write. An upload that trusts the filename it is given.

These need review even when the rest of the site uses Drupal’s security APIs.

Everything that does not serve the goal

Prototypes often accumulate features because they were interesting to build. Before integration, check whether each one is useful enough to justify its maintenance cost.

Two examples I keep meeting are heavy JavaScript animation with no clear purpose and expensive AI models used for routine tasks such as image tagging. The animation may be unnecessary; the tagging may work with a smaller model. These are decisions to test against the business goal before other parts of the system start depending on them.

Business logic mixed with render logic

Another common source of rework is business logic mixed with rendering. Deciding what to show and deciding how to show it happen in the same place.

This can be hard to notice in a prototype with one screen, one user role and one language.

Then it meets real use. A second variant appears. A permission hides part of the output from some people. A translation arrives. A cached version has to be invalidated when something upstream changes. An editor wants to change wording without a deployment. Each of these needs the decision pulled apart from the display. Because the two were never separate, the separation has to happen across the whole component at once.

Found early, this is a conversation and a small change. Found late, it is a rewrite of the thing everyone already considers finished. This is why the review happens before the integration, not after it.

Building for Drupal from the start

Where there is a choice, the better prototype is the one built against Drupal from the beginning. It costs a little more at the start, and everything learned in it transfers directly, because it was learned in the system that will run it.

If the prototype already exists outside Drupal, assess what can be reused and what needs replacing. AI tools can help adapt the code, but the result needs the same review as any other implementation. Generated code can still have the compatibility, asset and security problems described above.

Before calling the integration finished, check that it can be configured, deployed, translated, secured and maintained by somebody who did not write it.