August 11, 2026
People ask us whether they need a website or an app, but that's the wrong framing. The real question is: does this project mostly publish information, or does it manage state? A page that tells people what you do and lets them reach you is publishing. A tool that tracks who booked what, who owes what, or who can see what is managing state. ViibeStack has separate tools for these because they solve different problems -- the website builder is built for content that changes occasionally and forms that collect leads, while the AI app builder is built for data that changes constantly and users who need different levels of access to it.
Run your project through these six questions. If you answer 'yes' to two or more, you're building an app, not a website. 1. Does anyone need to log in to see something specific to them (their orders, their appointments, their invoices)? 2. Will the same record get edited by more than one person over time (a booking gets rescheduled, a ticket gets updated, inventory gets adjusted)? 3. Do different people need different permissions -- an admin sees everything, a client sees only their own stuff, a contractor sees only assigned jobs? 4. Does the thing you're building need to trigger a workflow -- an approval, a notification, a status change -- rather than just sit there? 5. Will you need reporting on the data later (how many bookings this month, which client hasn't paid)? 6. Is the core value of the project the information itself, or what happens after someone submits information? If most of your 'yes' answers point to state changing over time and people needing different views into it, you're in app territory. If your project is really about presenting something once and capturing a lead or a message, you're in website territory, even if it has ten pages and three forms.
A landscaping company wants a site with a homepage, a services page, a gallery, and a contact form that emails the owner. That's content plus forms. It doesn't matter that the form has eight fields or that there's a quote calculator widget -- nobody is logging in, no record gets edited after submission, and there's no permission model. Build it as a website. Now take the same landscaping company but they want clients to log in and see their upcoming service dates, reschedule if needed, and see an invoice history. The moment reschedule and invoice history show up, you've crossed into data plus workflows plus logins. That's an app, even though the marketing pages around it are still a website. This is the exact shape of project we walked through in how to price a client portal build -- the portal is the app, the marketing site is the website, and they're two different builds even when the client thinks of it as one project. A gym wants a page describing class schedules and a sign-up form. Website. A gym wants members to book specific class slots, see their remaining credits, and have staff track who showed up. App -- you're now managing inventory of a kind (class slots) and workflow (check-in), which is the same pattern we covered in equipment tracking in a spreadsheet: the spreadsheet works until two people need to edit the same record at the same time, and that's your signal to move to an app.
The most common mistake is starting an app project in the website builder because it 'just needs one form.' Then three months later there's a spreadsheet of client submissions nobody can search, no login for clients to check status, and no way to notify anyone when something changes. The form was never the problem -- what happens after the form is submitted is. If your form results need a status, an owner, or a next step, that's a workflow, and workflows belong in the app builder, not bolted onto a website with a form-to-email integration. The second mistake runs the other way: building a full app for something that's really just a brochure with contact capture, because 'app' sounds more serious. This adds login screens and permission setup nobody needed, which slows down launch for no benefit. If you're unsure, our FAQ and the glossary have plain definitions of terms like 'workflow' and 'record' that can help you self-diagnose before you start building either way.
Guessing wrong on ViibeStack isn't a rebuild-from-scratch problem, because both tools sit on the same underlying platform. If you started with a website and it's outgrown itself: - Keep the site as-is for your marketing pages -- homepage, services, about. - Spin up an app project for the part that now needs logins and records (client portal, booking system, ticket tracker). - Link between them: the website's 'Client Login' button points to the app's login page. Most service businesses end up running exactly this two-project setup, and it's the intended pattern, not a workaround. If you started with a full app and realize half of it is really just static content -- an 'About Us' tab, a static FAQ page sitting inside your app's navigation -- pull that content out into a website project instead. It'll load faster, rank better in search, and be easier for a non-technical teammate to edit without touching your app's data model. The how it works page walks through how project types share the same account and can reference each other, so this isn't a migration in the painful sense -- it's mostly re-pointing navigation and moving content blocks, not rebuilding data structures. If your app is genuinely small and you're now wondering whether you needed the overhead of logins and permissions at all, that's worth checking against a role-based permissions setup guide before you strip anything out -- sometimes what looks like overhead is actually the one thing keeping client data separated correctly.
Ask what changes after someone interacts with your project. If the answer is 'nothing, I just get notified,' build a website. If the answer is 'a record gets created, updated, assigned, or reported on,' build an app. Most real businesses eventually need both -- a public-facing site and a private tool behind a login -- and ViibeStack is built so that's two coordinated projects, not two separate vendors and two separate logins for you to manage.