Webflow Website + Custom App: How Agencies Can Split the Build

TL;DR

• Separate responsibility from hosting. A Webflow Cloud app can share the site's domain while still needing its own engineering and release process.
• Choose between a Webflow interface with a backend, a separately hosted application and a Cloud app. Test the existing business platform before replacing it.
• Give public descriptions, live business records and private files explicit owners. A course link may identify an item; it must not establish a customer's permissions or price.
• Agree how design changes reach both parts. Shared components do not remove the need to implement application states and review the receiving build.
• Accept the complete journey, including sign-in, an outdated link and a website change after the app works. Two separate successful demos do not establish a working handoff.

A website client asks for a working application

For example, suppose your agency is building a Webflow site for a training company. Marketing needs public course pages it can edit. Employers also need a private area where they can enrol employees, see their bookings and retrieve attendance documents. The training company already has an internal system holding course sessions and participant records.

You can keep responsibility for the website and design without taking on every part of the application. The first decision is what the existing training system can already provide. A supported employer portal may cover the requirement; a new interface may need only a connection to the existing records.

This training-company scenario, its addresses and the proposed checks are hypothetical. They illustrate a delivery arrangement, not a Caemcore client project.

If the portal itself has not been justified, our custom versus off-the-shelf client portal guide covers that choice. Here, the question is how a Webflow team and a software partner divide a project once the required customer journey is understood.

Choose the application boundary, not just its address

A separate application does not necessarily mean leaving Webflow hosting. Webflow Cloud supports code-based, full-stack applications alongside Webflow sites. That is different from adding a Code Embed to a page: Code Embed supports HTML, CSS and client-side JavaScript, not server-side languages.

Compare these routes against the same employer journey. The table describes possible arrangements, not a claim that one is always cheaper or that every project needs custom software.

For a Webflow-built interface, write down which form names, attributes and elements the application scripts depend on. A button's styling can change independently only if the behaviour does not rely on the changed detail. Keep that agreement with the website, rather than relying on the developer remembering which class must never be renamed.

For a separate app, the agency can still design the entire customer experience. The difference is that the developer implements the application interface in its own codebase. A shared brand does not require both teams to edit every screen in the same tool.

For Cloud, verify the actual application dependencies before choosing hosting. Webflow documents a Cloudflare Workers runtime with differences from a conventional Node.js environment. Ask the developer to check the required framework features, authentication library and connected services, rather than assume an existing app will run unchanged.

Assign the work that falls between the two teams

Use the following division as a starting point for the training-company example. Put names beside the responsibilities before estimates are accepted. The agency's design role can be broader or narrower, but someone must own the missing application states as well as the main screens.

One person may cover several roles. What matters is that the arrangement does not leave the Webflow agency acting as technical lead by accident. Asking a software partner to deliver the application means explicitly assigning technical decisions, tests and releases, not merely purchasing development hours.

Keep design acceptance and behaviour acceptance distinct. The agency can confirm that an enrolment screen matches the agreed design. The client must confirm the enrolment rules, and the software team must demonstrate that the resulting records and permissions follow those rules.

Keep the public catalogue separate from private customer records

In this example, let the Webflow CMS hold editorial course descriptions. Keep dated sessions, enrolments and attendance records in the system chosen to own those facts. A course description and a bookable session are different records: rewriting the description should not create a new session or break an existing booking.

Agree a stable identifier connecting each public course to its application record. Treat the public page slug as an address that may change, not the only identifier linking both systems. When a course is withdrawn from marketing, decide separately whether existing employers must still see its bookings and documents.

If session dates or availability are shown on public pages, specify their source and refresh behaviour. At submission, the application must check the current conditions again. Do not confirm an enrolment solely from a copied availability label or a price passed in a website link.

OWASP's authorization guidance calls for permission checks on every request, enforced outside client-side controls, including protection for relevant files. For the portal, hiding another employer's row is not enough. The service returning the record or attendance document must enforce the access rule.

Keep private records out of public CMS output, page source and publicly served downloads. The developer should identify which resources are intentionally public and how the rest are retrieved after authorization. Similarly, an administrative API key must not be pasted into a Webflow embed or browser script. OWASP's secrets guidance supports controlled storage and least-privilege access; ask which configuration is public and which remains protected on the server.

Design the transition through sign-in

Start with one path: a visitor opens a course page, selects the employer action, signs in and lands at the intended course inside their authorized company account. Give both teams the starting page, destination and expected result. Test returning users as well as new accounts.

The public link may carry a course identifier. It should not carry participant details or establish company membership. After sign-in, the application checks the user's access and the selected course. If an item is unavailable, the app should explain that result instead of dropping the customer onto an empty dashboard.

Do not base a new proposal on old Webflow Memberships tutorials. Webflow retired its native User Accounts feature on 29 January 2026. Specify the actual authentication provider or application service being used. That retirement does not prevent an app connected to Webflow from implementing its own sign-in.

When the public site needs no personalized content, it may only need a stable portal link. Avoid creating a second customer account system just to make the website header change after login. If a signed-in header is genuinely required, include session behaviour and sign-out across the relevant pages in the scope.

For a Cloud app at /app, reserve that path and check nested routes, assets and recovery links. Webflow's route rules give the Cloud app precedence when its route conflicts with a Webflow page. The agency must know which paths it should not use for a new campaign page.

Share the design without merging every release

Agree which parts must match: typography, spacing, navigation, form controls and feedback messages. Then design the application states that a marketing-page mockup does not settle. What does the employer see with no enrolled staff, an expired session or a record they may view but not change?

Webflow's DevLink workflow can export styles, variables and components for use in an application. This can support reuse of the visual system. It does not determine the enrolment rules or make a static component behave like a completed application.

Choose a controlled update process. For exported components, the agency approves a design change, the developer brings it into the app, checks the affected states and releases the tested version. Do not promise that publishing the website will update the application unless that automation is actually implemented and tested.

For a manually implemented design system, record the same approval and update responsibility. Either route needs a way to identify when the site and app differ intentionally. A public navigation bar may invite visitors to sign in, while the portal needs company switching and sign-out controls.

Document the release paths separately. Cloud environments can track GitHub branches, with pushes triggering deployments. That is a release route to manage, not an ordinary editorial update. The agreed workflow should prevent an unreviewed experiment from reaching the live application.

Accept one complete journey across both builds

Prepare a protected test website and application using synthetic employers, users and documents. Identify the backend and message destinations before testing. A test frontend connected to live participant records is not an isolated rehearsal.

A URL labelled staging is not an access control. Webflow explicitly notes that a deployed Cloud environment is accessible to anyone with its mount-path URL. Apply the appropriate protection and use non-production services for the rehearsal.

Have both leads demonstrate these checks on the chosen arrangement. They are a proposed joint acceptance exercise, not a complete security assessment.

1. Enter from the actual public page. Open the course page on desktop and mobile, follow the employer link, complete sign-in and reach the intended course. Verify the company account and current course details. Complete the agreed enrolment action and inspect the saved record; retrieve an allowed document from an existing test booking. Do not start the demonstration from a developer's already-authenticated portal tab.
2. Handle an old or altered link. Rename the public course slug in the test site and exercise the agreed redirect and application mapping. Open a withdrawn or invalid course reference, and try another company's protected document using a restricted test account. Each result should follow the defined rule rather than reveal unrelated records or silently choose a different course.
3. Recover when the backend cannot answer. Simulate an unavailable course service before submission. Check the loading and failure messages, retained user input where appropriate, and the route for getting help. The interface must not claim that enrolment succeeded without the required confirmation.
4. Change each side independently. Publish a test website change, then deploy a test application change, following the proposed release routes. Repeat the customer journey after each. For connected Webflow elements, check the attributes and scripts; for a mounted app, check nested links and assets; for shared components, inspect the imported version.
5. Hand the release to its operators. Have the receiving owners locate the deployed app revision, website version, configuration locations and incident instructions. Rehearse the applicable rollback in the test environment. If the app change affects stored data, show how recovery preserves new work rather than assuming a website restore reverses it.

Save the results with the tested versions and unresolved items. Require an owner for a failure spanning the site and app. A website team and software team can each complete their own checklist while the client's full journey still fails.

Scope the shared work before quoting the client

Ask the proposal to identify the website work, application work and work connecting them. The connecting work includes design handover, course identifiers, sign-in destinations, shared tests and launch coordination. Do not leave it unpriced because both teams describe their own deliverable as complete.

Separate one-time implementation from the required account plans, application hosting, identity services and human support. Compare the proposed configuration, not a platform's cheapest advertised plan. Agree who pays each provider and who retains account recovery and administration access.

If a ready-made portal completes the employer workflow, the smaller project may be website design plus configuration and integration. If only a narrow interaction is missing, test a connected interface before commissioning a full application. A split build is useful when it lets each team own the required work, not when it adds a second system without a reason.

When you need a software partner, our comparison of development partners for design agencies covers candidates and collaboration questions. Discuss Caemcore for the custom business system and integrations, with the agency's design and website role agreed separately. That does not assume a standardized white-label programme or require replacing Webflow.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can the Webflow website launch before the application?

Yes, when it has a useful standalone purpose and every public action leads to something available. Keep the existing enquiry or booking route until the replacement is accepted. Do not label an enquiry form as confirmed enrolment or invite customers to create accounts that will be discarded. Agree how the portal link changes at the later launch.

Can we keep the client's existing customer login?

Investigate that first. Identify the current identity provider, account ownership and supported integration, then test an existing customer's sign-in and recovery against the intended records. Retaining the same email address is not proof that the same account relationship survives. State whether another login is required instead of promising a shared session from the domain name alone.

Can payments be added after the first portal release?

Yes, if the first workflow can operate through the client's existing invoicing process. State when a place becomes reserved or confirmed and keep payment status distinct from enrolment status. Adding checkout later also requires rules for failures, cancellations and the records staff reconcile. Do not price it as a button when it changes those business decisions.

Should the private portal appear in search results?

Decide separately for public information and customer records. Keep useful public course pages available for discovery, while protecting private records through authentication and authorization. Google's noindex rule controls search visibility, not who can visit a URL. Apply indexing rules deliberately without treating them as a replacement for access controls.

How should a multilingual website hand customers to the app?

Include language in the shared journey. Agree which portal languages are supported, how a selection reaches the application and what happens when a translation is unavailable. Keep course identifiers independent of translated page titles. Test sign-in, errors and transactional messages as well as the first screen; a translated marketing page does not establish a translated service.

Sources

• Webflow, Webflow Cloud introduction. Checked 14 September 2026.
• Webflow, Custom code embed. Checked 14 September 2026.
• Webflow, About the Webflow Cloud edge environment. Checked 14 September 2026.
• OWASP, Authorization Cheat Sheet. Checked 14 September 2026.
• OWASP, Secrets Management Cheat Sheet. Checked 14 September 2026.
• Webflow, User Accounts sunset. Checked 14 September 2026.
• Webflow, Environments. Checked 14 September 2026.
• Webflow, Getting started with DevLink. Checked 14 September 2026.
• Google Search Central, Control what you share with Google. Checked 14 September 2026.

Platform details were checked on 14 September 2026. The training-company scenario, division of responsibilities and acceptance exercise are hypothetical editorial tools, not reported client results or a complete security assessment. Caemcore's service description follows its approved first-party materials.