Prompted by the SharePoint Hackathon 2026

In February, my good friend and colleague Chris Grist drew my attention to the Microsoft SharePoint Hackathon 2026, as part of the month-long celebrations of SharePoint making it to its first quarter century – no mean feat for a software product.

Me, I’ve been with it every step of the way, even before it’s christening, in embryo form as Site Server and Tahoe Server. If you can remember that far back you’re probably as ancient as I am!

Knowing my penchant for showing off, Chris challenged me to come up with an entry that would bring us kudos and possibly bag us a Microsoft Surface Laptop (if it were good enough to win). I love a good challenge but there wasn’t really much time to play with, especially with juggling customers, products and ongoing projects. Still, I did have half of something on the drawing board, a product called K-Docs Publish. This was really a replacement for a now dead SharePoint Add-in solution called, Word to Wiki (W2W).

K-Docs Publish

Please read on to discover the origin story but if you just want to skip to the chase then please feel free to jump and view our video submission for the competition.

This video was built using an amazing product called Synthesia (at https://app.synthesia.io), that allowed my daughter and I create personalised avatars that read a script synched to the presentation. You have to look really close to be sure that what you are seeing is not a recording, but a synthesised product – it’s very cool but also scary!

The Origin Story

W2W fell from a project I did years back with an oil and gas company, called Santos, here in South Australia. They recognised that a great deal of their important corporate information was locked up in their numerous collection of policies, procedures, SOPs, safety instructions, best practice guides and more, collectively known as Controlled Documents.

The problem was one of accessibility. Business critical information was buried in weighty tomes held in MS Word documents, but consumer users found it difficult to access this information. There seems little point in developing an important (maybe life-saving) safety guidance documents when no one can find it or no one can be bothered to read, it because the important details are buried somewhere in a dense 300+ page document!

The mighty SharePoint search engine didn’t help much. Sure it might help users track down the relevant document, but it didn’t solve the accessibility issue – consuming users simply couldn’t be bothered to wade through the detail – it’s the classic TL;DR:

So let’s move it to wiki (a trusted managed wiki)! Convert those weighty tomes into easily consumable web pages. No need to crack open Word and wait 20 seconds for it to load, only to discover it’s the wrong document.

This was a great idea in theory, but not in practice, because content authors were comfortable in Word and were far from comfortable in SharePoint Wiki pages where (and remember this the old SharePoint Classic UX) uploading graphics, creating and styling tables and just about everything else other than laying down plain text was traumatic.

Everyone agreed that accessibility to corporate information was a critically important issue, but no-one could quite stomach the prospect of transforming that information into a more consumable format and then having to maintain that information in a wiki moving forward. What’s more auditors (who one might expect to be rather traditional in their outlook) expect to see Controlled Documents as Word (or more likely converted PDFs) and trying to convince them that it has all being wiki’ised and to get with the program, was an unrealistic expectation and one likely perceived as too risky for senior management.

The idea behind W2W was for technology could come to the rescue. The product allowed content managers to maintain their source content in Word but publish it automatically as a Wiki page – and it worked and was quite successful.

We converted the original on-prem solution to a Provider Hosted app and pushed it to the Microsoft App store and bagged a few customers, but then…

The Imperfect Storm

As good as W2W was (and it have a loyal fan base), things never stand still and a few key factors coalesced which made it clear that W2W, in its current form at least, had run its course.

The first issue was the transition to SharePoint Modern UX. Classic wikis are still supported (even now) but in a world that’s gone mobile, the classic UI just looked dated (read ugly). The problem was that Modern UX doesn’t really offer the equivalent of a Modern Wiki library – which is a shame IMHO, but I don’t get to call those shots. All we have to work with is Modern Site pages and whilst traditional, classic wiki pages were essentially containers for standard HTML, that’s not the case for Modern Site Pages and there is no such thing as an HTML viewer web part (at least not an out-of-the-box one).

The second significant nail in the coffin for W2W was the retirement of SharePoint Add-ins as a supported development method. When we build the first version of W2W for the cloud, the SharePoint Framework (SPFx) had yet to be released, and the only viable options was to build an add-in/

Add-ins came in 2 flavours, either as SharePoint Hosted App (where everything was JavaScript and ran in the context of a hidden SharePoint site – I very ugly solution if you ask me) or as a Provider Hosted App where we, as software vendors, needed to maintain an online server to service the needs of our customers. Provider Hosted Apps are far from ideal either. I’m in the solution development business and have no desire to be in the infrastructure or software as a service (SaaS) business.

This imperfect storm meant that we either needed to drop W2W and the entire concept or re-imagine it in a way that was built using SPFx and which would look beautiful in SharePoint Modern and support mobile users.

It’s a game of 2 halves

As useful as the original W2W was, it only provided half a solution. It successfully converted source documents into HTML, created a hosting wiki or publishing page, and stored the HTML inside that page. The result was a perfectly serviceable rendition of the source Word document. However, in my mind, that only provides the first part of what is needed to deliver an effective knowledge base system.

You see, the problem is that these converted documents, let’s call them articles, don’t sit in splendid isolation. They are part of a wider ecosystem of information that sits within a context – the big picture if you like. There are relationships between articles and unfortunately these relationships are not always simple peer-to-peer referencing (as you get with cross links on the Internet pages), there is often a hierarchical relationship. For example, a procedure might be related to a parent policy and as part of the process, governed by the procedure, users might want to access guidelines or form templates etc.

What’s missing for the original W2W is this hierarchical navigation piece which means that we are not really talking about a wiki at all but rather a structured knowledge base.

We’ve have already released an initial version of K-Docs Publish that can be downloaded from our web site at https://kaboodle.software/Solutions/K-Docs/K-Docs-Publish, but the viewer web part that comes with this version is just that, a simple viewer. So the solution delivers the same capability as the original W2W but without structured navigation piece.

The Hackathon was a driver

I always had this idea of finishing off this solution but, as usual, life gets in the way and so I kept pushing it out.

Chris’s challenge, and drop dead timeline of the Hackathon, was just the impetus I needed to knuckle down and prototype the complete solution as I envisaged it could be. Only…

…when I reviewed the category spec’s on the Hackathon site, it became clear (reading between the lines was easy) that what the competition was after (and so what judges would obviously give weight to) is solutions that leverage AI. Isn’t everything about AI these days!

Well, another thing on my to-do list was to figure out how to leverage AI services within the context of an SPFx solution. My thoughts were that this should not be a Copilot agent – my rationale being:

• I need to get to grips with how to call the AI APIs in the Azure Foundry
• And how to leverage them from an SPFx context
• Copilot is expensive and not every organisation has chosen to license their users, and so to create a dependency might please Microsoft, but it would for sure restrict my market.
• I also envisage scenarios where customers might want to share their knowledge bases with guests and other trusted partner organisations and in such circumstances users cannot be relied upon to be licensed for Copilot.

Don’t worry, Microsoft will still get their cut, it’s just they’ll get paid based on usage, which leads to another driver; I want customers to be able to select their preferred AI model. It turns out that calling an endpoint which leverages the gpt-4.x-nano model, for Response Augmented Generation (RAG) is orders of magnitude cheaper (and faster) than calling the gpt-5.x full model, although the compromise is for the quality of the response

The bottom line is that developing a solution that leverages the Azure Foundry AI APIs, directly opens doors, whereas developing a solution that is dependant on Copilot firmly closes them.

Will I win?

I doubt it ☹. There are 126 entries for this year’s competition, and although they vary wildly in their utility and quality, there are enough really great ones in the mix that I will probably get edged out. I guess we’ll find out next week – although due to time zone differences the announcement and awards ceremony is 3 a.m. Adelaide time, so I’m not convinced that I will muster the motivation to watch in real time.

Release Date?

If you watch the video, it should be obvious that to get this far (in a 6 week timeframe) took considerable effort and as such the upgrade of the viewer side is not quite ready for primetime.

However, we are pushing this forward with this, and if all goes well we hope to have a version in the Marketplace by the end of May. As with all Kaboodle products there will be freemium version, with advanced features unlocked if you opt for a license paid version, which will still be decidedly affordable as costs are tiered based on the number of licensed users you have.

If you want to help us out by being a beta tester, that would be very much appreciated. Contact me and I’ll sign you up for the program, which we hope to start next month.

Sharing is Caring

Whilst developing an SPFx solution which calls Azure Function Apps (in a secure way) and which then marshals calls to AI models defined in Azure Foundry was, shall we say enlightening, but I learned a great deal.

In the community spirit, I plan to share my discoveries and learnings over the next few blog posts, so please stay tuned and if anyone has any specific questions as to how we built K-Docs Publish, please get in touch or leave a message in the comments section and I will do my best to follow up.