DoBu.uk

I just implemented time zones, I removed the multi-month view which nobody wants and improved the single month view. Removing stuff had a big improvement looking at it from the inside.

I rewrote the calendar code, made it simpler, faster and increased test coverage.

Ideally I would remove a lot more stuff and clean up the code base. However I have set a deadline to put the project into maintenance mode. So we shall see how much of this gets done.

Presently I have one user who is happy. I'm confident that there are more out there, the problem is that it is all taking too long.

This is because I took the classic engineer path of pushing the boat out as far as I could on the technical side. I wrote a lot of stuff from scratch, which has a lot of benefits, but high risks.

On the plus side the project has few dependencies or costs. So it can be parked while I survey the landscape and think about what I have done. I won't want to stop SEO altogether; it's something which takes time anyway. So stoking it occasionally and leaving it on a slow burn seems like a plausible idea.

If I were to start the project again I would probably try a "barbell" strategy of writing the core calendar components from scratch and use a lowcode tool like budibase for everything else.

Something I'd like to do now is allow the whole thing to be configured through a Google workspace plugin. Assuming that is viable. Which has the added benefit of being available in the marketplace.

Developing the core of the application from scratch is not a huge amount of work, maximises freedom and performance. The core of the product is where your edge is (if you are a technical obsessive), so it makes sense to perfect that.

However all of the CRUD around it, that users rarely ever interact with, just needs to work on some basic level to enable the core to shine.

Oddly a lowcode/nocode service and a low/no dependency app have the same property of being low maintenance. At least I'd consider it a bug if a nocode created app required major maintenance on a regular basis.

Most products don't have documentation which presents the necessary settings widgets inline. Nor do they show extended validation for the settings in the context of the current document.

I have started implementing this for the following page:
https://dobu.uk/how-to/link/forms

You can select a user profile (or not), enter a link URL and save it for the selected user. Also it does some limited validation.

It's easy to see why most software does not have this just from the difficulty of implementing it. Essentially it makes the docs a programming and UI challenge like any other part of the application.

Meanwhile I am convinced it is worth it, at least to some extent. Just now I started using logtail which was essentially a case of copy and paste because they inserted my keys into their code examples which were in the main UI.

Most likely Pareto applies here and one quickly runs into diminishing returns.

I added the ability to populate an external form field in a bout 5 minutes. It lets the customer inject the selected date into another forms product. For example you can populate the date hidden field in Typeforms with a url template like "https://xxx.typeform.com/to/xxx#date={year}-{month}-{day}"

String substitution is really easy to implement for a programmer. However it's horrible for a user to figure out how to construct the URL. The best way to deal with this would be to integrate properly with the forms product.

Never mind that for now though. There are trillions of forms products. The best I can do right now is document it and maybe use to heuristics to validate the URL.

The best documentation I have seen uses live data for the logged in user. If no one is logged in then it just shows an example or a login link.

Requiring the user to login to see the docs would not be smart. Apart from damaging SEO I often use mobile devices to look at docs where I am not logged in.

Making the documentation interactive is some work. However I quickly realised, while trying to figure out how a bunch of forms products worked, how much better it is if the docs are directly connected to the app.

I have replaced the boxes of text with bullet point lists. These tried to make a bunch of points that belong in long form articles if anywhere.

For many products I ignore the landing page and go to the pricing table. Usually this includes a list of features which actually says what the product is.

It's funny but a lot of the time I can't tell what a, apparently successful, product does at all. The landing page states its benefits, which are often nebulous, but I don't believe them.

It's only when the ends can be connected with the means that I begin to believe.

Having said that my landing page is probably still not selling the benefits enough. Or the means for that matter.

Let me know what you think: https://dobu.uk/

Trying to host a distributed HA KeyDB cluster as a Fly app does feel a bit like putting a round peg in a square hole. However it is working.

I have a master-to-master replication setup across regions. Most operations are done on the nearest instance. A handful are done on a central instance so that they are atomic.

This means most reads and writes are quick and that I don't need Upstash anymore.

More importantly the calendar and enquiry forms work and are quick in the regions where I have a server. I still need to implement timezone selection to get users outside of the UK, but it helps to actually show them what it will look like.

It takes between 4 and 40ms to serve the availability calendar page on Fly's smallest VM. This includes fetching the data from the DB.

This is a (draft at time of posting) article I have written for SEO and because people ask Christine how she setup her website.

"How Christine Palethorpe, wedding harpist, takes bookings and runs her website."

Overview:
Customer acquisition with Wordpress and social media
Displaying her availability with DoBu.uk and Google calendar
Taking enquiries with DoBu.uk
Tailoring her packages to each customer
Finalising the contract with Gravity forms and Zapier
Invoicing

https://dobu.uk/case/christine

Every so often I realise a word doesn't exist in international English. Apparently "enquiry" is one of them. Americans always use inquiry. To me inquiry is pronounced differently and means something serious is afoot. Possibly involving parliamentary committees and lords. Perhaps ending in serious jail time for someone.

Enquiry on the other hand, is the type of thing you do to find out if someone can take photos at your wedding. Hence why it's embedded throughout my website.

Meanwhile it has become increasingly clear that my MVP is not an MVP. It in fact contains an enquiry form which is unnecessary. It could integrate with any forms package by populating a hidden field.

Logically there is a case for me to include a limited form for clients who have no appetite for configuring Gravity forms, typeform, simpleforms, superduperforms, ...etc. However there is so much lower hanging fruit.

I am already stepping into a densely saturated market with creating an availability calendar. Then stepping into two by including a form.

I think I have always known this, but was in denial about the extra complication having a form would bring. Any extra feature has cascading effects into every aspect of development and marketing.

So why did I do it? I think because my flagship user said they just want a form that works better than the Google form they were using at the time. I went ahead and provided that in the initial release.

I came up with a way to avoid CAPTCHA and making users type their e-mail in twice. This get's my ego's juices flowing, but at the same time, these are viable products in themselves.

There is a huge difference between implementing a feature and creating value.

So do I just kill the form off? There are some complications, my sister currently uses it, but may switch to Gravity forms. I also have some users in the trial period, but no one paying for it.