A Guide to Quickly Developing and Deploying Web Applications

p>So you need to build something quickly, efficiently, and deploy with reliability and scalability. What do you do? More on that in a minute…

One of the interesting side effects of the global crisis we are all going through is the reliance we all have now, more than ever, on digital applications to conduct our regular affairs. Over the past few weeks, we’ve worked with numerous clients to develop new offerings, business models, and digital capabilities to either offset losses in other areas of business or augment services already available. This work is exhausting and requires quick planning, building, and iteration.

On great example that is in the news today is the Payroll Protection Program (“PPP”), which was part of last week’s government stimulus bill. The PPP is a loan program for small businesses that will cover their payroll, rent, and utility payments for the next 8 weeks. The program opened today, April 3rd, and thus far, the rollout has been, well… interesting – to say the least.

Watching this unfold as a consumer made me think about how the rules have changed for the implementation of software solutions. Somewhat for the bad, but mostly for good. In this post, I want to review a few thoughts and some tips for how your business can too build and iterate web applications quickly to respond to this, or future crises (or, opportunities).

Monolithic Organizations are in Trouble

As of today, the first day of the program, some of the major banks are unable to accept PPP applications. JP Morgan Chase last night told all of its customers that they would not be ready today. Wells Fargo just said to their customers, on the day of program initiation, that they are not prepared. Bank of America seems to have some sort of digital application online, but it’s highly limited to existing customers and those who already have a credit relationship. Meanwhile, numerous small banks and start-ups have put together application systems quickly and efficiently.

The old adage is that “giants move slowly.” Well, in this atmosphere, that’s truer than ever before. The fact is, large organizations are stuck when it comes to quickly adapt to change. The teams are too big, the processes are too slow, the checks and balances are too many. It’s simply impossible to respond quickly to initiatives when your ecosystem is so convoluted. Now, look, I want to be precise in my words – I am sure there are many talented folks at all of these banks working tirelessly to make this happen for their customers. But the bottom line is that the PPP isn’t a complex application to build. In fact, the bank I applied with this morning put it all together with DocuSign. They are taking applications right now using third-party software. There are ways to do this.

The problem at large-scale enterprises is that you can’t shoot from the hip. This is because ten different folks need to approve each step in taking the shot, and even then, you are afraid to pull the trigger because your job is on the line if you miss. This behavior is something that I believe makes certain companies economically unable to compete in particular areas. The fear of loss is muddying the vision of possibilities for way too many organizations. This crisis merely is exposing these issues to the masses for the first time.

Plan Quickly

The only way to implement quickly is to plan rapidly. Usually, we recommend a thorough discovery process to plan and identify all areas of opportunity and risk in a project. However, for a project that needs to be built quickly, you need to plan immediately. As I’ll speak about in the next section, agile is the only methodology you can use. So rather than build a waterfall-based development specification, it makes more sense to develop a bullet list of desired functionality, such that you can immediately prototype user flow.

By doing this, you can focus on iterating the prototype and not a document, which results in a more tangible series of improvements and also focuses on the specific end-product. It shouldn’t take you long to formulate a list of what an application should do. Let’s take the PPP program as an example. If I was building a system to handle these applications, it would need to accomplish the following tasks:

• Handle form submissions to either complete the SBA-approved PDF electronically or via other approved means.
• Handle the ability to upload supporting documents.
• Allow for e-signatures if applicable (seems some banks are foregoing this on the application process).
• Allow for the above in a secure means.
• Provide some exporting capabilities or management tools, reporting.

Overall – not a complex application. Of course, there is nuance there, but for the most part, this is easily manageable. So what is the best way to take the above bullet list and start to make it a reality?

Prototyping

The best way to get a visual is to begin prototyping. An application such as the above should be relatively quick to prototype, and if you are smart, you will use a third-party UI/UX or existing libraries your company has to quickly take the bullet list to a workable prototype. This step is essential because time is of the essence. You can quickly roll out something clickable and can get easy approval or iterative revisions before having a development team work on implementation. In a process such as this, prototyping is your design, architecture, strategy, and product development cycle, all in one. Because time-to-market is critical and the above application is simple – there is no reason you need a giant team to do this. You can have a small, focused team turn around this concept in hours, not days.

Your Methodology? Agile Only!

We’ve covered the waterfall vs. agile debate before. In this type of project, there is no route forward other than agile. That is because the following conditions have been met:

• There is no written and agreed specification: because you haven’t the time.
• The requirements are changing: because the nature of the PPP program is changing hourly.
• Testing and quality assurance are happening simultaneously.
• The timeframe is aggressive, making the waterfall methodology incapable of success.

Agile will allow you to quickly develop the platform, make amendments on the fly, focus on short term deliverables which can keep the project moving, and also allow you to easily add or remove team members from the process along the way.

Picking a Technology Stack

When you have an urgency and a need to go-to-market quickly, you sometimes have to make choices, especially in terms of what tools or technology you use to get your product online. I saw a bank this morning, as I referenced above, who utilized DocuSign for the entire application process. It wasn’t the prettiest system, but it got the job done. In a crisis, you shouldn’t always feel as though a stop-gap solution isn’t worth considering. Is DocuSign how I’d do this? Or, is it the most elegant? Well, not especially. But if it helps you get a product online quickly that can help your customers or your business – then go for it.

I think the determination must be based on the nature of the product. The PPP, for example, is a program that directly helps businesses in a time of need and also assists the banks because they are getting fees for facilitating the loans. Because of this mutual “need”, both parties are a bit more willing to deal with functional inconsistencies.

However, if you are trying to build a new line of business to keep your company afloat in this time of need – well – you should choose wisely to ensure you are presenting the best product possible in the shortest time to market. You may not have another chance to prove this revenue stream works if you fail the first time. So, let’s say you are building an e-commerce to offer direct-to-consumer shopping while the crisis is affecting your core business. A noble idea, but make sure you execute right. If you put up a quick, dirty, and not intuitive shopping system, it will likely backfire, and you’ll be in worse shape than before.

In the PPP example, you do have a few choices. As mentioned, one bank used DocuSign. Another is using their pre-existing style guides and functional UI to build custom forms. There are many ways to make an application, and your choice has to be based on a variety of factors:

• Is this something where you have leeway to go to market with perhaps a less-than-elegant solution?
• Will you have time in the future, via subsequent phases, to better the offering, or does this have to be done right from day one?
• Do you have any pre-built infrastructure that you can use to support this new application?
• If you chose a quick go-to-market solution, can you iterate on top of it or easily transition away from it later?

These are just a few of the crucial considerations that must be considered as you plan the implementation of your initiative.

Deployment

You have to come to grips with the idea that you may deploy something that isn’t as up to snuff as you’d prefer. And that, provided you are not putting anyone at risk, is okay. You have to consider the fact that you are deploying software earlier in the process than you usually would, and you will have had less time to find edge-cases and unique bugs or anomalies. The critical difference here versus a typical development cycle is that you will continue iterating at a rapid pace immediately post-launch as you become aware of more holes in the process that you may have missed.

This is particularly true if you are going to have your project scale in the short term. Today, we already saw Bank of America’s application for PPP go down in the first hour. Traffic and scale have a way of immediately showing you where your system is vulnerable or has inefficiencies. Unfortunately, without having time to do proper load tests, you’ll have to handle some of this on the fly. First off, have the expectation in your head that such issues will arise and be ready and prepared to treat them as they present themselves.

Iterate at the Same Pace

One last note – as we said above – the idea of a quick development cycle means you will have lots of follow-up work to do. This includes iterative improvements, bug fixes, and all that goes with it. You cannot slow down back to your normal processes to get those fixes in place. The speed you utilized and the quick-approval processes in place to get these applications live must continue. Otherwise, you’ll be using a broken and bureaucratic system to manage something that was built in a totally different methodology. For the time being, keep up the pace and flow of improvements and bug fixes. If this was so essential that it needed to be built in record time, then the repairs are as important, if not even more so.

Wrapping Up

I spend a lot of time consulting and working with large enterprise groups. I’ve always been a small business kinda guy, with the largest company I ever worked for was about 30 people. I understand how to navigate corporate bureaucracy, but I don’t agree that it needs to exist. Just yesterday, I was speaking to a friend of mine who runs a non-profit organization. They want to deploy a digital application process for an assistance program focused on low-income individuals. Today it’s a physical form that makes it difficult for participants to complete. He inquired about building a system, and I estimated two months would be appropriate, if not a bit faster, to get it done. Honestly, it’s probably much faster than that.

Alas, in speaking with the state who oversees the program, they said they are already one year into the development of a similar application, and it will be done sometime next year. The fact is, there is a ton of waste out there. People and enterprises spend 10, 20, or sometimes 100 times more than they need to deploying technology solutions. They are paralyzed by process and unable to deploy anything quickly. This is why we have an interruption economy made up of start-ups that are quickly iterating products to compete with companies who are too large to keep up.

I hope that as a takeaway from this period we are going through, companies and organizations can begin to embrace agility and look at their own processes concerning technology solutions. If you have a team of 30 or 40 folks working on something as simple as the above – you might be over-employed for the project and overcomplicating things. Hopefully, as more and more companies embrace technology to solve immediate needs, they will realize that these solutions can be simple, implemented quickly, and be maintained without the massive overhead and red tape.