We're finally ready to show the world our beta of everypage 🎉. Before we do though, I thought it'd be good to document our journey to MVP so there's something to judge the results of our beta "launch" against.
An idea is born
Over the lockdown, my wife and I (together we are Kiba Labs 🦍) decided to build a side-project together. Before the lockdown we had planned to work on Kiwi, a product to help engineering managers encourage better documentation throughout their team. It was a classic case of scratching your own itch as this is a problem I've thought about a lot in my day job. The first thing I did was buy a landing page template and throw it up as a GitHub page. We intended for Krupali to own the product-related aspects of Kiwi and this started with the landing page content. We hit a wall immediately though, as she hadn't had experience with html, css or js. I couldn't believe I hadn't questioned it before, but why was it necessary to know html, js or css to edit a simple landing page template in this day and age. The more I looked at it, the more I was upset that the copy of the landing page was so deeply coupled with the structure and styling of it 🤮. I would never do this with anything I built myself, why is it happening here?! And so everypage was born...
My first instinct was to build this with simple templating - something like jinja2 - but as I thought about this more and more I realised just how annoying a problem this was. At work we had external consultants who handled our landing page because we felt it wasn't a good use of our software engineers valuable time. This was mostly because landing pages often require many, many iterations - change the text, change the colour, change the layout so this section is first, oh change the colours again - it could drive anyone crazy!
In contrast, for the product we actually sell at work, we had designed an awesome component library that allowed us to change themes and structures without having to worry about the underlying CSS freaking out every time we moved a button. This was my inspiration - surely landing pages are a subset of this problem. Our hypothesis is that there are thousands of developers out there who want a landing page for their product but don't want to become entangled in the web that is modern css and javascript, let alone the difficulties of supporting various browsers - backend developers everywhere: it's not fun 🤯!
Whilst I was thinking about the technical intricacies, Krupali went and checked out how non-developers build landing pages. All the usual suspects came up; Wix, carrd, landen, webflow and even a few I hadn't heard of before but looked great (like unicorn platform). But as a developer I couldn't bring myself to using tools like this - I like version control too much. On top of that these platforms are all closed and own your page - even if you exported the page you would be left with html, css and js, you can't just import this into another platform. When she described this to me I knew what we needed - a new specification for the building of landing pages!
Designing the MVP
The solution as we saw it was to have a system that allowed you to declare "sections" for your page (i.e. the layout) as json. The content of the page and the theming of the page would be json too. This meant that everything is committable to version control, editable anywhere json is and would reduce the problem of learning how to build a landing page to learning what the various sections are and how they could be used. It's intended from the start that this be an open specification i.e. we simply declare the "schema" for a header-signup component as something like:
{
"type": "hero-signup-1",
"titleText": "string",
"logoImageUrl": "url",
"subtitleText": "string",
"formAction": "urlMethod",
"formTarget": "url",
"inputName": "string",
"inputType": "inputType",
"inputButtonText": "string",
"formAdditionalInputs": [{
"name": "string",
"type": "inputType",
"value": "string"
}],
"inputPlaceholderText": "string",
"inputSuccessMessageText": "string"
}
and then implementation is left up to the library used. Obviously everypage would be the first (and possibly only, but we're hoping not 🤞) library to implement this specification. The theming would be achieved by having a UI components library that could be used by all projects that implement the schema specification (but of course anyone can implement their own UI library too).
This would mean landing pages in everypage are "transferable" to any provider you want or could easily be moved in house without the person in charge of spec-ing the structure and content having to care. Perfect 👏!
An example would be something like this:
{
"type": "hero-signup-1",
"inputName": "email",
"inputType": "email",
"titleText": "Create your beautiful landing page in minutes with a declarative API",
"formAction": "POST",
"formTarget": "<api url>",
"logoImageUrl": "/assets/everypage-wordmark.svg",
"subtitleText": "Our easy to use landing page generator builds your landing pages with perfect performance, SEO and accessibility built in.",
"inputButtonText": "Subscribe",
"formAdditionalInputs": [],
"inputPlaceholderText": "Go on, you really will love it 👀",
"inputSuccessMessageText": "You're signed up 🎉"
},
to create this section:
The plan for the initial MVP was to create all the sites we have under Kiba Labs in everypage and then release it so at least websites similar to those could be created. I've worked on a lot of side projects e.g. Word Magic, Kites and Scopie all with their own landing pages so this would definitely be a challenge, but overall it sounds pretty simple so far!
Getting some validation
Pretty much anyone you ask now will say you need to have some validation before you start building anything. As a developer this is hard to swallow and harder still to follow but as a seasoned maker it's obvious - don't just build stuff unless you are doing it for fun.
My first point of call was a few colleagues who are backend developers - in my mind this project would be perfect for them. Of course, they all nodded and agreed in earnest as I described the problem and how I plan to tackle it. Looking back though I definitely didn't do this right - of course they were going to agree, they don't actually have anything to loose 🤷♀️.
Krupali spoke to a different set of people and the one with the most useful feedback was the organiser of Weekend Club, a regular work group we attend. He had used many landing page builders so far and in general he found them relatively easy to use but found they didn't really offer much by way of guidance to what should be done (rather than what could be done - they all show off their awesome features!). This was great advice as it articulated what I couldn't - designing a landing page involves so many skills including design, copy and coding - having it all in the control of an engineer is so constraining. It's hard to create guidance that doesn't sound generic like "Don't make your sentences too long" because the tools people use to create their pages are all over the place and in the end have to be funneled through an engineer. In everypage we will try to remedy this - make the sections follow specific guidance by default - don't let people do bad things where possible and call out bad things where identifiable.
On top of this we also tried out a bunch of landing page builders. I gave up pretty fast because I generally dislike drag and drop builders that try to simplify complex interactions. Krupali kept going on and manage to build a site in a few of them. We did feel a bit overwhelmed here at the number of features these builders had when considering them our competition. The only way to get over this thinking was something I heard in a podcast - the competition isn't other tools, its people wasting time on doing it themselves. I had never considered using a drag and drop builder so why was I considering it a "competitor" now?
Once we looked up from all the "research" we felt super motivated to get started. Admittedly, we could have validated a lot more (so could everyone though, right?) but there was also the factor that I was itching to build something fun! So we started coding / designing our MVP..
Scoping out an MVP
I think designing an MVP of a new project is one of the hardest things for product people to do. Realistically, any mis-step can lead to the project failing. So we decided to really think about our framework for choosing "features" before we started to list them. The approach we decided on was fairly simple but seems super effective: We made a big list of features, ordered them by priority and draw an arbitrary line somewhere near the top that said "MVP".
The big idea though, was the this line was allowed to move as much as we want. As the only people involved (and the only people that would benefit) we fully understood the pros and cons of moving something above or below the line. As we developed over the next month and a half this allowed us to iterate on the idea as a whole rather than being to focused on specific features.
An example of this was initially we hadn't even thought about hosting but we quickly realised it was the only real way to get paid since nobody would pay for a open-source library directly. Having a hosting platform would also allow us to iterate on the product in a very visual way that Krupali could use too rather than just having a library for me to use. So another month of work was added to the MVP, but we knew this was for our overall good so we easily agreed on it and moved on.
Another example is custom domains - initially it was firmly on the "Not MVP" side of the list. As we got closer to launch, however, we both felt it tugging at us, wanting to be included. Once we both got to the point where we felt it must be included, we added it to the list and it felt great!
A final example - the dashboard has lots of areas ripe for improvement and a great example of this is the canvas. There are so many ways to make it more intuitive to use like having pre-made json objects for insertion and offering some overview of the schema so errors aren't just shown with now explanation. But these changes involve a lot of work, and whilst we agreed they had to be included at some point we decided it would be easier to have users contact us for support rather than implement these changes and release a month later.
After about 2 months of evenings and weekends, we finally agreed on what should go in the MVP and had built it 😋
In the end, we managed to build a lot more than we expected. It's far from finished but we're hosting our own sites (not all, but a few) on everypage and so far its worked a charm. It's a lovely feeling when you are positively surprised by how well your own product works - a feeling we always feel when we look at how fast sites update considering they are configured to sit at edge caches all over the world!
There's a quote people often say "If you aren't embarrassed by your first version, you launched too later". This seems a bit stupid to me - it's easy to look back at anything and be embarrassed because as you grow you learn more (and if you don't then you should be embarrassed that you haven't). Who would release something to the world with a real "oomph" if they weren't proud of it? Surely that launch is doomed to fail regardless of how good or bad the product is because the creators themselves don't believe in it? Saying that, I'm super sure we will look back at the screenshots of everypage now and be shocked at how basic it was, but at the moment we are very proud of what we have created and can't wait to show it to everyone!
So now we are ready to accept beta users to everypage. Our next post will be on how the beta period goes and what we learn from it. I expect there will be lots of think about in terms of how we chose features for the MVP, but we can't learn much more without launching! It definitely feels weird to be showing our baby to the world after holding it so close to our chest during development.
So go check it out at https://www.everypagehq.com 👀, the free tier is more than capable for any experiments you'd like to run and there is no credit card needed to get started!