The Making of BoardCloud
Building a World-Class Board Portal
This is the story of how BoardCloud a hyper-modern board meeting management system built on the Microsoft .Net Core Framework, began its life ten-years ago as a small custom project and grew into a competitor in the international board portal space.
Once upon a time, a ‘jock’ appeared at my desk asking for a programming job.
To those of you unfamiliar with the term ‘jock’, I tender the following image. Think of a man in his early twenties, not tall, but built of a large frame, from which swung muscled arms attached to the neck and shoulders of a rugby forward.
‘How can I help son?’ I asked.
‘I want to be a programmer,’ he replied.
‘What about a job in sales?’
‘No thanks. I want to program,’ he said.
‘Rugby players don’t make good programmers.’
Well… maybe they do! Luke turned out to be a phenom. Knowing precious little about coding, he dived in and worked as hard as Bill Gates did when he still counted his spare change.
A lifetime of experience has taught me that learning to code ‘mindfully’ takes time, above all else. And Luke put in the time. Workdays, weekends and nights. So many hours in fact, that his sweetheart called me one evening, pleading for some of her time back.
After two-years of this level of effort, Luke started to get a little cocky. He would interrupt Bruce our senior architect, with alternate suggestions. Suggestions that sometimes caused Bruce to descend into his thousand-yard stare, from which he would more and more often emerge, nodding agreement.
At about the time Luke started to become a programmer, along came a project for a big fish customer. They were such a big fish that their CFO often bragged that after month-end, they would hold a good portion of the country’s cash in their vaults. What they needed, was a dedicated system to create electronic board meeting packs to replace the clunky PDF document builder they were currently using.
Obviously, Luke wanted this project.
At this stage, he was technically proficient. He could research solutions and apply good business logic at the same time as producing competent code. He lacked experience of course, something only time at the bench could deliver.
After some nagging, I relented and appointed him as the lead developer for the new board pack builder project. We knew he was not 100% ready but we gambled on his drive and commitment to deliver a good result for the customer.
BoardPack Version 1
To be frank, the first BoardCloud version was typical of the output of a committed first-timer on a big project. The system performed exactly as client has specified but lacked any of the ’what ifs’ that an experience programmer would have coded in, from experience. There was also a fundamental infrastructure weakness where no consideration was given to setup flexibility and basics like customer name, board pack cover pages, look and feel were all hard coded. There were also some document handling limitations, the worst of which was PDF handling which was handled by a library that had severe cost implications as it scaled.
Nevertheless, over the next year or so, BoardCloud 1 grew steadily into an effective board pack maker and distributor. Luke worked relentlessly to improve the system, guided by a stream of user driven feature requests and a drive to make the best possible system.
Then along came a completely unexpected sale for a new customer, who had been sold on the system by Customer №1.
‘Can we have it by next week,’ I was asked.
‘No problem,’ I replied. ‘A few tweaks to personalise it and you’re off to the races.’
Breaking, in my eagerness, Rybko’s First Rule of IT, which says: ‘When you answer a customer’s question with “No Problem”, you can be certain it IS going to be A Problem’.
The only race we were off to was ours as we rushed to make my salesman’s promise a reality. For the next two weeks Luke and Bruce lived 16-hour days, glued to their laptops, making the ‘quick’ adjustments needed to run a copy of the system for a new tenant.
By then, it was clear that if we wanted more board portal customers we would have to rebuild. But at that stage, other more urgent projects were clamouring for precious developer hours.
The Doldrum Years
Over the next two years, we marketed the system as it was. It did a sterling job for users, building and sending PDF document-based agendas, albeit with little flexibility. Internally, each new install resulted in a forked copy of the code-base and keeping these in sync became a growing headache and time-drain.
Even worse was that by then Luke was gone, lured away by a corporate dev house that offered him all that we could not. But as luck would have it, another phenom came along.
His name was Alex. Barely out of his teens, as bouncy as a puppy before a walk, he emitted an incandescent glow of pure smarts. Alex was driven by an insatiable urge to write great code and enough confidence to be certain there was no coding task that could stop him.
‘Don’t worry Alex in ten-years you will be great. You just need patience,’ I told him, only half-jokingly.
‘I’m great now,’ he would say, confidence being another of his attributes.
Sadly, he lacked the experience to understand that he needed experience to become as good as he thought he was.
About a year later, I came in one Monday with the ‘brilliant’ idea to turn the PDF powers of our agenda manager into a general interest PDF document binder. ‘This may be our chance to build a popular general use package,’ I said, full of Monday morning wishful thinking.
We headed outside for a scrum in the driveway. Standing in a ring, Alex breakfast bowl in hand, a spoon of a vegan concoction moving from bowl to mouth in time to Bruce’s puffs on his ciggy.
As usual, Bruce was the master of caveats.
‘We need to ditch the current DotNetNuke platform. .Net Core is coming up fast, so let’s base it on that and we need m more flexible PDF library.’
Thus, was born Compozr.
Birthed by a circular process where we would decide on some functionality at our Monday meeting, that Alex would spend the week working on to be ready to hand over to me to review over the weekend. Slowly but surely driven by this iterative process, Compozr grew into a beautiful document manipulation tool. It could cut, make and trim any number of different document types into a merged PDF, with a full index, bookmarks and page thumbnails.
Then the focus turned to me.
My task was adoption, the key for any successful software. But try as I might, I could not get any meaningful traction online for Compozr. The reason, when it dawned on me, was simple, the PDF market was super-saturated with PDF tools, vanishingly few with the document handling functionality of Compozr.
The challenge was the ‘PDF’ keyword on Google searches. Add ‘PDF’ to any Google search and no matter what other search phrase you tag on, it will produce hundreds or even thousands of results. This pushed any relevant Compozr search so far down in search results, that no one ever found us.
Paid search from AdWords was the obvious source of the traffic we required.
But the popularity of ‘PDF’ based search phrases, mandated a monthly investment of $50K or more, which was not feasible for Syncrony a small South African based development house.
Compozr drifted for a few months, going nowhere, until a virus came along, which changed everything.
The Covid Years
Covid shook us.
No more cosy Monday dev meetings, wafting along with the smell of filter coffee.
And no more work.
In an instant, our custom development work dried up. Our Microsoft development team sat idle except for occasional maintenance of existing systems. We did some upskilling and some long-needed maintenance. But after a while, we ran out of make-work. So, after some reflection, I asked Alex via Zoom, much work it would be to graft our Compozr’s improved PDF functionality into the existing BoardCloud project.
‘It’s not possible,’ Bruce said.
I have learned over the years to listen when Bruce strokes his beard and makes a pronouncement. To me, his mind resembles a sequence from The Matrix, where everything explodes and all possibilities unfurl.
‘The Compozr document handling will have to be completely retooled to handle meeting agenda items, which is at least a few months of work.’
‘OK, let’s say we do that, what else would we need to sell it to multiple customers, without struggling like we do now?’
‘We need a multi-tenant framework,’ Bruce said. ‘A system that allows multiple customers to run from the same code base, while still having their data separated.’
The development of a SAAS platform to house the new BoardCloud raised the difficulty levels exponentially. It was a project that would stretch our capabilities. A project that may even be beyond our capabilities.
Yet in a flush of optimism, in a world silenced by lockdowns, shrouded in uncertainty, it was decided.
Until we had some real work, Bruce would develop a multi-tenant SAAS (software as a service) platform, which would become a home for Alex’s yet to be developed BoardCloud system.
[Read more in Part 2]