Software development · Product Development

How do you choose the software development partner that suits your business?

Anonymous

September 15th, 2015

I have a potentially lucrative software-based business idea, I've been talking about it with industry thought leaders for quote some time now, I consider it as validated. However, I am still to build the MVP. Which takes me to the question: what's the right software development partner? I want to better understand the process of going from having the initial idea to selecting from a shortlist of the right people/agencies.

Peter Johnston Businesses are composed of pixels, bytes & atoms. All 3 change constantly. I make that change +ve.

September 15th, 2015

Start with this thought... http://dilbert.com/strip/2015-09-11
Then read The Lean Startup by Eric Ries.

What you will begin to realise is that an idea is only part of making a business work. That creating too much is just as bad as creating too little. And, most importantly, that a business is more than a piece of technology - it is a living thing which will change continually. As Steve Blank put it... "No Business Plan survives first contact with the customers".

So if your idea will undoubtedly change, what do you do? Tie yourself into someone contracted to design what you have specified, leaving you with a fixed first iteration you cannot change? Of course not.

What you do is find someone else (or people) with a similar vision to you, just as much intellect but the skills you lack. You and he/she can pool your respective skills and hopefully create a whole bigger than the parts, with their skills helping you see better and your skills helping them see better.

Whether they work for you or someone else, by the way, is irrelevant at this stage. But buy the person, not the company. And when the opportunity becomes real, be ready to welcome them on board.

Simon Effing Technical Advisor and Scala Developer. I build sustainable MVPs for lean B2B startups.

September 18th, 2015

Look for a technical partner that shows interest in your business and listens to you.

Software development is a continuous process of decision making, therefore developers need a deep understanding of the underlying goal of their work.

The traditional approach where developers just follow instructions or specifications causes a lot of trouble and friction. It puts all the burden of requirement engineering on you. And even the most detailed specification leaves enough wiggle room to build something completely useless. 

Experienced engineers can provide a lot of valuable input and ideas on how to structure requirements, find shortcuts, avoid unnecessary costs and optimize the overall process. Requirement engineering and software development should be highly interactive.


Build a long-term trustful relationship.

You have to trust your engineer because there are important parts in the development process you can't control.  

Here is an incomplete list of the hidden qualities of a software solution:

  • Security: There is huge number of possible vulnerabilities, here are some examples https://www.owasp.org/index.php/Top_10_2013-Top_10
  • Consistency: A system might show correct behavior under low load, but when exposed to high concurrent access suddenly generates random corrupt data. These kind of errors are typically not reproducible and might even corrupt existing data.
  • Protection against data loss: Your data is you most valuable asset. Software bugs can be fixed but lost data is gone forever. Is there a regular backup plan in place?
  • Availability: Is the system able to run 24/7?
  • Scalability: What happens if your application suddenly gets a lot of traffic? Is it easy to scale up without investing in new expensive hardware?
  • Maintainability: Even if all other qualities are Ok, you might have a solution where the source code is of so poor quality that it is impossible to make changes or add new features without breaking things. I've seen projects where the entire solution had to be rebuilt from scratch for this reason.


Although I've just scratched the surface I think you get an impression how crucial and potentially dangerous these high risk factors are for your business, but it's completely impossible to verify these for a non-technical person. The consequences might show up only months or years after the completion of the project.

So why should a developer care about this if it's so easy to rip off a client by just ignoring these factors? 
First of all, good engineers have a sense for these qualities ingrained in their DNA. It hurts them to ignore these issues.
And second: the fuel of a software engineering business is reputation and referrals. Experienced developers are totally aware of this. 

Talk to the person and build a personal relationship. Ask about these hidden qualties and how they should be handled. 


Use a written contract

This might look like a contradiction to the previous point, but it really isn't. Things can go wrong, even in relationships that started really well. It's a bit like a pre-nup ;)


Avoid time-based rates

Trading time for money automatically generates a conflict of interests and for a non-technical person it's impossible to check if the hours on the bill are realistic or not. 

On the other hand, real-life projects are just too big and too much in flux to agree an a fixed price.


I prefer an iterative fixed-price approach:
  • define a first package of features which can be delivered within less than two weeks and agree on a quote.
  • after the package is finished, review the result and check if it conforms to the package definition.
  • At this point you have the opportunity to revise the overall direction of the project and react to changed business requirements. Define the next package and reiterate.

All these steps should be conducted in close collaboration of business and engineering.


kooveli kv independent consultant / tutor at Prime Consulting Group

September 19th, 2015

Appreciate Peter's closing sentence Set out to build this team, rather than simply take on a contractor to build your idea. This is the essence of it. I had a similar with my website. Realised that taking a dip in the water pays, though uncomforting / scary initially

Peter Johnston Businesses are composed of pixels, bytes & atoms. All 3 change constantly. I make that change +ve.

September 19th, 2015

When technology was new, business leaders were frightened by it. So they put out the idea that "Developers are mostly techies who cannot visualise what is needed best for your or even to engage with you in a meaningful discussion in defining what you need because they cannot understand / communicate in a business language and you cannot speak their language."

And IT was hard enough that the people who could do it WERE a breed apart - they spent their day wrestling with code which didn't work, data connections which were hard to create/maintain and User interfaces which were far from intuitive.

Those days are long gone - over a generation ago. We've gone through the PC, end-to-end software, the internet, search, social, mobile, data eras and are about to hit the virtual reality and singularity (smartphones cleverer than people) eras.

Modern executives are IT aware - often the technology they use at home is ahead of that available in the workplace. And IT people are business aware - they are now the architects of the user and customer interfaces through which people interact with companies - they are often the human faces of their organisations.

Eric Schmidt talks of the Clever Creatives - people who understand technology, business and creativity - as the holy grail people for the future. For most of us, that is a team, rather than an individual. But it should still be the goal - each of these will have a different vision and uniting all three will give a 3D view which is stronger than any individual one.

Set out to build this team, rather than simply take on a contractor to build your idea.

Aik Arutunian CMO at Reinvently, Head of Marketing at Provectus

September 21st, 2015

Couldn't agree more with the thought that "choosing an outsourcing provider is just a shade lower than choosing a life partner". The right developer makes the difference between failing miseraby and letting your competition far behind.

As for the details you shared, it looks like the perfect case for outsourcing. I myself am an evangelist of "outsource everything but your soul" approach, which has worked great for me on multiple projects.

Start by checking out this article

Guntis Urtans Managing Partner at Colabpro

September 15th, 2015

I do not think there is no single recipe for this.
Long term you will be willing to keep core expertise in-house, therefore you may want to find and hire somebody who could then build the team around.

However for MVP it might be overkill - so outsource development could be  option as well (may not work however if development contains significant R&D component).

As for outsourcing - wide selection and no single recipe again :)
As it was pointed out in some other discussions -  good references will reduce risks, while may not give you awareness that you have picked the best available option, so consider few alternatives might be good idea.

If you will decide to evaluate outsourcing option - my company actually provides services of selection of right team from pool of 40+ companies whom we have selected on basis of earlier assessment and/or previous project experience. 


Anonymous

September 15th, 2015

I very much agree with Peter's advice above. It is extremely likely that your idea will go through significant changes as it develops and as you learn more. Whatever setup you have needs to accommodate that.

Outsourcing is a good option if (and only if) you are building something rather small that is only intended as a learning opportunity or perhaps as something only intended to be demoed for potential stakeholders. In this case, the risks (=budget) is so low that if one supplier fails it's not a big deal.

If you want to build an MVP that you intend should grow into the final product you need someone with a strong technical background who can help you evaluate and select developers / developing firms and manage the development process. Just sending over a specification and expecting a remote team to develop something good is highly unlikely to work. For finding that person I think you will have to rely on recommendations.

An internal development team would of course be the best option, but it takes a lot of time and resources to build one you would still first need that one tech guy you really trust who can help you build one and set up the structures for it work well.

Peter Johnston Businesses are composed of pixels, bytes & atoms. All 3 change constantly. I make that change +ve.

September 17th, 2015

It may help if you reframe your view of an MVP. Think of it as a scoping exercise.

An experiment to see what you actually need to build, by building something as simple as you can imagine and then testing it on some people to see if they really want it, what bits they value and what they'd like you to add.

Once you have that information, you'll be able to write a brief to a development partner saying build this, create that. You'll know what size of partner you need, whether a co-founder might be better or whether you can buy 90% of it off-the-shelf and customise it.

If you make that choice before you've done the scoping exercise you run a high risk of choosing the wrong route. So don't make a long-term decision now, do what's required to find out what the future looks like. Looking for a long-term development partner is choosing an answer before you know the question.

Andrej Kostresevic

September 24th, 2015

Find someone who speaks your language. There is often a big gap between your vision and a developer's understanding of your vision.
Find someone who gets the business goals enough to recognize which decisions are important to bring up to you, and which ones can safely be made in your absence.
Find someone who is comfortable saying no. An energetic CEO with metaphorical ADHD (aren't we all) and a "yes-man" technical parter is a recipe for disaster. I've seen million dollar budgets wasted with this combination.
Find someone who asks why? As in - why is this important? (best when combined with "no" when appropriate)
Find someone with a proven track record. Have they demonstrated ability to deliver? 
Find someone whose working style matches yours. Do you want daily check-ins? Weekly builds? Whiteboard brainstorming, or written functional briefs?
Find someone you like and your gut trusts.

Steve Owens

September 15th, 2015

I would recommend having someone who has done it before help you.  It's not an easy processes, and having someone who has made the mistakes already will help a lot.  You can find more tips on this subject at www.FinishLinePDS.com.