Symbiosis of Code Quality and Iteration

sym·bi·o·sis /ˌsɪmbiˈəʊsɪs/ noun: A mutually sustaining relationship between two unlike things. Neglect one, and the other quietly collapses too.

Code quality and rate of iteration are often thought of as conflicting principles. Intuitively, you might expect that spending a lot of time improving code quality slows down the rate of iteration and vice-versa. In this article, I spoke with an engineer at a growing startup to understand how they tackle this conflict, and compared their approach to companies of different sizes in an attempt to discover the role each plays in driving success.

Background

[Update — 2026]

Since this piece was written, Cord has rebranded to Encord and grown into one of the biggest AI startups out of London. In February 2026 it raised a $60M Series C, taking its total funding to roughly $110M at a reported $550M valuation. It now positions itself as the data layer for “physical AI”, working with teams like Woven by Toyota, Zipline and Skydio. The interview below reflects the company as it was in its earlier, scrappier days, which is exactly what makes it a useful snapshot.

Cord is a 2-year-old startup that’s raised $12.5M in series A funding¹. We spoke to John Smith, a Backend Engineer at Cord, to gain insight into their practices. He explained that early on, there were no formal development, testing or documentation procedures in place. He believes this fuelled their success by allowing the founders to focus on building the product quickly. However, as the team of developers grew and the complexity of the product increased, the lack of these practices started to obstruct productivity. This is because new developers struggled to understand the codebase and, with more developers came more code which made it harder to keep track of everything. Consequently, to pay off tech debt Cord developers are now building their first test suite and documentation for existing features, while continuing to develop new features.

Growing pains at scale: Twitter and Netscape

Twitter and Netscape both had to deal with technical debt and growing pains after becoming market leaders. Twitter started gaining popularity around 2007 and by early 2010, they had to migrate from third-party hosting to their own internal infrastructure. In 2015, the company started to experience growing pains again as they began to reach physical scalability limitations and had to re-design their service architecture to handle their needs. Fortunately, Twitter had enough resources to fix their problems with minimal impact².

Netscape, on the other hand, similarly had problems with code quality but their story didn’t end so well. In an attempt to keep up with their rivals, they hurried to add new features to their browser. This resulted in poor code quality that was hard to refactor, reuse, and test, leading to the release of a very buggy version of their browser³. While Twitter’s problems were focused around scalability, and Netscape’s around adding more features, these case studies illustrate how important it is to manage code quality and architecture, no matter the size of the company.

Listening to customers, not just their requests

Code quality is not the only driving force for the success of a product; taking into account customer needs is also key. A faster rate of iteration allows for more feedback, which can help keep a company on the right track. John noted that minimising client churn is currently Cord’s vital priority, so he will sacrifice code quality to deliver on urgent client requests. However, clients are notorious for not knowing which features they need⁴. John described how a large client requested a complicated new feature which took two months for the founding developer to implement. After releasing the feature, they discovered the client never used it.

Hence, it is important not to take client requests at face value but to spend time understanding what their underlying problems are. To support this, Cord has adopted Hotjar, which records user activity on their platform, to build a better understanding of how clients use their software⁵. By using Hotjar to track real user pain points and the usage of new features, development on expendable features can be minimised, freeing up time for more critical work. This increases both their rate of iteration and product quality.

A/B testing: failing faster to scale faster

Similar to Hotjar, A/B testing enables tech firms to better understand user engagement and apply this knowledge to produce a high-quality product. It is a method to compare two versions of a feature to determine which one users prefer⁶. This has become popular amongst established firms like Microsoft and Amazon who conduct over 10,000 A/B tests annually⁷. Research by Koning et al. shows startup firms can also benefit from adopting A/B testing by scaling and failing faster⁸. Founders are able to recognise if their idea is flawed faster, and startups implementing these tests are more likely to scale faster and innovate, introducing new products up to 18% quicker. Delegating small design choices to A/B tests enables founders to spend more time on pivotal decisions.

At Cord, John explained how A/B testing hasn’t yet been implemented as currently their release to production is manual and they need a faster and smoother deployment pipeline in case a rollback is needed. Cord chose to keep their deployment pipeline simple for now, to focus on developing key product features and keep clients satisfied.

This is in sharp contrast with the iOS app startup by Sam and Joe, where an advanced deployment pipeline was implemented early on, enabling a smooth rollback procedure. However, at the time, Apple had a 2-week review process, rendering the startup’s advanced automated deployment pipeline an overkill since they couldn’t release faster than every two weeks anyway. Considering Sam and Joe had secure procedures in place to roll back, they could have benefited from A/B testing and “failing faster” to quickly discover their idea was flawed.

The takeaway

Early-stage startups can benefit from taking on tech debt to meet short-term goals, allowing them to iterate quickly, gain customer feedback and fail or scale faster. However, this risk should be understood and mitigated when possible, to prevent hindering long-term success. As companies grow larger, so does their tech debt and this alone can cause the demise of a product, as poor code leads to more bugs, which are harder to catch, and no one wants to use a product that constantly crashes. Code quality and rate of iteration have a symbiotic relationship which can be mutually beneficial.

Written by me together with two of my Imperial College London classmates, Guji and Amelia