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).