HN Explorer

Launch HN: Weweb.io (YC W21) – Create websites visually using JAMstack tools

195 points by raphael-gold ↗ HN
We're Raphael, Florian and Marc, co-founders of weweb.io (https://www.weweb.io/). We are building a Webflow/WordPress style product, but where users can drag & drop their own React/Vue components and use data fetched from any API.

We started working together on a side project in 2016, it was a mobile app in rails that lets people choose music in their favourite bars. The app didn't bring much value to bar owners, but it was fun to build and we made good friends among our first customers. Aside from our jobs we loved spending time building and iterating on different web products, we even built a simple angular web-app that would let anyone create a website entirely from a mobile phone.

Fast-forward to 2018, we stumbled upon the Jamstack ecosystem and loved it. But one thing surprised us so much that we decided to quit our jobs to solve it: while many developers were switching their websites to the Jamstack, businesses were (almost) always pushing to go back to WordPress or no-code systems because Jamstack sites didn't come with a no-code interface to update the front-end.

The thing is, even with headless CMSes, most changes on a website still need to be addressed by engineers, who usually don't have the time to do it. This situation frustrates marketers, who then argue against their developers' technical choices.

That's why we built weweb.io, to allow developers to use their favorite Jamstack tools while providing a nice GUI so marketers can edit their websites in autonomy.

The main uses-cases where people find weweb.io useful are 1) when they want to ship websites fast, with a no-code tool that's not a black-box for developers, 2) when they want to create websites at scale (hundreds of landing pages) with data coming from an external back-end (API, database, Headless CMSes, Airtable, etc.) or 3) when they have a custom React/Vue front-end and want to let marketers iterate faster on it.

We currently have integrations to fetch data from Airtable, Google Sheets, Ghost CMS, Strapi and any REST API. We are planning to release more integrations in the following months.

We have a free plan where users can build a site and redirect on their own domain name for free! We start charging a recurring fee when these sites are becoming more mature (more than 500 visits / month)

To deploy a site, users hit a “publish” button and we pre-render the site, optimize the images and deploy the files on a CDN (Cloudfront). We are planning on opening the deployment system so developers can use their favorite platform (Netlify, Vercel, or anything) and choose their favorite SSR/SSG (Next, Gatsby, Nuxt, Gridsome, etc.).

We currently support uploading Vue.js components from GitHub out-of-the-box, and make the props editable in our GUI thanks to a simple config file in the component.

Furthermore, we're working on improving our support for React. On this subject, we would be interested to get your feedback on how to interpret React from a Vue app. We tinkered with libraries like https://github.com/akxcv/vuera and were hoping to not have to rewrite our whole app using React. If you people have any advice on this, we would be more than happy to hear it!

We would also love to hear your feedback about the tool. Feel free to give it a spin at https://www.weweb.io/

90 comments

[ 0.55 ms ] story [ 145 ms ] thread
0xferruccio
I've used Contentful, Strapi, Ghost, Wordpress, Webflow and Netlify CMS in the past so I think I might have a good perspective on this. I think all those tools fall short when you want to make a site with 90% standard components and then one or two interactive custom React components with some Framer motion effects.

I've played around a bit with this product and it looks like it does a good compromise between flexibility and ease of use. As I'm redesigning my company's site in the next weeks I think I'll give this a try

raphael-gold
yes, from a no-code edition perspective, it is the problem we are trying to solve. We've seen a lot of users frustrated by their regular site builders because they couldn't do this extra 10% of customization. Another frustration we've seen is that websites built with regular no-code builder live in isolation from the content ecosystem of the company (headless cms, custom back-end / database, etc.). While testing feel free to let us know if you need an integration with one of the cms mentioned above. We don't have Contentful, WP nor Netlify yet but they are on the list :)
mintone
Great work on launching! I would be interested to know who the target market is - if you’re technically competent enough to know your react from your vue how likely are you to use a visual builder? I’m speaking from a technical background, but also webflow etc haven’t clicked for me so maybe I just prefer the had way. The airtable integrations etc; I know people who would LOVE that and wish they could run their entire lives from the platform so that’s a winner. Sort of in the same way as you used to see people pushing excel to be the “everything” tool, people are now doing with airtable, so giving a nice front end of just running the site out of there is great. Well done guys!
raphael-gold
We've typically seen technical people using weweb.io when they want to collaborate on the website with non-technical people (their content creators or marketing team). Interestingly, we see teams splitting the work on the website as follows: developers build custom components and upload them from Github on the editor, then marketing people build the pages and edit the content in autonomy, so developers are involved only for highly custom front-end elements. You are right about the Airtable integration, it is the most used feature of our tool so far :D together with the custom vue.js components integration.
amitport
Even if you have a team of react developers. Faster is still faster. The cycle of design-code-feedback can be much quicker with such tools.

Your react developers can spend more time on custom components, more complex flows, etc.

raphael-gold
yes, we've seen that one of the drivers for choosing our tool is often a shorter time to market and faster iteration cycles.
Gys
Pricing depends (also) on number of visitors, for example, the free tier includes 500 visits per month.

So this is hosted by you? This is a tool/service in the space of squarespace, weebly and such?

raphael-gold
yes for the free tier we host the website. Starting from the paying tiers we enable self-hosting. Today it is still an on-demand feature but we are planning to enable self-hosting in self-service before the summer. We also plan to have one-click integrations with Netlify and Vercel (we are in discussion with them at the moment).

Yes, the tool is in the space of no-code site builders, we typically see users choosing weweb when they've outgrown their regular site builders like Webflow, Wix or Squarespace and want more customization options.

mekkkkkk
When it comes to the per-visit limits, what exactly counts as a visit? Being crawled and indexed can quickly consume hits if they are simply renderings of the page. Even the business tier seems really limited if that is the case. Especially for 100$ a month.
raphael-gold
that's a good point, we are currently discussing this with our early adopters to find the right balance. We might increase this per-visit limits. What would be a fair limit for the business plan according to you?
mekkkkkk
If you could use heuristics to discard automation such as search engine indexing and open graph lookups, then the limit is probably fine. I'm not sure I'm a fan of the pricing model in general though.

If I were you, I'd look into smart caching, traditional (high and scaling) bandwidth limits, and instead applying tier limits on updates/edits/data pulls. More user friendly, more generous for smaller projects and slightly less open for exploits. In the current model (with no heuristics), you could shut down one of your customers in 5 min just using curl.

raphael-gold
Yes that makes sense. Though, it would be hard to apply edits limits because the number of edits can vary greatly, independently from the purchasing power of a customer (for example a startup would change it's home page every other day while a large corporate would barely touch it once a quarter). The bandwidth or page views limits seem to be raising the same issue and the logic for us is simply to avoid server costs that would be too high for a single site that would pay a basic monthly subscription.
mekkkkkk
If a large company is not updating their site very often, then you do not have a great value proposition anyway. Your core product is ease of updating/editing and customization, no? Makes sense to charge based on that aspect.

Of course you need some sort of traffic restriction for things not to spiral out of control. Putting this restriction on actual MB's transferred is an acceptable safeguard. Cache bandwidth is cheap using the right strategies, so your bounds could be pretty high while keeping it profitable.

raphael-gold
cool, great feedback. We'll look into implementing bandwidth restriction instead of page view, I had the same conversation with an agency yesterday and they were leaning toward your point of view.
ath92
Looks really cool. Out of curiosity, how did you build the real-time collaborative aspect of your editor? Is it built on some existing tools, or did you build that part from scratch?
raphael-gold
The collaborative feature is built from scratch :D It works with WebSockets. At the beginning we used WebSockets to enable autosaving and undo (ctrl+z) in the no-code editor: we save all the actions happening on the elements with unique IDs. Once this was done, it was much easier to add the collaborative feature.
bwghughes-fth
I'm afraid Editor doesn't load in Safari. I get a 403 when loading the editor.
raphael-gold
whoops! yes sorry the editor only works with chromium based browsers. We will add a message to let users know!
raphael-gold
we are also planning to expand support to other browser engines as we grow :)
jack_riminton
Makes a lot of sense. I was a contract PM for a company which used Wordpress and off-shore devs to customise it and it was pretty painful. Couple of observations:

1. The Wordpress ecosystem is valuable because of the plugins. How do you envisage enabling such an ecosystem? 2. The beauty of React is with the components. An ideal end-state would be where a non-techie searches and find a React component they like (without having to go through Github) and they can add it to their WYSIWYG editor without even needing to speak to a dev

Wish you all the best

raphael-gold
Oh wow this flow would be really cool! Both observations are linked in a way: the WordPress ecosystem is really impressive and we'd love to create something similar in the Jamstack universe. To do that we are planning to open a "marketplace" where users could find components, themes & plugins. So, if we enable one-click integrations of components in a user's library, I think you are right that it'd be better not to have to link a Github account as most non-developers won't have one.

We will start working on the marketplace sometimes in Spring. We'll probably have our power users contributing first and then gradually open the marketplace to all the developers willing to build for the community.

tobr
I feel like you wrote a better pitch for it here than on the website. It’s certainly a pain I’ve ran into many times: building on tech that devs prefer leads to a situation where only devs can make certain changes, something they often don’t enjoy doing, while other team members wish they could just do it quickly themselves. Frustration all around.

It sounds like a thing that should be marketed to jamstack developers who understand how this is different from, say, Wordpress or Webflow, but that doesn’t seem to be the main audience of the communication on the site.

First impression from just watching the video is that it looks a bit complicated, and that “marketers” (or whatever title the person editing a site with this would have) might be confused if their site is not set up in just the right way to fit weweb.

raphael-gold
that's interesting, we actually have a real difficulty here because our buyers are either marketers or developers. As the problem we are trying to solve is shared between them, both are looking out for solution and we are having a hard time positioning our marketing website's communication because of this. Also, thanks for sharing your impression on the video! When you say "if their site is not set up in just the right way to fit weweb", do you mean that it feels like the editor won't allow you to build custom layouts that fit with any design? Your feedback is most welcomed!
tobr
> When you say "if their site is not set up in just the right way to fit weweb", do you mean that it feels like the editor won't allow you to build custom layouts that fit with any design?

I find it a little hard to put this succinctly, but basically as a dev I get a little nervous seeing all the features in the UI. In my experience any complex editor like that has to be designed around a bunch of assumptions about what kind of site you’re editing, and almost every slightly complex real world site will have aspects that break those assumptions. It could something subtle, like confusion around terminology (imagine being a non-technical editor for a book binding website, and seeing terminology about “bindings”), or features that look like they should do something but for whatever reason don’t have any effect on the components in use. The more complex the editor is, the more likely that certain things will cause confusion when they meet the real world.

raphael-gold
these are definitely real life example we experience every day. It is hard to draw the line between simplicity and customisability. For this our biggest inspiration is Figma. It's amazing to see non-designers drawing things in Figma without getting too many frustration together with designers doing complex and very precise designs & design systems without feeling limited.

Their interface feels easy to start with but can take you very far if you need customization and scalability.

We are far from what they achieve, but that's where we'd love the end up. :D

notahacker
Have you explored the simplest option: separate "Weweb for devs" and "We web for marketers" landing pages, videos and homepage subsections/columns/tags?

On the video: first impression is that it's heavily Weweb-built template driven like another Squarespace (especially if I stop watching in the first couple of mins before the bit about design systems) whereas I assume from the description in this thread that the design elements marketers can add and what layouts/colours etc they can choose can be fully configured by devs (and the target audience is teams that want to do this) Ultimately I assume you plan on replacing the tutorial on the home page with a video that's snappier, more benefit-focused and more selective about UI examples anyway?

raphael-gold
On the previous version of our website we actually dedicated the home page to marketers and had a link in the nav called "For Developers". The for developers page started to rank on google on some requests like "visual builder for react". We are revamping this page now and we'll add it again on the site.

Thanks for the feedback on the video, it's really useful. Makes me think that on the developer video we should probably start from a blank site and add a custom component in the editor right away.

pembrook
I think you’ve definitely identified the problem correctly. I’ve complained about this problem before on HN, since it’s the only place where people are wise enough to not get swept up in the latest hype train.

If you want to do any regular content marketing/blogging, custom landing pages for SEO, a/b test copy, or even just update the design of your site...Jamstack paired with an enterprisey headless CMS is just an absolute freaking nightmare. I like to joke that Jamstack is the fastest way to build a site that nobody ever visits.

Literally every Saas company I work with has switched their marketing site over to Webflow for this reason (especially since most Saas companies get a majority of inbound leads through content).

And they seem to be pretty happy with it! So I think you’re definitely on the right path.

I have none of the traditional armchair critiques for you. Just keep doing what you’re doing! Marketing sites should be easily controlled by marketing people.

raphael-gold
yes, that's a pattern that we saw as well! Teams migrating to webflow or wordpress to give back the autonomy to marketers. We also saw teams willing to migrate to the Jamstack from squarespace sites or webflow sites but not doing it because it would mean that marketers would lose their autonomy on the front-end. We felt these pattern should be broken and that Jamstack should be "marketer friendly" as well :)
FanaHOVA
There's a lot of tooling being built. uniform.dev and outsmartly.com for personalization, GraphCMS for content federation across data stores, etc. It's still pretty early days for the ecosystem.
raphael-gold
Absolutely, the Jamstack ecosystem is just beginning.
harrisreynolds
I've built a competing tool but I will say I love what you guys are doing with open sourcing some of your components etc. Also love seeing Vue! It is game changer for us at WeBase.

Lots of opportunity in this space... best of luck to you!

harrisreynolds
Agree. I recently refactored WeBase [1] to be 100% Jamstack compliant so it can serve as the UI site builder for platforms like Netlify.

But it is targeted at "no-coders" instead of coders given how out of balance the supply and demand is for software developers. We need more powerful tooling for professionals without coding skill to be able to build and maintain.

And while Webflow is a really nice tool it still feels too hard to use for non-developers.

[1] https://www.webase.com

raphael-gold
yay! good luck with webase, good vibes in the name too :D
koolakalaban
Very cool! It seems like this is more the way things are moving. Just out of curiosity, how did you get the big name companies on your landing page to use your product if you just now launched?
raphael-gold
we actually "privately launched" 18 months ago and we knew some people in these companies who had the problem we are trying to solve - so they were willing to try us out. They gave us tons of feedback, we improved the product thanks to that and we now felt like it was a good time to launch publicly and get more feedback from you folks :)
jerrygoyal
As far as I understood I could use both drag and drop editor as well as code. If so, how's it handling css? do you handover tailwind classes/bootstrap/just vanilla css.
raphael-gold
we handle CSS at component level, this means that you can add custom css for every element or "section" (UI block) in the site but not at site level. If you import your custom component it can have its own CSS. We don't support adding CSS at site level yet, but so far users didn't ask for it too often.
swyx
congrats on launching!

i confess i struggled to get the value proposition at first. i tend to look for as simple as possible positioning. people can get behind "no code", people can get behind Jamstack/"empowering developers", but pitching the messy middle is very tricky in my mind.

i think where i was swayed is less in the custom components part, but more the integrations with airtable/other APIs. you might have a decent shot of doing that better than wordpress and webflow can (although both are formidable already). as a marketer with some dev time i might find that very useful.

with the custom components piece, i'd lean into more of a marketplace approach so that people can reuse components made by others/pick them off the shelf, and people who maintain components might even be able to make money from the weweb users who are using them!

as for embedding React in Vue - what are the constraints to simply mounting the React component on a DOM node rendered by Vue? are you solving for SSR or something? its not clear from your description what exactly you are struggling with.

raphael-gold
Yes, back-end integrations seem to be one of the main reasons why users decide to adopt us. Being able to add their own components is also one of the big reasons. Also, being able to customize the front-end without limits also reassures developers who were mainly interested in using back-end integrations.

I really like your point of vue on the marketplace approach and tend to agree. Most users will want off the shelf elements that they can customize easily (especially marketers). We will start working on the marketplace this Spring.

As for react in vue, our problem really lies into the pre-rendering -> the main problem is that we have react in a vue.js environment which can create performance problems and conflicts between the two frameworks.

winkelvoss
This is 100% where the website building ecosystem is going. As a coder who knows just enough to be dangerous, I'm so excited about it. I know http://stackbit.com/ has been doing this for a while. What makes WeWeb guys different/better?
raphael-gold
great question! From my perspective, stackbit is made for large corporates willing to add a no-code layer above an existing Jamstack site. This provides additional customization option to marketers compared to a headless CMS only.

Our approach is different because you would build your site from scratch using weweb, which gives you much more customization possibilities on the front-end than a stackbit, but it would not be possible to add weweb "on-top" of an existing react or vue website.

winkelvoss
huh, that's totally off. Stackbit enables visual editing from a Jamstack site built from scratch too. Their visual editor seems like it's better. And you could do a site from scratch, with a theme or even just add it to your existing site. Neat product. But don't see any value add to the ecosystem in it.
raphael-gold
To start with Stackbit I believe you need to start with one of their themes and stackbit would be added on top of it. While you can start from a blank page in our tool. In their editor, the customization possibilities are limited in no-code compared to a comprehensive no-code website builder.
winkelvoss
Nope. lol Can start from a blank slate, one of their 500+ themes, a starter repo of your own or from your existing website. Stackbit's honestly pretty dope.

And they have a full online code editor in their visual editor. Nothing no-code about it.

It looks to me like you guys are just TinaCMS for Vue instead of React.

Not trying to be a dick. Just trying to share the truth.

TinaCMS import { InlineForm, InlineText } from 'react-tinacms-inline' return ( <InlineForm form={form}> <h1> <InlineText name="title" /> </h1> </InlineForm> )

weweb <wwLayout path="cards" direction="row" class="cards"> <template v-slot="{ item }"> <wwLayoutItem class="card"> <wwObject v-bind="item"> </wwLayoutItem> </template> </wwLayout>

raphael-gold
Agreed, they are building a really great product.

We are (at this stage) still very different though: with weweb, you can build full layouts with various elements and manage the CSS of every single element directly from a GUI in a no-code editor, just like in a Webflow.

In Stackbit's no-code editor, you can change the position of ready-made sections and change some of the props of these sections (text, links, etc.). You cannot however build a section from scratch 100% in no-code like you would do in a Webflow (or weweb) using grids/flexboxes, drag & dropping elements into these containers, updating all the CSS parameters visually, etc. You'd have to do it in the code in Stackbit today.

Same goes with Tina CMS. They do not offer a comprehensive no-code editor like weweb or Webflow and we are very different for that reason.

The cool thing that Tina and Stackbit manage very well (and that we don't), is the ability to add a in-line visual editor in an existing react project to change the content and some of the properties visually, but it is limited to these properties.

What we do on the contrary is offering a comprehensive no-code site builder where marketers would build 90% of a custom website and developers would add custom coded vue components in the drag & drop editor for the extra 10% that cannot be built in no-code (+ make some of the properties of these components editable from the GUI).

Hope this makes sense?

ROARosen
Congratulations! Are the finished-product sites exportable?
raphael-gold
yes they are exportable, but it is on a on-demand basis. Not so many users asked for it yet, so we didn't build this feature in self-service but it is in our backlog. We want to make sure anyone can deploy the static files on their own infrastructure, but we are just waiting for more demand to build it in self-service. You can actually go upvote for it on our public roadmap: https://weweb.canny.io/feature-requests
[deleted]
(comment deleted)
samtimalsina
I have felt the need for this before, and wanted to work on it as a side project. Congratulations on launching! I will be watching your growth.
raphael-gold
cool that you felt there should be a solution to this problem too. Let us know what you think about the tool, I'd happily share point of views on how to solve this problem.
imgermi
Great product. At first I was kinda skeptical about it. My initial reaction was "hmm ok, another one of this no code tools competing with Webflow".

The market is slowly getting crowded. Webflow has been growing like crazy. And Wordpress creators are not falling behind. Divi and Elementor are constantly improving their products, they have a huge community, and they just work.

Spoiler: Weweb hits the problem very well.

I've been lucky enough to play around with it for the past few weeks. The number one thing I looked for was not all the fancy tools for Vue js, design systems and headless integrations (even though my team needs them). It was not feeling overwhelmed whenever I'd need to use it.

That's what happens to me with tools like Wordpress. Every time I have to update a Wordpress site at scale I'm like "shit, here we go again".

They nail it at this pain point. Weweb is dead simple, and it just works.

I'm excited to give this a shot at scale, using a large design system, updating data regurarly with a tool like Airtable, and using custom components with Vue Js.

Great work Weweb folks!

raphael-gold
oh wow, thank you. You are comparing us with giants and I feel we still have a lot of work to do on the editor to catch up with them. But we are working hard to ship improvements fast! Feedback are always welcomed, that's how we improve, so, much love for our early adopters <3
fireeyed
The editor doesn't work on Safari 14 ?
raphael-gold
no unfortunately the editor supports only Chromium based browsers but we are planning to expand support to other browser engines as we grow :)
sandGorgon
I would love to see a Next SSR output here. This would be killer !
raphael-gold
I discussed this with the guys at Vercel a few weeks ago, this is definitely something we'll look into when we improve our React support. We'll also enable a one click deployment to Vercel so you can do a Next SSR + deployment on Vercel in one click. This should be possible by the end of Q3 this year.
sandGorgon
the one click is secondary. What is more important is the toolchain that bridges marketers + developers using nextjs.

It may happen you wont be able to make this too generic - like all kinds of Vuejs, gatsbyjs, etc etc etc. The toolchains will be different. I would say pick one toolchain and perfect the "developer+marketer collaboration tooling"

raphael-gold
That's a really good point. Agreed that we should perfect one solution before extending to other ones. We might start with Nuxt as weweb mainly works with vue.js at the moment. We'll let the community know on our public roadmap: https://weweb.canny.io/
domano
I've been whishing for a CMS like that, but i would prefer something selfhosted though. Headless CMSes are not customer friendly at all.
raphael-gold
I understand. When you say self-hosted you are talking about the websites generated or the full app?
domano
Well both for that matter, but this is mostly due to my customers being very careful where they host their data, germany is a bit different in that regard i guess.

Still i think that this is totally something that is missing! Maybe CMS Plugins would be nice, could really work well with strapi.

raphael-gold
Well the good news is that we already have the Strapi integration! You can try it right away if you'd like :) As for the hosting, right now people ask us directly and we send them their static files, later people will just have to click a button and configure the deployment microservice to deploy the files wherever they want. We didn't plan to enable using weweb on-premise.
domano
I totally can relate and wish you all the best - right time, right solution!
raphael-gold
appreciate, thanks and please share your feedback with us if you give the tool a try - that's the most valuable thing we can get from you folks!
stanislavb
Who would you consider your top 3 competitors?
raphael-gold
Good question. Wordpress is number 1. It is the biggest site builder that has a GUI for marketers and that's open to developers. Only, it is in PHP, so we don't directly compete with them. Webflow, Squarespace and the likes are not direct competitors, but they are site builders that we sometimes compete with for some users. Does that make sense?
alex-wallish
This is really cool, congrats on the launch! Is there any way to add authentication currently?
raphael-gold
Currently it is not available but that's the next feature on the list! We are thinking about integrating Firebase and https://supabase.io/ to start with. We are also taking a look at the possibility to manage all the users & authentication from Airtable. What would you prefer to use as an authentication service?
alex-wallish
Being able to manage users directly from Airtable is intriguing. For me I would like to be able to use it with https://clerk.dev. I wonder if this is currently possible actually since all clerk needs is to be able to wrap a react entry point? What would i actually get if i export a site from WeWeb
raphael-gold
yes, actually a good portion of the users using Airtable asked for it, but it means that we might develop a back-end dedicated to this. We are exploring it at the moment. I sent a message to Colin to discuss the Clerk integration ;)
colinclerk
Hey Raphael, Colin from Clerk here. Alex popped into our Slack and we've been looking into whether an integration is possible.

We haven't found a way to wrap the entire WeWeb application with a <ClerkProvider> component (which is a React context under the hood and informs our other components). Is that possible?

Or, in lieu of that, is there a way to hook Javascript into the rendering lifecycle of a page/component. Behind our React components is just vanilla JS, so if there were a way to control rendering based on window.Clerk.user being null, we'd be off to a good start for simple authenticated pages. (You can play with window.Clerk.user in console on https://accounts.clerk.dev to see how it works)

Would love to collaborate on an integration! You can reach me at colin@clerk.dev

raphael-gold
looks like it could be possible :) I just sent you a message so we can discuss it further!
rp36
Congrats, weweb.io definitely looks exciting.

For anyone interested, recently I had to research opensource visual page builder/websites options and these were top of the list:

https://github.com/prevwong/craft.js (React)

https://github.com/paperbits/paperbits-core (Full website, uses Firebase)

https://github.com/react-ui-builder/react-ui-builder-editor (React)

https://github.com/premieroctet/openchakra (Editor for Chakra UI)

https://github.com/BuilderIO/builder (Not sure if this really is open source)