Homechart için bir WebDAV/CalDAV istemcisi ve sunucusu geliştirmeye başlayan ekip, başlangıçta bu sürecin kolay olacağını varsaydı. Ancak, mevcut Go kütüphanesi go-webdav'ın eksik özellikleri ve veri modellerine uymaması nedeniyle kendi çözümlerini geliştirmeye karar verdiler. Bu süreçte, WebDAV'ın karmaşık ve eski RFC'leriyle (Request for Comments) yüzleştiler. Başlangıçta tüm RFC'leri uygulamaya çalışsalar da, gereksiz eski kalıntılar ve spesifikasyonun genişliği nedeniyle bu yaklaşımdan vazgeçmek zorunda kaldılar.
Bunun yerine, ekip mevcut istemci ve sunucuları (Apple Calendar, DavX, Thunderbird, Apple iCloud, Google Calendar, Radicale gibi) tersine mühendislik yaparak incelemeye yöneldi. HTTP proxy'leri ve Wireshark kullanarak istek ve yanıtları analiz ettiler. Bu yöntem, RFC'leri baştan sona okumaktan çok daha hızlı ve etkili oldu, çünkü WebDAV'ın sadece HTTP gövdesini değil, başlıklarını da incelemek gerekiyordu. Bu süreç, ihtiyaç duydukları API'yi ve desteklemeleri gereken istek/yanıt türlerini hızla belirlemelerini sağladı.
Go'da XML ile çalışmanın zorluklarına da değinen makale, standart Go XML kütüphanesinin yetersizliğini ve bu nedenle HTML düğümlerini yönetmeye benzer bir yaklaşımla kendi xmel kütüphanelerini geliştirdiklerini belirtiyor. WebDAV'ın "yapılandırılmamış" şeması göz önüne alındığında, bu kütüphane, karmaşık XML verilerini kolayca işlemek için kritik bir rol oynadı. Sonuç olarak, ekip MVP'lerini oluşturup mevcut uygulamalarla test ettiğinde, standartların çoğu zaman sadece birer öneri olduğunu fark etti. Özellikle Apple ve Google gibi büyük oyuncuların RFC'lerin sadece bir kısmını uygulayarak aslında birer MVP sunduğunu ve neyi destekleyip neyi desteklemediklerini tam olarak belgelememeleri, WebDAV geliştirmenin gerçek zorluklarını ortaya koydu.
WebDAV gibi eski ve karmaşık protokolleri uygularken, standartlara sıkı sıkıya bağlı kalmak yerine pratik tersine mühendislik ve esnek araçlar geliştirmenin daha verimli olabileceğini gösteriyor.