You have an amazing idea, you spent time sussing out the details, getting customer feedback and doing market research. You may have wanted a technical co-founder (or not), but you ended up hiring developers to build your minimal viable product (MVP).
You’re in the midst of building the technology and things are not going well.
I’m truly sorry. I have seen this happen too many times. It is so heartbreaking for me. It is why I committed my career to help nontechnical founders build businesses customers love while avoiding the common risks associated with software development.
But we’re here and you’re in this predicament, so we have to review a few things.
You may be really angry and frustrated with the developers but you may also be dealing with your own regret. Do you feel like an idiot for wasting money? Or, for staying with them for too long? Maybe you’re ready to move forward with customers and you can’t. Frustrated and anxious, you’re eager to jump to another shop. But you don’t want to make the same mistakes again.
The first thing to know is “You’re not alone.”
After 15 years in this industry, I have come to the unfortunate conclusion that it’s a given that founders will waste or lose money getting their MVP developed. In my own research from 2017, I found:
- 5 of 7 entrepreneurs have at least one poor experience with a software developer
- On a scale of 1 to 7, entrepreneurs rated the impact a poor experience with a developer had at a 5.
Five out of 7 on impact? That’s like saying, “One or more experiences with a bad developer brought my venture close to ruin.”
I think the canned advice out of Silicon Valley keeps leading founders in this direction:
- “You should find a technical co-founder”
- “You need developers to build your initial product so you can test your business assumptions.”
Both are, ahem, bullshit, but since they continue to be repeated over and over again, you’re in this situation and I’m writing this article.
First, consider that this advice comes from mostly software developers and technical founders. They created this industry and have an interest in remaining at the top of the totem pole. They want you to need them.
Second, building the initial product for a developer-founder is far easier to develop than for you, a nontechnical founder. Your initial product (a.k.a. Your Minimal Viable Product) should be cheap, quick to iterate on, easy to get and apply feedback and launch again.
By default, hiring a dev shop for a couple thousand dollars (or $250K) to build your initial product is not cheap, quick or easy to iterate on.
[PS: I have amazing development shop partners that have high standards for the quality of their work and collaboration. Contact me for an intro]
But, for now, let’s do this: Put the stress, panic, fear and other unproductive emotions aside. Below, I’ll try to address the cracks, fortify your foundation and make the best choice for YOU and YOUR BUSINESS going forward.
Signs Your Software Development Project is Going Badly
Before you make a hasty decision to leave your shop and find a new one, I want to make sure your project is exhibiting enough signs that it’s going poorly. I’ve listed 36 items that some of us industry experts use to evaluate the quality of a software development project and the collaboration around it. Give yourself 1 point for all bullets that you’re confident are true.
- You did not test the service, run a pilot, concierge it, or do something to validate some initial business assumptions
- You did not get comprehensive customer feedback on sketches or wireframes before engaging software developers
- You are still considering which target customer segments you will market this product to
- You have not yet begun business development and establishing strategic partners
- You do not have trusted advisors to give you guidance, feedback, introductions, and other support
- You are not yet running marketing experiments (both qualitative and quantitative) on landing pages, value propositions, and problem statements
- You don’t have customers waiting to buy or test your product once it’s built
PLAN AND DESIGN
- You began the project with a wish list of functionality
- You consider each item on your list as required to launch your product
- You do not have tangible proof that the money you invest in development will achieve your desired goal
- There are no clear milestones associated with your project
- Milestones do not line up with product releases you can test with customers
- Your milestones do not have metrics that measure success/failure
- There are no deliverables or documentation of what’s being created
- The developer did not perform a discovery phase before starting development
- You did not authorize or want to pay for a discovery phase
- The developer does not present to you short and long-term options for the features you request
- The developer does not ask you a ton of challenging questions to ensure you’re on the same page
IMPLEMENTATION AND TESTING
- Your development shop is not delivering what you expected
- You are constantly asking for revisions
- You are considering hiring a technical person to micromanage your dev shop
- They tell you to “just trust them”
- You are constantly saying “I don’t understand.”
- When the developer tries to explain, you still do not get an adequate explanation
- You have heard from others that the technology they are using is unusual, and/or it may be difficult for you to find others that can develop using that technology
OWNERSHIP & KNOWLEDGE TRANSFER
- You do not own your code (i.e. On GitHub, you do not own the organization and team)
- You do not know which programming languages they are using
- You do not know which frameworks they are building your platform on
- You do not know which libraries they are using
- You do not know the cloud architecture they have implemented
- You do not know what all three of these mean: Frameworks, Libraries, Cloud Architecture
- Your development shop is not responding to you according to your service agreement
- You are compensating the developer with only equity
- You are not the developer’s “ideal client”
- You believed you could spend less with an offshore company while still building high-quality software
- You thought you could manage the developers yourself
- You are disappointed that the developers cannot work independently, without you
- Once you see what the developers have built, you have new ideas and changes
- You often believe you all are on the same page, thinking the same things about features
- You often think the developer has blind spots as they did not consider something you felt was obvious
- You consider your developer’s challenging questions unhelpful
- You consider your developer’s feedback unhelpful
- Much of your disagreements are around the original scope and estimates
- You’re holding them within the original scope and estimates
Now, tally up the number of points to get your “score.”
Where you at?
If you have more than 10 points, I’m concerned and want to talk to you.
I think you would benefit from a second opinion to weigh in on your project and advise on next steps. You can head over to this page on my website to book free 45 minutes with me.
I’ll help you and you’ll help me continue to build out this scorecard/rubric.
If you’ve found this article helpful, please click the 👏🏻 below to recommend it to your friends here on Medium