Stuck In a Bad Relationship
A startup founder approached Blue Bridge for the reason that many people do: they were unhappy with their current web development provider. They were extremely slow and weren't able to make changes to the application they developed without breaking it. The founder wanted to be able to scale up their business development but wasn't confident in the stability of the application.
On our initial call to discuss the project, we discovered that the application had been developed using an offshore developer. The founder had thought that he was hiring a firm in Massachusetts, but they were actually flipping the work to developers in India. This was something that became apparent after several months of working together and wasn't disclosed at the start of the relationship.
Our recommendation to the founder was to do a Code Audit. We explained that it's typical for offshore developers to do the least amount of work necessary and try to bill as many hours as they can. It's been our experience that this approach to work is riddled with security holes, breaks easily, and is difficult to improve. Many of these were symptoms that the founder had already experienced and and they agreed to hire us to take a look.
The Code Audit
A week later, we met with the founder to discuss the results. As expected, the application was a mess:
- There were over 120 SQL injection vulnerabilities due to a lack of input filtering. This would have enabled a middle school hacker to alter or even completely destroy the data that the entire business relied upon.
- Two different platform databases were being used to run the application. This increase the needed development time to work on the application because it prevented using the existing input filtering capabilities of the core platform (which the previous developers weren't doing anyways.)
- The offshore developers had stolen code from another platform and were trying to use this code to run the application. Coders refer to this behavior as "copy and paste programming." It saved them time initially, but because they didn't actually know how the code worked, the result was code bloat that slowed the application down, made it more susceptible to attacks, and made it unpredictable and easy to break.
- The developers had "hacked" the core platform by changing the code to run how they had wanted to run. This effectively locked the application into that version of the platform, preventing security patches from being applied in the future.
The result was what the client experienced: an expensive to expand, difficult to maintain, and very fragile application.
We try to avoid recommending code rewrites to clients because they are expensive and often unnecessary, but in this case we felt that it really was the best option. The founder agreed with us and we submitted a proposal to do so which they accepted.
Ready to Sell Again
Six weeks later we completed the rewrite with some additions and enhancements. The founder was extremely pleased with the speed with which we completed the project. It had taken them five painful years to get the application to where it had been when they encountered us. They were amazed that it only took us weeks to rewrite the entire mess. They were also surprised at how much more intuitive and quick the application worked when it was executed according to the conventions of the platform.
Having regained their confidence in their core product, they booked a sales meeting with an enterprise partner and were able to focus again on growth without having to lie awake at night worrying about their product falling apart. As important, they knew they had someone in their corner that they could rely on when they needed to grow the application again.