BIGKit

This time we are trying a few different channels. On top of this, I have also attempted to engage with the /r/graphql community to see if there was any interest in graphql as a service, as this is definitely something we could pivot on. So far the sentiment is pretty dismissive.

As of today, I put out the first part of our product reveal. We posted it on /r/react /r/reactjs /r/dotnet /r/cms /r/fsharp, and also on HackerNews/linkedin/twitter. Reddit was somewhat unforgivable in terms of downvotes and negativity, although some communities were definitely better than others. Despite this, about 1/3 of our traffic for the article came through from reddit, so this is probably one to get right.

Generally beyond this reception has been positive for those who dug a bit deeper and actually read the article

The article itself has so far received 350 hits, and our site page views are up to about 30 so, although numbers are very small still, this is a huge increase from 3-4 a day.

I think this definitely highlights the issue that we are still trying to nail down exactly who the customer is, and realistically developers are not ever going to be our main customer, they simply have to 'tolerate' the product. We have always imagined that there is a BA class or something akin to a power user, who is technical enough to get their hands dirty.

I am dreading the next publish, the plan is to drop it next week.

Alongside our core product, we have also been working with Headroom to build a tailored application for their business. Getting the last details in place is, as always, a painfully slow process that always takes longer than you think!

In order to be able to deliver this, we have had to build whole swathes of features into our product around SSR and SEO, and deployment. Although this has in some ways been a massive distraction, these are now largely solved problems which simply increases the value of the product.

We have definitely had way too much feature-creep, and I am not entirely sure what we should have done differently other than get out and test with customers early. The problem with a product this ambitious is that you kind of need most of the moving parts working in order for it to deliver any value to anyone, or even take it seriously. I still feel like we are hundreds of miles off this, even though we have a huge list under our belt already.

After much work, deliberation, dogfooding, we are finally at a point where the product delivers on many of the promises we originally set out to achieve. You can now build real things! The UX needs a lot of work still, but it feels like every feature now is a bonus.

We deliberately took the choice early on to build our own sites with our tool, forcing us to ensure there were no details we could fluff over. This made everything an order of magnitude harder but was probably worth it in the end, as our product is better as a result.

Working with Angular X and a bunch of dotnet api's throughout 2018 and 2019 for Bud, although standard practice in the industry, made me question the very foundations of web development. A lot of what we were building was simply repeating the same things over and over in subtly different ways, every time massively complicated by the fact that everything was code.

Every pixel-push operation requires a developer who needs to know git, css, angular, is familiar with the PR process, and 30 other things. There was some justification for code, but it felt like 90% of it should be able to be constructed and maintained in some higher-level tool.

Understanding this problem from an insiders point of view, I felt I had a unique perspective as to what a potential solution may look like, and require.