The disciplines of service architecture, continuous integration and delivery (CI/CD) are not native to most development shops. To the layperson, these are all tech buzzwords. These disciplines are unique areas of technical expertise reserved for larger IT departments and companies that have robust architecture, engineering, database, DevOps, and content delivery capabilities. Most importantly, they also do Application Performance Monitoring. These skills are not in any way in the skill set of your “classic development shop”. Yes, you went to a podiatrist for a facelift.
Ordered a Ferrari. Got a Pontiac.
So, what does this mean for small companies that have outsourced the development of their web app, mobile/native app, PWA, or software to classic development shops? It means often the project is completed, you pay for this solution, you get a salute from the vendor. And when you need updates or want to integrate it with something else, you pay through the nose if they oblige you at all. And you have no idea if it will be secure, perform well, or scale at all.
Sound familiar? You have an “orphaned app” of dubious quality and questionable performance “at scale” – and you just got started. Well, you are not alone.
How Did This Happen?
The hard truth is the answer lies in your lack of expertise in cars and your lack of diligence in researching what you were buying. The same holds true for custom development. Most buyers don’t know what to ask for. And even if you did know what to ask for, how would you verify the quality of the solution? The truth is you cannot, or you likely would have the expertise to build it yourself.
Now let’s talk about performance. The overall performance of your application depends on how the application is built, what infrastructure it runs on, how scalable the component architecture is, as well as how well the code is written. When you buy an app from a development company that does not do architecture design and hosting as a core business, you are essentially buying code that has not been tested to scale. The vendor will likely deploy your code to a single cloud server running everything including the database. They will ask you to test is to make sure it does what you need it to do (the minimal requirement), provide enough fixes until you accept it, and send you a bill.
The bottom line is you probably asked for “working code” and that’s all you got.
Building is Easy. Maintenance Takes Commitment.
There are literally thousands of these “classic dev shops” promising to leverage their vast development resources to build your app “for a fraction of the cost”. Why are there so many? There are so many classic dev shops because many countries have a glut of developers that have been churned out of school with basic skills that do this work for peanuts. And the initial development of something is where the easy money is. The quality of the work is likely not a success factor. The objective is to minimally meet the requirements and get paid. You want a warranty? Good luck with that. You wouldn’t buy a car without a warranty. Why would you buy a tech solution without one? But it happens all day, every day.
What does that mean for you? That means that eventually, if your business model is realistic and the use of your application grows, you will have performance issues, security issues, and maintenance issues. It’s not a question of if, it’s a question of when.
It’s All About the Foundation
Many people use the old “house foundation” analogy. But it is so true here, I will risk it. The environment hosting the thing you just paid for is the foundation of your solution. Some questions you should ask:
- What is my roadmap for the solution over the next 3–5 years?
- Will the solution support the roadmap and all the users we anticipate?
- Can it scale efficiently to support the user base (whatever that user base is) with no interruptions?
- Who will maintain and monitor the ongoing performance of my solution?
If the answer to any of the questions is “no” or “I don’t know”, stop, and get some help from a solution provider, not just a “dev shop”.
How to Engage a Solution Provider
Ideally, you should make sure you have access to adequate expertise to scope and manage your investment. You should understand that vendors are very good at presenting things that sound good initially, but don’t necessarily meet the needs in the long term. Like everything, the technology space is a “buyer beware” world. If you have a trusted and reputable vendor, it is much easier. But it is always a “trust but verify” situation.
Your best defense is a team of experts you trust with the experience and skills to help you ensure you get what you need.
The Minimum You Should Do
If you are thinking of hiring a vendor with unknown performance, you should do your diligence. The level of diligence depends on many factors, not least of which is the cost. But ideally, the diligence you do should be adequate to mitigate the risk. Development is a service like any other. And to protect your investment, you should consider some best practices when engaging anyone providing you any service:
- To protect your Intellectual Property, execute an NDA with the vendor prior to discussing your needs in any detail.
- Require 2-3 reputable and verifiable references and verify them before engaging the vendor.
- Have the contract reviewed by a contract attorney. At a minimum, this should include terms such as:
- warranty terms and guaranteed service levels,
- the deliverables be delivered to you, and not owned or managed by anyone else,
- and Independent Verification and Validation (IV&V) of the deliverables reviewed by a third party.
Honestly Assess Your Own Skills
Last and most importantly, you need to be honest about your capabilities. If you own a business, you likely have one, if not several, areas of expertise. If technology development or contract law are not in your wheelhouse, admit it and enlist the help of a professional with those skills. You will be glad you did, and you won’t end up holding an orphaned app wondering how you got here.
