What our
clients want
HelloSign
HELLOSIGN DEVELOPER NOTES BELOW:
I think #1-3 are items that will force us off of Webflow in the short term, but all of these will be blockers in the long run.
1. Multiple Webflow environments (eg. Dev staging) - this is a big blocker for us, particularly when we are staging upcoming releases and functionality. We would want to be able to gate this somehow (using VPN or some sort of internal firewall) rather than just unindexing the domains. Wed also need to be able to configure this using custom domains, to help resolve CORS issues and any other potential cross domain issues.
2. Selective publication controls - it is a massive blocker that we cannot selectively publish pages, but rather it has to be the entire directory tree at a time. This can actually block work from getting done on the website, or requires careful planning to make sure stages content remains in our staging site (Webflow.io) and not our production site. To me, this is probably the biggest reason why we would consider a move from Webflow, as I probably spend more time QAing our production environment to ensure that everything that is supposed to be published is published, and everything that is not supposed to be published is still staged.
3. Page count limits - aside from above, the page count limit is a massive blocker for our team to scale our marketing presence using Webflow. I understand the workaround using collections, but I’m not interested in learning a Webflow-specific hack to create a one-off page (that process doesn’t scale and frankly is quite cumbersome). 100 pages is tough for a company of our size; we it hasn’t been a huge issue yet but I expect our team to hit that limit within the next 6months to a year, which would leave us no choice but to find an alternative solution.
4. Granular user permissions and multiple editors in designer mode - this hasn’t been a huge issue yet, but having more than one user in designer will be important to get more done with our marketing website. Additionally, it would be nice to grant specific user permissions, such as page-level access and edit restrictions, as well as a general publication permission.
5. Asset manager changes - it would be great to be able to rewrite an existing image, use folders for related images, and set our own image path, without Webflow hashing image names for us. This is particularly challenging when working with batches of images outside of the native Webflow editor as well (eg. In custom JavaScript code)
6. Upload JavaScript and JSON files (non-lottie) to Webflow - as we scale as a business, we are writing a ton of custom code to handle various experimentation and integrations with tooling on our Website. It would be nice to leverage the Webflow asset manager for this, but we instead need to use an S3 bucket to fulfill this need. I should note that we will likely use S3 to handle #5 in the near future as well.
7. 10000 character limitation for custom code - I think Webflow’s No Code philosophy is really unique and important, but doesn’t scale for a business of our size. Thankfully we can bypass this using our S3 bucket, but I’ve gone through some great trouble to try to optimize a snippet of code to work across three to five custom code blocks due to the character limit. I definitely agree that we shouldn’t be putting a ton of custom code into a page header or footer, but this limit does present some challenges, especially because we usually use it for a quick, temporary fix for an issue.
8. Advanced logging - it would be great to have better logging, specifically around downtime and other errors on our website. In the past, I’ve typically reached out to Webflow support when there is an issue, and they’ve mentioned that “everything is fixed now” more often than not. It would be nice to pinpoint what exactly happened and how we can prevent it from happening in the future, and I think logging would be a good first step.
9. Manual CSS writing control - Webflows CSS editor is incredibly powerful and intuitive, but more often than not, I’ve accidentally overwritten an existing combo class that breaks a critical element on our home page, or other high visibility page. It would be great to have manual control over our style sheet, rather than just making edits in the GUI interface. I am also considering switching the bulk of our style sheets over to S3 in the future.
Developer complaint: Better staging, testing, and publishing environment. This would be an ideal solution for HelloSign -- hellosign.com is on two different Webflow builds. Both builds are 'synced'. One build acts as the staging environment, one acts the live version. Anyone can do anything they want to the staging environment. Designer mode, editor mode, everything that you can do in a normal build. Only an admin can push the staging build changes to the live version. The admin can push individual pages from the staging build to the live build. They get a log of potential issues with css. Note: I understand that this ask is complex!
Marketing team complaint: Publish to webflow.io in Editor. They hated this one. Made no sense to them. This is frustrating for any team -big or small - that has Editors. Everyone is always, "what? really?" when we tell them how this works.
Intuit
SSO for Intuit employees to access internal content. No highly sensitive data, no account management. Just a way for people to access Intuit education content. They're our only client (seriously the only) that is hosted outside of Webflow.
Dropbox
Publish to webflow.io inside Editor. We just launched a content-based site for Dropbox. They're very excited to get their editorial team inside Editor. Almost all changes to the website will be coming from Editor - they essentially have no staging environment.
Abstract
From an Abstract developer:
Our internal security team has an issue with our new Webflow site. In a nutshell, after moving our site from Wordpress to Webflow our website is missing security headers, which they recommend we add:
Frame Options: Deny: add_header X-Frame-Options DENY.
Strict Transport Security: add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always
Set X-Content-Type-Options: nosniff.
Set Referrer-Policy.
Joe:
If Abstract knew about this before the project, it's possible they would have rejected Webflow as a platform. They're dev/security focused.
