How to Manage Your Development Budget

[object Object]

We build custom softwareincubate product ideas, and teach technology. This means we are spending a fair amount of time with companies of all sizes. We hear all sorts of war stories that span issues with founder break-ups, budget, off-shore development woes, horrible experiences with software shops, and an inability to launch products people love.

I am continuously surprised by how many people we come across every week that have a story that starts this way: “We spent half our budget on software development in India. That didn’t go very well so we shifted our efforts and spent the other half of our budget on software development in Ukraine. That didn’t work either. We have spent all of our product development budget and have at most half of our product complete! Now, what do I do?”

This isn’t just an overseas story by any means. We do hear more often about off-shore stories and near-shore stories that are similar to this but we also hear the exact same stories with regards to large and small local software development firms too. Sometimes this problem stems from a company trying to directly manage a development team when their industry experience isn’t associated with that skill set.

This is a common story to us. If you fit this description, don’t worry, it’s not just you! In a lot of cases, it also isn’t the development team you’re using. There is usually a mismatch in experience, expectations, and assumptions.

It’s hard to believe but software as an industry is still relatively young. The industry likes to claim “best practices” but since software development is continuously under a state of development itself, the only best practice is an ability to embrace and manage the continuous change that surrounds the software industry. A good practice today is considered inappropriate tomorrow.

I have now been involved in technology product development and software consulting for 20 years. In that time I have learned more programming languages, frameworks, and tools than a room full of people have fingers and toes. Learning is non-stop. We have undergone a continuous paradigm shift. This has included building:

  • desktop only applications
  • web applications that run on one server
  • web applications that span multiple servers
  • web applications that live on virtual servers
  • distributed applications on virtual servers
  • containerized applications
  • the migration to “microservices”
  • then nano-services
  • “serverless”

And this is just a consideration of high-level backend and infrastructure concepts. The landscape of front end frameworks and concepts moves at an even faster pace!

So then, how is a non-technical person, perhaps a subject matter expert in their given space, supposed to manage the planning, budgeting, quality, scalability, and delivery of a software product while also focusing on the consumer fit, business plan, marketing, and sales of their product idea? How would this person be able to identify the right people for their team? And how would they be able to judge the quality under the skin of the product being delivered by their team?

They will struggle. Not impossible to manage but also not suggested!

Some people have expressed how “lucky they have been” with the choices they have made so far. And that does happen from time to time! I would estimate that 50% of the folks that we speak with have these issues, and the other 50% don’t (wild back pocket guess). Likely a small sample size too. But the problem is real either way.

What can you do to have a higher likelihood for success at your first time running a technology project and hopefully not find yourself in this situation?

  • Join mentorship programs, meetups, and masterminds to ultimately expand your network with qualified people. (if you are in the Austin area we have a meetup for engineering managers)
  • Partner with someone that has deep experience building or doing what you want to build. Interview as many people from as many different groups as possible. Think about it like dating, don’t get in a rush to marry someone simply because they are there. Find the right person to take on the aspects of your project that you aren’t comfortable with. And make sure that you enjoy spending time with them (culture fit is critical).
  • Don’t go “all in” with the first software firm of your choice. Give them a piece of work to prove them out. Give someone else a piece of work to prove them out. Then compare the firms on communication, proposal accuracy, professional fit and finish around what they built, etc. They need you more than you need them! Your success should be their highest priority.
  • Date your service providers (of all types) before you get married to them. Check references.

Feel free to reach out if you are already finding yourself in a similar situation. We are always happy to help and can likely point you towards a better solution.

grey dotted shape