A “Rapid Development Partner” is actually what it sounds like, however, to be clear we’re talking here about a rapid “software development partner” who has a core focus on mobile and web application development; quite often they’re your project partner from concept through MVP (Minimum Viable Product) delivery.

What they do is also clear, develop software, and deliver said software (web and/or mobile) as rapidly as possible, without error, defect, flaw or bug.  This is rarely the case, though there are many claims to the providing of this highly valuable type of service/skill. Unfortunately, even though the majority do eventually end up delivering without bug or defect, they often deliver with error or flaw, (misarticulating the client’s requirements) and deliver such extremely late. 

So, let’s help you discern if you’ve actually found a rapid development partner, and determine if they are of quality.

1. How do you protect yourself from failing to deliver on time? (destroys profitability and credibility)
   • Were you set up for failure from the moment your client signed the statement of work?

There are some things to ask to look for red flags before you even engage: 

• How often are you scheduled to meet?
  • Aside from purely fixed requirements development, agile and waterfall methods both suffer terribly the longer the time between client-designer-developer meetings.
    • Once a week is the LEAST meeting quantity recommended;
    • Once or more daily if possible is utopian;
• Have they provided you with a “Statement of Work”? 

• This is a comprehensive breakdown of what they are going to do, to what end, what is included, what is not, and what is intended to be delivered as an end result, this should include also an explicit timeline (with milestones if extensive project) for deliverable(s).
• Have they asked you for “user story” for each user or customer type that will interact with your developed project?
  • This is an easy opportunity to tune in to your client’s project vision, that most designers and developers miss out on.
• Is there no designer to work with the developer?
  • Either you have designs (from a designer) or your statement of work should include such; otherwise this project is destined for overruns.2. How do you have confidence that they are advising the right technology solutions?
  • Are they advising just because it’s technology they’re familiar with, or are they advising because it’s the right technology to meet the client’s requirements?

While it’s best to have a competent CTO on your own staff, you can ask the following to gain confidence as a non-developer:

• Request some logical/reasonable explanation as to the technology choice being advised;
  • ask what this technology choice implies in terms of code maintenance
    • Support
      • Is it new technology or is there a thriving community of users and supporters for this choice?
• Ask them to compare it to at least one other technology choice for your having an easier ability to understand through a comparison, 
  • highlight pro’s and con’s of each.
• In the cases where you’re wildly out of your league/realm of coherence, a second opinion from another design/development shop is a great way to gauge accuracy.

That second point, is as critical as delivering on time; the scalability of the client’s technology, the cost of maintaining it and the ability to get community support for your chosen technology, are all vital considerations when inventing software.

Begin your rapid development journey now.