I’ve been working in the software development industry for several years and have worked with dozens of start-up founders and small business owners during my career. At Equaleyes, whenever we’re discussing a potential project, we’re dealing with different types of people – each of them unique.
Commonly we’re dealing with clients that have a product idea and are searching for the cheapest solution they can find. In the majority of cases, they have limited understanding of the problem they’re trying to solve and are new to building a digital product. Their bosses, investors or buyers are adding additional pressure by setting time and budget constraints.
At Equaleyes we take projects on a case-by-case basis. Over the lifetime of our company, we have lightheartedly taken on several projects that we shouldn’t have done. As a fledgling company, we were eager to sign any client that we could. Once we signed the deal, we were delighted, until we saw the mess we had got ourselves in to. Then we were sad and depressed. Eventually, we’ve learned that taking on a cheap project and providing an affordable service, to be able to earn a small amount of money, doesn’t do anybody any good. In the end, it’s not good for the clients, and it’s not good for us. We’ve had our share of blunders, and this has made us more selective about what opportunities we say yes to.
Looking through the successful projects we’ve done in the past, I’m noticing a common pattern. The more successful, stable or knowledgeable the client is, the less they are pushing for the cheap and fast development, and the project is getting a much better return on investment once it’s finished. And that makes sense. If the product is not good and it doesn’t solve real problems, then it doesn’t matter if it was built on budget and on time.
What makes developing a digital product expensive?
More than 68% of all software projects fail. The most common problems are a mix of technology challenges, building a product that doesn’t add enough value to the users and time and budget constraints.
It’s common knowledge that it’s important to learn about the user. In reality, knowing the user is extremely hard. Even the user themselves seldom knows what they want. Only a dedicated team can solve complex product problems by frequently testing assumptions while being in close contact with the user.
There is seldom one big technical obstacle that prevents a product from succeeding. The real technical challenge is the fact that the small unknown problems start piling up just a couple of weeks after the development has begun. Each software project we took on had its specifics, and it was a black box on its own. The Agile development methodology, in reality, means that each week of the development our perception of the project changes. Over time we slowly reveal the mysteries of the product, and this usually means uncovering a pile of additional problems and work. The deadlines and budget constraints usually stay the same throughout this process.
It’s easy to succumb to temptation and take a shortcut here and there to speed up the development and save time, but this often ends up becoming a common practice. The product development becomes similar to running in an accumulated pile of mud. The more mud, the harder it becomes to run fast and, eventually, you get stuck. In IT we call this a technical debt. It’s tough to provide precise time estimates for the development work, especially when we are building an innovative product.
The essence of a good software development agency
Jesse Watson, a software development manager at Amazon, wrote an interesting blog post where he outlined that the real value in software development is created with the synthesis of programming skills and deep context. The deep context, he explained, is that the developer acquires substantial knowledge in particular fields throughout his career and can, without much thought, anticipate where problems might appear. He can predict difficult situations and provide suggestions with precision and with ease. In a way, it’s similar to how a boat’s captain is capable of safely navigating through the water, even in the dark and with limited reliance on instruments.
Recently we took a substantial project which included the development of a shop with a payment process. After agreeing with the client on payment provider and going half way through the implementations, our client found out that there will be restrictions on what type of products he can sell and that this will massively impact his business. In the end, we had to throw our old work out and start preparing alternatives for implementing a new one. This experience has now provided the team with experience and deep context skills in this area – allowing us, like the ship’s captain, to predict and anticipate potential hazards as they might present themselves down as we chart a course through the waters of digital product development.
The essence of a good software development agency is the ability to utilise and nurture the deep context skills of their employees and learn to amplify that talent through training and the knowledge sharing process. And this is how I intend to lead the team here at Equaleyes.
BONUS READING: All your product is missing is a user guide, but you’re not sure where to start with it? And what about the legal requirements? Ferry Vermeulen has those answers for you in his article – User Manual Template Case Study: Startup Creates a Compliant Manual (in Less Than 3 Weeks) and a template with the legal parts included! Make sure to check it out!
