When a business wants their website to accommodate scheduling, a recruiting application, event management, or some other special feature, there are basic questions to ask. 1) Does it really need to be part of your website, or can your website just lead people there? 2) How much are you willing to be involved in the ongoing support for that functionality (if people can mess it up, they will)? and 3) How much capital do you have for custom software development AND maintenance? If the answers are Maybe, Not Much, and Not Much (and even regardless of the answers), you’re probably forgetting the cloud.
What Kinds of Functionalities Might You Keep in the Cloud?
It could be any major functionality, beyond the website as marketing presentation. However, here are some examples:
- mortgage/financial application and tracking
- class/event management and signup
- job application/posting
- sports league tracking, ranking, scoring
- e-commerce product ordering and fulfillment
- podcast/media hosting
- discussion forum and social networking
- appointment scheduling and booking
There are two overall methods for getting any of these going with/on your web site:
METHOD 1: Native system built into the website:
- Cost: Building in a native functionality drives cost up by order of magnitude (e.g. 1000%). When you look at the initial cost of a website, that’s the cost for the website as marketing presentation. Functionalities are either extra or drive up initial cost.
- Sustainability: is low, because the core website is now an app, not a presentation, it will need frequent maintenance, ongoing contract, etc. Additionally, you’ll need to budget cost for updates to keep up with frequent browser/website platform upgrades so the system doesn’t break.
- Security: There will be a continual need for vigilance and stopgap fixes. Mixing a user database with the website database encourages hacking, which is highly prevalent now user data is available. You have a prize – information on other people – and it *will* be targeted, if it’s in your website.
- Legal: Mixing a user database with the website database causes significant compliance regulations to kick in, and opens you to expensive challenges, when there’s a data breach, or you’ve incorrectly communicated how data is being used. This is especially true where any financial transaction is occurring; new rules since the banks’ devastation of the US economy in 2007 make this a real concern.
- Stability: Mixing a user database with a website database leads to bloat, often a slower website, and potentially increases website stability issues over time. The fundamental issue is not separating presentation from data acquisition. A site can be built with separate databases for each functionality, but then the other issues still apply.
- Support: The needs may be excessive. While cloud-based 3rd party systems have their own support, often ’round the clock, you are now the support layer for your own system, and either have to hire staff for that, or be available to do it yourself. Alternately, you can be less than responsive when people have issues. Not budgeting for support on a mission critical system would be foolhardy.
- Cost: is usually vastly lower. You’ll pay a nominal monthly fee to the 3rd party cloud-based system provider, and you have to search for one that you like, get some free trials, and decide on a system, but ultimately that’s not adding much cost to your website build.
- Sustainability: is highest, since the 3rd party cloud app provider, not you are handling all the password resets, keeping the servers running under a load, fixing the system when browser versions come out, and doing all the technical things to keep it smooth. You’ve offloaded those problems to their team.
- Security: You’ve offloaded most of the data security problem to them. It’s their job to monitor and resist hacking attempts, which happen all the time, and to protect the applicant data, which is highly prized and sought after. It may not remove 100% of liability for a breach, but it can drastically reduce your exposure, and certainly your embarrassment. You can always switch vendors.
- Legal: Compliance is usually built-in, with proper disclosures, data security protocols, etc – all of which must be accurate, legally vetted, and kept up to date as regulations change (which happens frequently). Do you really have time to even do all of the required audits for compliance? Your handling people’s data here, so you’re just as responsible as say Facebook or a Capitol One for the legal end of protecting customer data. Size isn’t a pass.
- Stability: Your applicant database isn’t even on the same server as your website, meaning your website can be zippy and unimpeded by the bloat or any data management issues. If your app were to go down, your website could stay up, and you could issue an announcement or switch to a backup vendor.
- Support: Whew! Now all you need to do is have a basic level of support for a presentation website, and the 3rd party cloud-app provider takes care of the hefty support related to the functionality you’re getting. They’ll do this either by supporting your customers directly (when there are interface issues) or supporting you directly (when there are overall functionality issues). No need to call in the original developers who custom built your system to try and fix it, making your support costs unpredictable. Your monthly fee covers your support with a 3rd party cloud-based system.
What If You Still Want Native Functionality?
Method 2 is a leaner project, but if you still want Method 1, you’ll need some help. Unless you’ve personally managed a development project yourself, don’t go it alone. One way MadPipe helps clients is vetting and communicating the requirements in a way a web developer understands, and vetting communications with the developer, interpreting back to you the client, and calling out anything vague or any concerns. That’s project management on a website build, and we do it all the time. We can even refer the web site build to a company we like that is capable of delivering.
So, if you do Method 2, don’t go straight to the developers; it may sound like you’re speaking the same language, but different words mean different things to a business owner vs. a tech person. Start with the project management side of it. Contact MadPipe to get the ball rolling.