Cantilever’s development team works with three distinct web platforms – JAMstack (Sanity headless CMS + Next.js), LAMP (Craft CMS, often with Craft Commerce), and Webflow. Each platform has unique strengths and trade-offs. This guide compares them across key dimensions to help our strategy team (non-technical stakeholders) decide which is best suited for a given client project. We focus especially on when to choose a custom JAMstack approach versus a LAMP/Craft solution, with Webflow as a third option. The goal is to match client business needs to the most appropriate platform in clear, jargon-free terms.
JAMstack (Sanity + Next.js): Very few inherent software limitations – you can build almost anything – but dynamic features require extra services. Out of the box, a Jamstack site doesn’t handle things like user logins or e-commerce without integrating external APIs or custom code. For example, forms and authentication must be wired to third-party services or serverless functions. This adds complexity, and regulated use-cases (e.g. storing medical info under HIPAA) demand careful selection of compliant services. On the upside, there is no monolithic system imposing constraints; you define the capabilities you need. Essentially, the only “limits” are development effort and the need to assemble various services for functions like search, forms, or auth.
LAMP (Craft CMS/Craft Commerce): Craft CMS is a robust traditional CMS, so it has fewer functional limitations than a no-code tool – developers can extend it with plugins or custom PHP code as needed. However, it runs on a LAMP stack (PHP, MySQL, etc.), which means you must manage server software and updates. High-traffic or very large sites can face performance issues if the server environment or caching isn’t optimized. Craft has licensing costs and a smaller ecosystem than WordPress, so some niche integrations might require custom development (fewer ready-made plugins). It handles forms and content well via plugins (e.g. Freeform for forms) but something like an elaborate multi-step form or real-time features could require extra coding. HIPAA compliance is achievable (since you control hosting and can ensure encryption, BAAs, etc.), but it’s on the implementer to set up a compliant environment. In short, Craft imposes minimal feature limitations but comes with the responsibilities of a self-hosted solution.
Webflow: Webflow is a closed platform, so certain advanced requirements simply can’t be met if they fall outside Webflow’s feature set. For instance, Webflow does not natively support multilingual sites – this has been a top user request since 2017 and as of 2024 still isn’t built-in. Workarounds (like duplicating sites or using third-party translation scripts) are possible, but they add complexity and can hurt SEO. There are content limits to keep in mind: a Webflow project supports a maximum of 100 static pages , and its CMS collections (for dynamic content like blog posts or products) are limited to 10,000 items total on the highest standard plan. If a client envisions tens of thousands of pages or items, Webflow may not scale without an enterprise account or splitting content across sites. Webflow also only recently introduced Memberships (user login areas) in beta, so robust user accounts or gated content were historically not available. Even with the new feature, Webflow’s user-authentication system is in early stages and not as flexible as a custom build. Another critical limitation: Webflow is not HIPAA compliant – the company does not sign Business Associate Agreements and lacks required data encryption for medical data. This means healthcare clients or anyone dealing with sensitive personal data should avoid Webflow’s forms/back-end for that data (though one could embed a third-party HIPAA-compliant form service as a workaround). Overall, Webflow is feature-rich for general marketing sites, but if a project needs capabilities outside its menu of offerings (complex forms logic, advanced search, external database integrations, etc.), you may hit a wall.
JAMstack (Sanity + Next.js): This approach offers developers maximum control and a modern workflow. The developer experience is code-centric – building with Next.js and using Sanity’s APIs. Teams can use Git for version control, pull requests, and all the best practices of software development. In fact, Sanity integrates well with developer workflows; content schemas and even content can be managed in code and reviewed via GitHub PRs. This means a high degree of collaboration and quality control is possible for code and content model changes. Developers skilled in React/Next.js will enjoy the flexibility: they are free to structure the project as they see fit and can incorporate any libraries or integrations needed. The trade-off is that it requires specialized skillsets – you need front-end developers comfortable with React, and possibly DevOps knowledge for setting up builds and deployments. Maintaining a JAMstack site is essentially maintaining a custom application; adding new features means writing code (there’s no pre-built plugin to toggle on). So while the developer experience is powerful, it’s geared to those with a software engineering background. In summary, JAMstack is developer-friendly in terms of tools and freedom, but it absolutely requires experienced developers to build and maintain – it’s a custom build, not a turnkey system.
LAMP (Craft CMS): Craft CMS is often praised by developers for its elegant and flexible architecture. It uses Twig templating for front-end, which keeps code organized and readable, and the CMS structure doesn’t impose heavy “lock-in” – you can build content models as needed. For a developer with PHP experience, Craft provides a good balance: you get a lot of CMS functionality out-of-the-box (admin UI, user management, etc.) but also plenty of extensibility. The learning curve for Craft is relatively gentle for those familiar with web development, though newcomers to PHP or CMS development will have to learn Craft’s conventions. Setting up Craft involves configuring a web server, database, and the CMS itself, which is more involved than a cloud platform. Collaboration can be managed via Git for template/code changes, and Craft supports content migration files to propagate database schema changes. However, the content (entries) in databases doesn’t version as easily as code. Overall, Craft demands a moderate developer skill level: you need to know web development (or have a developer on hand), but you don’t need to reinvent the wheel for basic CMS features. There is a learning curve to master all components of the LAMP stack and Craft’s system, so a newbie developer might struggle initially. Once up to speed, though, developer productivity is high – Craft is “built for developers” in the sense that it’s very customizable and doesn’t fight you. In short, Craft offers a polished developer experience if you have web programming knowledge, whereas non-technical team members would not be able to set up Craft without developer help.
Webflow: Webflow’s ethos is “no code” for the user, which means the “developer” experience is very different. Essentially, the Webflow Designer tool is the development environment – a visual IDE for building websites. For someone with front-end skills, Webflow can feel liberating (no need to wrangle build tools or hosting) but also limiting. Traditional developers may find the lack of direct code access frustrating – you can add custom code in limited chunks, but you cannot freely manipulate the underlying server or use Git. Collaboration on Webflow projects is improving but still not on par with code-based workflows. For example, Webflow lacks a robust version control or multi-developer code review system (no equivalent of Git pull requests natively). Changes are made in the visual editor and published, which can be challenging to manage on larger teams or complex projects. On the flip side, Webflow is extremely accessible to non-developers or designers. A technically savvy designer can handle what would normally require a front-end dev – creating layouts, responsive styles, even animations – all through the UI. This speeds up development for straightforward sites and empowers design teams. There’s also a large community and many Webflow University tutorials, which lowers the barrier to learning. If custom functionality is needed, developers can inject code (e.g., an embed or hooking up an API via JavaScript), but it’s not the primary workflow. In summary, Webflow provides a fast, low-code development experience for building standard websites, but complex developer tasks (like large-scale code integration or advanced build processes) are not supported. It’s ideal when you have limited dev resources or tight timelines, and less ideal when a project demands heavy custom engineering or multi-developer collaboration.
JAMstack (Sanity + Next.js): In a headless setup like Sanity, the content editors work in the Sanity Studio, which is a separate admin interface (not on the live site). The experience for editors can be very good, but it depends on how we configure it. We have the ability to totally customize the editing interface to match the content model. For example, we can create custom input fields, content blocks, and workflows in Sanity that make it clear how to enter content. An editor might see fields for “Title,” “Body,” “Author,” etc., or even custom modules they can add (text blocks, images, etc.) if we build that in. This tailored approach can make content updates intuitive – editors only see the fields relevant to their content and can build pages by assembling predefined content blocks (without needing a developer). Sanity even supports real-time collaboration (multiple editors editing content simultaneously, like Google Docs style) and content versioning, which is a plus for content teams. However, because JAMstack decouples editing from the site, editors don’t get a real-time visual preview by default (we can set up preview modes, but it’s extra configuration). The editing is form-based rather than WYSIWYG drag-and-drop on the actual page. Non-technical editors may find this less immediately intuitive than, say, editing text right on a webpage. It requires training to understand the content schema. In short, Sanity’s editor experience is as intuitive as we make it – it can be very straightforward for structured content and allows custom help text, live previews, etc., but it is a structured form interface. For content-heavy sites where consistency is key, editors often appreciate the clarity. They don’t need to worry about design (that’s handled by the code), only the content. If a client expects to “move this image a bit to the left” on their own, a headless CMS won’t allow that – they’d need a developer to alter the front-end code. So the JAMstack approach favors organizations where editors are comfortable with a content form interface and the site is designed to enforce design consistency.
LAMP (Craft CMS): Craft CMS is known for an excellent authoring experience for non-developers. The control panel is clean and intuitive, organized with a left-hand menu for sections, entries, assets, etc.. Editors can easily create or update entries (pages, blog posts, products, etc.) via fields that developers set up. Craft supports rich text fields, image uploads (with an image editor), relations (e.g., relating a staff bio to a department), and more. It also has draft and preview features – an editor can create a draft of a page, hit “Live Preview,” and see exactly how it will look on the site in real time before publishing. This gives some WYSIWYG confidence while still maintaining structure. Craft’s matrix field system even lets editors build flexible content layouts (like adding customizable content blocks within a page) in a controlled way. User roles and permissions in Craft can be granular, so we can allow, say, a “News Editor” to only access the News section, etc.. This is useful for larger teams. Overall, editors usually find Craft intuitive and powerful – it’s often cited that despite being developer-centric, “Craft’s admin panel is intuitive for content creators”. The only caveat is that because Craft can be configured in many ways, the initial editorial interface is as good as the implementation. We need to design the backend fields thoughtfully for a top-notch editor experience. Assuming we do that, Craft provides things like scheduled posts, content revisions (version history), and search-and-replace across content, all of which make editors’ jobs easier. Training an editor on Craft tends to be quick; if they can use WordPress or any modern CMS, they usually adapt to Craft with little trouble. In summary, Craft CMS offers a very friendly content editing experience – editors get a straightforward interface to manage content, with live preview and other conveniences, without needing to touch any code or layout issues.
Webflow: Webflow shines when it comes to empowering non-technical users to manage content and design to some extent. There are two modes relevant to editors: the Designer and the Editor. The Designer is the full interface used to build the site (intended for developers/designers). The Editor, however, is a simplified in-context tool for content editors. An editor can click on a text on the live website (in Editor mode) and change it right there, or update images and CMS items through a sidebar – all without touching the visual design controls. For many clients, this is extremely intuitive: they essentially browse their website, hit an “Edit” button, and then can click and edit content on the page as it appears. Webflow also provides fields for SEO settings, Open Graph, etc., in a user-friendly way when editing pages or CMS items. The learning curve for a pure content editor is minimal – if you can fill out an online form or edit a Word document, you can likely handle Webflow Editor. Where Webflow is less editor-friendly is if the client wants to drastically change site structure or design on their own. That still requires using the Designer, which, while code-free, does assume a bit of technical/design savvy (someone can break a layout if they don’t know what they’re doing). But for day-to-day content updates (text, photos, new blog posts, swapping a banner image), Webflow offers a smooth, visual experience. Editors do not have to worry about breaking the site by adding content – the templates ensure design consistency. One more benefit: since Webflow is hosted, editors don’t have to deal with separate staging environments unless we set one up – they can edit content on the live site (or a staged copy) and publish changes instantly. On balance, Webflow is extremely editor-friendly for routine content edits, arguably the easiest of the three for a non-technical user to pick up. It was built for the scenario of a marketing team member quickly updating the site without calling a developer. The only scenario that might trouble editors is if the site demands content changes that also require structural changes Webflow can’t accommodate (but then it’s more a platform limitation than an editor issue).
JAMstack (Sanity + Next.js): This option is the ultimate in flexibility – anything you want to build, you can build. There are effectively no template constraints. We hand-code the front-end, so we can implement any design, interaction or integration that serves the business. Need a complex calculator tool on the site? We can code it. Want to integrate with an obscure third-party via API? No problem – we have full programming capability. Sanity as a headless CMS is also highly flexible: we define custom content types and structures from scratch. Because there are no pre-built assumptions in Sanity, developers can create truly bespoke content models and editing interfaces. This means the system can adapt to very specific client needs, rather than forcing the client into a one-size-fits-all model. The trade-off for this unlimited flexibility is that everything is custom-built – which takes time and specialized skill. If later the client wants a new feature, a developer has to build it (but again, it’s possible to build anything). The JAMstack approach is future-proof in the sense that modern frameworks like Next.js are continuously improving and not likely to become obsolete soon, and headless content can be reused in new front-ends (even mobile apps) down the road. It’s also easy to integrate new services: you can send or fetch data to/from any system because you aren’t confined by a CMS plugin ecosystem. In summary, JAMstack provides maximum customization: “Build anything! Unlimited possibilities for features and growth… not what a template or plugin limits you to”. The only limits are development resources and imagination. This makes it ideal for projects with unique requirements or likely to evolve in unpredictable ways (you won’t hit a dead-end – you can always extend the code).
LAMP (Craft CMS): Craft CMS is often chosen for its balance of flexibility and structure. It’s not quite “anything goes” like a from-scratch Next.js app, but among CMS platforms Craft is highly customizable. Craft starts as a blank slate in terms of site building – no forced themes or structures – developers create all templates and content types. That means we can achieve custom designs and complex functionality within the Craft framework. Craft’s plugin architecture and Yii/PHP underpinnings allow for extending it as needed (one can write custom modules or use community plugins to add features). For example, if we need to integrate a CRM, we could write a module to push form data to that CRM’s API. If we need a special navigation menu that updates based on user login status, we can code that logic in Craft. Essentially, Craft lets developers “craft” bespoke solutions (true to its name) without the rigidity seen in more off-the-shelf CMS platforms. Where is it less flexible than JAMstack? Because it’s an integrated CMS, you are working within PHP and the CMS context – for extremely novel features, you might need to step outside that stack (which is rare). But practically, Craft can handle most website needs from simple to complex. One advantage is that a lot of common needs (multi-language, user roles, e-commerce via Craft Commerce, etc.) are already solved within Craft’s ecosystem, so you’re not reinventing the wheel – you customize by configuring or lightly extending, rather than coding entirely from zero. Craft doesn’t impose design restrictions; our front-end can be as unique as we want since we write the HTML/CSS/JS for it. In terms of templates and features, Craft is very flexible – far more so than Webflow or WordPress themes – but it’s not a “no code” flexibility; it’s developer-driven flexibility. Also, if a requirement is totally outside Craft’s domain (say real-time multiplayer functionality or something web-app-ish), one could still integrate it, but at that point a JAMstack or web app approach might make more sense. To sum up, Craft CMS provides high customization potential with a strong CMS backbone: it’s ideal for complex sites where you need custom data structures or workflows, but you want those within a managed CMS environment rather than writing a whole application from scratch.
Webflow: Webflow’s flexibility is best described as “within the box”. It’s impressively flexible in enabling custom designs – you can implement custom layouts, typography, animations, and so on, to a degree that rivals hand-coded sites. For most marketing websites, this is sufficient. You’re not limited to pre-made templates; our team can design from scratch in Webflow’s visual canvas and achieve a unique look and feel. However, when it comes to adding functionality beyond what Webflow offers, you start to see the walls of the box. Webflow provides a set of building blocks and features (CMS collections, basic form handling, e-commerce, some logic flows with its new Logic feature, etc.), but if you need something it doesn’t provide, the options are limited. You might use an embed code component to insert custom HTML/JS – for small widgets or third-party scripts, this is fine, but you don’t have a full development environment to build complex interactive applications inside Webflow. Also, certain patterns like deeply nested content relationships or very complex filtering of content can be challenging. There is “very little customization through code or scripting in Webflow compared to other platforms” , meaning you rely on what Webflow can do out-of-the-box. Another way to put it: “Within the limitations of Webflow, we can build exactly what we want… but the possibilities are limited compared to coding where everything is possible.”. So for example, adding a completely custom checkout flow or a non-standard e-commerce discount logic would be very hard in Webflow; in Craft or JAMstack we could code it. On the bright side, Webflow’s built-in features cover a wide range of typical needs (SEO settings, forms, lightboxes, sliders, etc.) and they keep expanding what you can do without code. If a client’s needs match what Webflow was built to handle (marketing sites, small e-shops, portfolios, etc.), then Webflow’s constraints won’t be felt and we get both flexibility in design and the efficiency of not coding. But if a client comes with a very custom requirement (say a multi-step form that interacts with a database and user accounts), Webflow might not be the right fit. In summary, Webflow is highly flexible in design and standard content presentation, but it is the least flexible in terms of deep custom functionality. It trades ultimate flexibility for ease of use.