Wix Velo for Developers: What You Can Build and Where It Stops

Velo is genuinely more capable than developers assume, and genuinely more limited than Wix’s marketing implies. This is an assessment of both, so the platform decision can be made before rather than after the build.

What you actually get

That set is enough for a booking system, a members area, a light catalogue, a lead-capture flow integrated with a CRM, or a content site with dynamic pages driven by a collection.

The one security rule that matters

Page code runs in the visitor’s browser. Backend code in a .web.js module runs on Wix’s servers. Everything sensitive — API keys, business logic, anything that writes — belongs in the backend, and every backend function is a public endpoint that must validate its own inputs and check permissions.

// backend/orders.web.js
import { Permissions, webMethod } from 'wix-web-module';
import { currentMember } from 'wix-members-backend';
import { getSecret } from 'wix-secrets-backend';

export const submitOrder = webMethod(
  Permissions.SiteMember,          // never Anyone for a write
  async (payload) => {
    // The caller controls the payload entirely. Validate before trusting it.
    if (!payload?.sku || typeof payload.quantity !== 'number' || payload.quantity < 1) {
      throw new Error('Invalid order');
    }

    const member = await currentMember.getMember();
    const key    = await getSecret('FULFILMENT_API_KEY');   // never in page code

    return dispatch(key, { sku: payload.sku, quantity: payload.quantity, memberId: member._id });
  }
);

Permissions.Anyone on a function that writes data or spends money is the single most common Velo vulnerability. The other is trusting a price sent from the client — always look it up server-side.

Data collections and their ceiling

Collections are convenient and they are not a relational database. There are no joins; a reference field gives you one hop and anything deeper is application-level assembly. Query filtering and sorting work well on small to moderate datasets and degrade as collections grow, particularly with multiple filters and a sort.

Practical guidance: denormalise the fields you filter and sort on, keep the number of items in the low tens of thousands, and paginate everything. If the data model wants joins across three collections, the project has outgrown the platform.

Where Velo genuinely stops

These are the constraints worth being honest with a client about before starting:

• No real version control. Wix has its own release mechanism and a Git integration, but this is not a branch-and-review workflow. Code review, meaningful diffs and reverting a single change are all harder than they should be.
• No local development loop. You work in Wix’s editor against Wix’s runtime. No local server, limited debugging, and no running the site on your machine.
• Limited automated testing. There is no natural place for a unit test suite or CI. Testing is largely manual, which caps how large a codebase can responsibly get.
• You do not own the rendered output. Markup, script loading and much of the critical path belong to Wix. You can improve images and defer your own code; you cannot restructure what the platform emits. Core Web Vitals therefore have a floor you cannot go below.
• No npm ecosystem in full. A curated set of packages is available, not arbitrary dependencies.
• Migration is a rebuild. Content in collections can be exported; page structure, layout and Velo code cannot be carried anywhere else.

When Wix plus Velo is the right answer

It is a good fit when a non-technical team must own day-to-day content and layout, the interactive requirements are modest, the data model is shallow, and nobody wants to operate hosting. For a small business site with a booking flow and a CRM integration, it is frequently the most sensible choice available, and insisting on a custom stack would be over-engineering.

It is the wrong fit when performance is a competitive requirement, when the data model needs relational integrity, when several engineers need to work in parallel with review, or when the roadmap points at a product rather than a site. In those cases a real CMS with a real front end — the approaches in Building Scalable Headless CMS & Gutenberg Architectures — costs more up front and less over three years.

If you are already on it

• Move every secret to the secrets manager and every write to a permissioned backend module.
• Audit Permissions.Anyone across all web methods; treat each one as a public API.
• Verify signatures on HTTP functions receiving webhooks — the same discipline as any webhook endpoint, covered in Designing Resilient Multi-Platform Data Pipelines.
• Reduce image weight and defer non-critical code; that is the performance headroom you actually control.
• Export collection data on a schedule, so the content is not hostage to the platform.

Questions people actually ask

Can I use npm packages in Velo?

Only from the curated set Wix exposes, not arbitrary packages from the registry. Check availability before designing around a specific library – discovering a dependency is unavailable after the architecture depends on it is an expensive surprise.

Is Velo code version controlled?

There is a Git integration and a release mechanism, but not a normal branch, review and revert workflow. Plan for that: keep changes small, document them externally, and do not assume you can cleanly roll back one change from a batch.

How do I keep API keys out of the browser?

Store them in the Wix secrets manager and read them only inside backend .web.js modules. Anything in page code is visible to any visitor who opens developer tools – there is no obfuscation that changes this.

Can I fix Wix Core Web Vitals?

Partially. Image weight, your own script loading and above-the-fold content are within your control. The platform’s own markup and script bundle are not, so there is a performance floor. If Core Web Vitals are a competitive requirement, that floor is the argument for a different platform.

At what point should a Wix project move off the platform?

When the data model needs joins, when several engineers need to work with code review, when automated tests become necessary, or when performance is a business requirement rather than a preference. Migrating is a rebuild, so it is worth recognising the trajectory early rather than after two years of accumulated Velo code.