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.

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

Matt Warcholinski Serial entrepreneur x7 // Remote JavaScript Teams for Hire

Last updated on December 14th, 2018

Is your budget higher than $10k-$20k?

If NO, build MVP by yourself -> How to build an app as non-technical founder

If YES, below a few questions worth mentioning:

General Questions

How do you work? Tell me more about your process/approach of creating the application.(Tip: Get a big picture of the approach.)
How do we communicate during a project to know the PPP (progress, plans, problems)? (Tip: There must be a mechanism/procedure that ensures you know what’s going in the project. You must be updated at least on a two-week basis. You NEED to know when things go wrong. Dig deeper using the next question.)
How do you ensure we know when things go wrong? Helper question: tell me how you handled a project in the past that went wrong. (Tip: First, nobody wants to deliver bad news. Make sure they have a mechanism in place. Second, nobody’s perfect, so there must be a case that went wrong – listen to what they took out of it. Third: none likes surprises – the best is to be prepared for the challenges.)
What do you expect from us and what should we expect from you during the cooperation?(Tip: See what are the roles in the new-forming team. There’s no one way to set it up, but it is good to know what to expect. It’s great to know from the beginning what is the scope of responsibilities for each party.)
How do you try to deliver the product that will match our and market’s expectations? (Tip: See how they work on figuring out what you really need.)

Technical Questions

How do you ensure software quality? (Do they use, for example, peer code review or automated tests?)
Will I own the source code? (Tip: check the agreement.)
Do you work on technical documentation?
Could you provide me profiles of developers with whom I will work? (Tip:They will be anomyzed – with no personal/contact data.)
Can I talk to the best-skilled person on your team?
Tell me how you will solve/build a…. (Tip: Give an example of a tricky part of your app and ask the potential software development partner how they will approach it.)
Could you share with me your best practices for writing the code? (Tip: ex. we have it written down as a handbook and use an eslint company file….)

Business Questions

Why are you better than other software houses? What makes you special? (Tip: ex. Sometimes, it could be a PM or QA or Senior/Architect Mentoring.)
How easy will it be to scale a team by 1/3/5 developers? How much time do you need? (Tip: if you plan to scale the team, communicate it to the software development company ASAP. Around 1-3 months should be enough to scale the team.)
What is your pricing per Man-Day? What does it include? (Tip: ex. Sometimes, it could be a PM or QA or Senior/Architect Mentoring.)
Have you done any project similar to mine, regarding the Industry/Technology/Product Features?
Could you provide any testimonials/references from your previous clients? (Tip: Check clutch.co, have a Skype call with one of the customers, check Facebook Reviews or simply google it.)
What is your experience working with Startups/SMBs/Enterprises? (Tip: Ask about the size of companies with whom they worked, ask to give you examples of projects.)

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.

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.

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.

Question stats