Your Software Firm Should be Vetting Your Idea, Too
Choosing the right software development company to spearhead that app idea is a tough task. There are more decisions than you can shake a stick at: Local, remote, or international? A large team with a deep bench, or a small team with deep specialization? A process closer to agile, or are you chasing waterfalls?
Contrary to the number of unsolicited offers of development help you may have in your inbox, leading firms are also on the hook to carefully vet potential clients. A working relationship is a two-way street — especially for the amount of communication software relies on — and a project’s outcome carries a cascade of effects for the agency that builds it.
No two projects are the same, but a lot of shared qualities surface among the ones that succeed. Let’s dive in.
Why We’re Evaluating Your Software Application Idea
First, we’ll quickly touch on the claim that development shops have to rigorously vet the ideas that cross their desks. After all, why would an agency ever turn down a paying client?
Three of the more reliable avenues for a firm to secure new projects include:
- Follow-on work from existing clients
- Referrals from former and current clients
- Case studies that resemble what a prospect hopes to achieve
There’s a recurring theme in all three: They rely on the project being successful. If the app fails to generate value, it’s a safe bet that follow-on work is off the table. As we covered in more depth alongside pricing, the get-to-know-each-other phase of sales is also the can-we-do-this and can-this-be-successful phase.
More subtly, success also plays into team engagement. Developers (and designers, and project managers, and everyone else) are noticeably more effective on projects that routinely hit their business objectives. Building something comes with a sense of ownership, and positive morale ties in with a positive outcome.
Summed up, we need more hits than misses to attract new work and keep our folks happy.
Signs That Point to a Successful Software Build
We’re not experts in your domain, so it’s just about impossible to judge the idea at face value. That said, there are telltale signs that successful projects have in common. Here’s what we’ve seen in the last decade.
Realistic Timelines and Budgets
Everyone wants their application finished yesterday. We haven’t quite sorted out a time machine (yet), so what’s the next important date on your calendar?
From our side of the fence, time and money are the most straightforward metrics in evaluating a project. Is the need realistic when paired with basic guide rails? Too much too soon doesn’t set either side up for expectations to be met.
If I were building a house from scratch, I might start with a rough sketch of a layout that’d suit my expectations. Great jumping-off point? Absolutely. Suitable for permitting and estimating by contractors? Probably not.
A list of requirements, needs, and dreams are all a fantastic starting point for a software project, but they’re just that: A starting point. Together, we’ll figure out which approach makes the most sense and how it ties into budgets, timelines, and best practices. There’s so much variability in the how that early certainty is a red flag.
Subject Matter Expertise
We’re not an expert in your domain, but do you have someone that is? Most founders operate in a space that they know, and our best partners tend to be consultants on a particular bit of subject matter expertise.
Folks that dive into a new industry can be just as successful, but it does require additional vetting on our end. Experience can point out regulation, pitfalls, and false starts.
A Plan for Customer #1
Preferably, a Field of Dreams approach (if you build it, they will come) isn’t the business plan.
Do you have a monetary commitment from at least one customer? Even if it’s your organization, having customer number one set before development starts is a huge vote of confidence for the idea. It hedges bets on the risk of software:
- Even if the end result doesn’t take off, the project could still generate value beyond the project cost to that first set of users.
- Throughout the build, the team will have access to feedback from real, paying customers.
Bonus points if that customer is on board to help fund development efforts.
A Viable Minimum Featureset
What’s the smallest set of features that would be useful to a user?
Building out every requirement and wishlist item takes months (or years) — and waiting until everything is “perfect” tempts fate. That period is marked by change. Your understanding of the problem, the industry, and the customer will be further refined, and those learnings should be delivered as quickly as possible.
If the answer to this section’s opening question is all of them, the project may burn a lot of time building the wrong thing. Or, get stuck in an endless cycle of “tuning” before launch. Both, as you’d expect, carry hefty penalties when it comes to defining a release timeline.
Similar to sorting out a minimum viable product, can the individual features be prioritized? Could you list them out by importance without writing everything horizontally?
Everything’s developed on a sliding scale of effort. If we’re talking about a mission-critical part of the application, it makes sense for that feature to command a disproportionate amount of attention. Should something be fully custom? How much complexity can the timeline support? Getting the overall resourcing approach correct relies on being able to rank the importance of a platform’s parts.
A Clear Explanation of the Hard Parts
We love hearing about the secret sauce behind an idea. Algorithms, processes, bits of logic — custom software is exciting because it’s a window into your unique expertise.
The catch, though, is that you have to be able to explain that expertise. Hard concepts need a clear explanation for implementation — like our translation of Outcomes Insights’ ConceptQL into an interactive visualization. We want that algorithm to be automated and scalable too, but first it needs to be translated into a production-ready language.
Budget For the Stuff That Comes After
Is there ample budget set aside for the stuff that comes after launch? It’s a topic we’ve covered previously: Releasing an application means that you’re a technology company (congrats!). With that, you’ll be on the hook for sales, marketing, training, maintenance, and a host of other costs and concerns.
Going all in on the technology is buying a fancy engine and forgetting the rest of the car.
Pitching Your Software Development Vendor
Selling a potential vendor on your idea seems counterintuitive, but it’s usually a sign that you’ve found a team worth considering. Successful projects are the path to follow-on work, referrals, and solid case studies, so development shops also have incentive to be picky about potential partnerships.
Vetting from the agency side is relative, though, since we’re generally lacking in your specific brand of domain expertise. Instead, we’re looking for the telltale signs of a quality idea and an iterative build process. Existing customers, prioritized features, realistic timelines, and the ability to explain complex concepts clearly all go a long way in setting up a favorable outcome.
Component-centric design systems give teams greater consistency, maintainability, and efficiency in the process of building web applications.