In today’s data and information economy it is inevitable that you will, at some point, face the dilemma of choosing between an out-of-the-box software solution or attempting to build the “perfect” platform that meets your exact needs.
The argument for the build-your-own solution usually goes something like this: “Our program and requirements are unique and we need something that meets 100 percent of our needs and gives us 100 percent control over how it looks, feels, and works.”
We can relate. okapi was hatched when an agency with 30+ years in the experiential marketing space had an internal conversation that went very much that way.
Unlike a lot of similar conversations we’ve heard of, this conversation (eventually) became an (almost) perfect platform for managing all aspects of an event program. But we learned some hard truths along the way.
First off, if you aren’t a software development company you’ll either need to become one, or hire one. And after twenty years in this business I can tell you neither of those are easy or inexpensive. Because developing the perfect solution, or even a minimally viable solution, is a full time gig for a whole team of people. We ended up creating a software development division, and then spun that off into what has become okapi.
Next, you’ll have to make decisions. A lot of decisions. Some of them will be critical, some of them will be deceptively easy, and all of them will impact the end product. It won’t just be decisions about functionality or esthetics either. There will be tough decisions about infrastructure, and architecture and security. You’ll have to decide things like your tolerance for downtime, backup and disaster recovery procedures, and the length of time one of your end users should wait to have their support request resolved.
And even when it’s done, and trust me on this one, it’s inevitable that you will have overlooked some really important functionality and have to build that in. Then your customers and users will want a few new features and each one of those will have to be built.
Each one of those new features essentially has to go through what’s commonly referred in the app development world as as the software development lifecycle. Imagine each feature you need passing through the stages of: initiate, requirements, design, develop, test, document, deploy, support/maintain and evolve. One feature * nine stages * every feature that you want in your project…you do the math.
Then if you’d also like a mobile app add another huge chunk of cash. This article says that it could take between three and six months to build a mobile app similar to Instagram and cost between $100,000 – $300,000 dollars. P.S. That’s JUST the mobile app…not the web app and all the infrastructure that makes it all happen.
Ah finally! It’s done. You’re so happy you’ve rolled out version one of your new toy. Now it’s time to move into maintenance mode. In this stage you’ll need to upgrade, update, fix issues and continue to host the solution once it’s built. That isn’t cheap either. In fact, this admittedly academic but highly relevant article detailing some “Fundamental Facts about Software Engineering” says that “maintenance is more difficult than development,” and estimates that maintenance consumes between 40 to 80 percent of software costs. And that’s FOREVER…ouch!
Then of course there’s all the project management and administration required to take your software solution from initial plan to performance ready. Someone has to manage the engineers, write the documentation, and furnish written policies and legal documents that comply with ISO, PCI and GDRP standards.
But let’s back up and talk about what it costs to even build the kind of functionality you’re dreaming of. Have you ever wondered what you’d have to spend to build a software platform these days? There are some cost calculators built into this article about building mobile apps, including some guestimates about what you’d spend to replicate popular apps like Spotify and Facebook. But honestly, the initial costs are dwarfed by the ongoing costs to host, maintain, and keep your software current, the distraction from your primary income-producing activities, the energy and stress invested, and the wait time before you have a viable product to use.
For most companies, unless your strategy includes owning the IP or reselling the platform as an income stream (and okapi does offer a multi-site, brandable solution that provides that functionality as well) it’s hard to justify investing in a built-from-scratch solution.
So does that leave you with having to either put up with the shortcomings of most out-of-the-box solutions or trying to persuade the software vendor to make modifications just for you?
First, before you get excited because someone is willing to customize an out-of-the-box solution for you be sure you ask what the downstream effects are of your proposed changes. If their software wasn’t designed to accommodate the modifications you’re requesting it’s likely that there will be future updates and releases with features and functions you won’t be able to enjoy because your newly customized site isn’t compatible with the new features everyone else gets access to for free. It’s also possible, depending on how well those customizations were documented, that the time will come when support will be problematic because there is no one still working for that vendor who knows exactly how your changes affected everything else in the software.
But we don’t believe that should leave you stuck with someone else’s idea of the perfect solution. Nope. Not even ours.
We look at configuration and customization as a continuum. From out-of-the-box, no customization at one end of the scale and the from-scratch, totally custom build at the other. The ideal balance for most companies is to choose a solution that is about 80 percent baked that allows you to put some resources into customizing the last 20 perfect to fit your needs. All the while ensuring you still have access to every new feature that gets developed in the future.
Which is why one of the big decisions we made in the architecture of okapi was to make it highly configurable without resorting to totally customized. If our solution is 100 percent perfect for you the way we designed it we’ll all do a happy dance together. But if it isn’t, our customer success and engineering teams will work with you to spec out the customizations required and give you the peace of mind of knowing that those modifications will be compatible with future releases and will be supported seamlessly by our team.
My path to the world of event program management started over over twenty years ago. That’s a story for another article, but for the past two decades I’ve counseled and consulted with hundreds of companies to build all sorts of technology, marketing, and sales solutions. In all that time I can’t even count the number of companies that have approached me with something like, “We just spent $250,000 working with an overseas developer and have nothing to show for it.” Or, “We hired a developer to build our product. He just quit and we have no idea where our code is or how to access our servers.” I’ve heard the same frustrating stories so many times that I wrote a book to give entrepreneurs some frame of reference for what to expect before they start on this journey.
So if you’re considering building a piece of software and would like to have a really frank discussion about the costs involved let me know. I’m happy to get on the phone and tell you straight-up how much we’ve invested in the development of okapi. Or, if you’re considering using duct tape and bailing wire to glue together five or six free systems to meet your needs take a look at this post I wrote. Spend just a couple of hours reading those two pieces and thinking it over. . Then, If you’re still up for building a product, shoot me an email and I’ll happily spend an hour on the phone pointing you in the right direction. Either way, the okapi herd will be here to help you regardless of the path you choose to follow.