Most people wouldn’t think that one of the keys to writing the best code and developing the best product is vulnerability. The opportunities and rewards that come from working in an open and transparent environment are innumerable on the personal growth scale, but perhaps more importantly, the resulting code base and end product are refined and honed far beyond what any one person can do on their own. Our team is dedicated to functioning in this highly productive manner where we collaborate and innovate daily. We invite our clients to open up and share everything about their project so that we may provide the most meaningful and deeply impactful assistance.

Most of the startups we work with are still in the concept stage when the product consists of ideas on paper, some rough wireframes or a proof-of-concept prototype. The initial challenge is to understand the founders’ goals and help them design a product that meets the needs of their users without blowing the budget on extraneous features which can be pushed to another iteration or cut entirely. When we deliver that product it is crucial that our code is professionally written so that the next developers, often an in-house team, can take over where we left off. We make our code and ourselves available to answer questions to ensure a smooth handoff, as any cracks in our work represent cracks in our reputation. Quality assurance is an ongoing process that requires open collaboration between our team and the client.

It can be a bit unnerving to have someone pick apart your work and we understand that it can be difficult for someone unaccustomed to this kind of approach. We insist on working in this manner since our experience has proven that it nets the best possible results. Coshx Labs is built on collaboration, transparency and trust; even our interns grow accustomed to having more experienced developers dig into their code in order to make it as strong as possible. This is how we transfer knowledge between our team in order to grow as individuals and as a company that builds great software. Although inexperienced developers can accomplish great things on their own, sometimes it takes a more seasoned individual (or just another set of eyes) to ensure that a particular approach will not cause inefficiencies down the line. This approach is baked into both our culture and our methodologies which benefits all the products we work on and the businesses built on top of them.

Sometimes the teams we work with have the first iteration of their product built, often by a founder that has taught themselves how to code while working on the project. In some instances, such as Kidfully, the product works from a functional perspective but can use the expertise that we bring as consultants to ensure long term viability and extensibility. In this instance the founder believed firmly in his ideas but recognized that the code could be improved. We commend and appreciate his ongoing desire to learn and to refine the product by drawing on the experience of those he works with. (disclaimer: we provided help but Mike built the vast majority of Kidfully)

Being able to defend ideas while remaining open to advice is a balance that is hard to achieve but it is vital for the ongoing success of a company. This is where the concept of vulnerability really takes off. It requires confidence along with the understanding that you do not have to be Superman to make the world move.

In some instances we work with teams that are reluctant to share their code and open it up to scrutiny. This is a major red flag for us and an opportunity to encourage them to be as transparent as possible. Generally teams respond well once they realize our goal is simple; to use our expertise in order to maximize the value we provide to our clients. It is imperative to verify that when all the development components are merged there are no unforeseen complications that lead to wasted time and money, or worse, a product that does not work. We can only do this when we are able to see the entire system and understand the product road map, while acknowledging that products will evolve as the market demands.

A refusal on a client’s part to share the code base and work in seamless collaboration is a non-starter for us. We just don’t work this way. If we can’t see the whole project to assess and build to the best of our talents then maximal value is not provided. Our developers care deeply about what they do and won’t compromise professional integrity for the sake of chasing dollars. Larger companies often bring us on to add technical firepower to one aspect of their business, but working on new products in pieces and parts without a good understanding of the whole system is highly inefficient. It is akin to building a beautiful penthouse apartment and plopping it on a shoddily built foundation that comes tumbling down. This is a shame when a tour of the basement would have revealed the cracks that needed mending.

A reluctance to work openly is often derived from an inability or unwillingness to be vulnerable which manifests as insecurity and arrogance. Insecurity about letting others find and fix poor choices, which is inherently an improvement of the code, and arrogance that one possesses all the answers already and needs no one to suggest anything else. When our team provides professional advice and recommendations it is derived from our experience and has nothing to do with the relative intelligence of our team and those we work with - we are just as fallible as anyone. Where we are different is in our willingness to be open and grow from each others’ experience or point of view. It takes a crafty individual to come up with an inefficient solution to a sticky problem but savvy professionals invite others to hold up the mirror that allows them to see how they themselves may be causing problems.

We exist to help young companies thrive, but our product and programming expertise is only part of the equation and the most value we provide is often heading off mistakes that companies will pay for down the road. It is easy for teams to be so preoccupied with whether or not they could that they didn’t stop to think if they should. (I would like to see Dr. Ian Malcolm debate lean startup principles).

This may seem trivial for a startup that wants an MVP to test market validity, raise capital and move on from there. It is not. For starters, what happens when you need to iterate rapidly or your site crashes due to a spike in traffic? Pulling a product for a rebuild is costly, both in terms of development time and market traction. Delaying in-demand features opens the door for competitors to execute when you are busy paying off technical debt. Most importantly it sets a terrible precedent as any successful tech company will need many developers working in unison to grow a product. A lead developer that will not open their work or trust their team will have a hard time gaining buy-in from top tier programmers that are problem solvers and not mindless workers. How can a team expect to scale when a culture of obfuscation and siloed work persists, rather than a culture of collaboration and constant improvement?

Side Note: I have, for years, been using the word ‘convicted’ to mean ‘full of conviction, or the feeling of being sure that what you believe or say is true’. This is wrong, which was pointed out by my friend and colleague Dave Kapp when he reviewed a draft of this post. I felt a little dumb at first but became a slightly better writer and speaker due to his astute observation and desire to help.