Your Software Firm Should be Vetting Your Idea, Too

Choosing the right software development group is a tough task, owed mostly to the sheer number of decision trees: local, remote, or offshore? A large team with a deep bench, or a small team with deep specialization? A process closer to agile, or are you chasing waterfalls? Do you need leaders, implementers, or both?

Contrary to the number of unsolicited offers of development help you may have in your inbox, leading firms are also on the hook to be choosy. A working relationship is a two-way street — success hinges heavily on communication, after all — and the outcome is important to the team building it, too.

No two projects are the same, but a lot of similarities pop up among the ones that make the grade. Let’s dive in.

Why We’re Evaluating Your App Idea

What would it take for an agency to turn down a client with money in hand? A round-the-clock concern: the ability to secure future work.

Three of the more reliable avenues for a firm to land new projects involve:

• Follow-on work from existing clients
• Referrals from former and current clients
• Case studies that resemble what a new prospect hopes to build

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 involved) are noticeably more effective on projects that routinely hit their business objectives. Building something good stems from a sense of ownership, and positive morale follows 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 (usually) 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 share. Here’s what we’ve seen in the last decade-plus.

Clear Idea of Responsibilities

Do you need someone to find a solution, or implement one? If you’re looking for leadership help, you’ll have to be prepared to cede it; if not, you’ll have to be ready to provide it.

Either way, responsibilities should be clearly set at the beginning.

Realistic Timelines and Budgets

Everyone wanted their application finished yesterday. We haven’t quite sorted out a time machine just 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 potential project. Are the needs realistic when paired with process? Too much too soon doesn’t set either side up for expectations to be met.

Flexible Requirements

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? Nope.

A list of requirements, needs, and dreams are all fantastic starting points for a software project, but they’re just that: starting points. 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 experts in your domain, but do you have someone who is? Most founders operate in a space that they know, and our best partners tend to be consultants on the subject matter expertise that drives the idea.

Folks that dive into a new industry can be just as successful, but it does require additional vetting on our end. Experience informs regulation, pitfalls, and false starts.

A Plan for Customer #1

Preferably, the 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 #1 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 with 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. Your understanding of the problem, the industry, and the customer will continue to improve, and those learnings should be delivered as quickly as possible.

If the answer to this section’s opening question is all of them, we’ve found a red flag. The project may spend too much time building the wrong thing in a vacuum, 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 and budget.

Prioritized Features

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 pieces.

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 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 an 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 a budget for the stuff that comes after all go a long way in setting up a favorable outcome.

Interested in how the pre-project process goes with a development shop? Check out our guide to working with an outside software firm.