Steer Clear of These Common Pitfalls in Bespoke Software Development for Your Business

All happy families are alike; each unhappy family is unhappy in its own way.

Tolstoy

You’ve probably heard a success story or two in bespoke software, something like “ordinary guy launches a popular mobile app” or “business cuts costs in two with a clever digital system”.

Perhaps you’ve also heard of a flop— maybe a friend sank money into an idea that didn’t take off, or a colleague owned a faltering IT migration.

The horror stories, though depressing, can teach the most. So if you’re considering a foray into bespoke software, get to know the points of failure. They’re less public, so unfortunately many learn someone else’s hard lesson again.

We cover a few of the frequent breakdowns below. We’re in the business of product launches so we can tell you where the landmines are. Sadly, more than once has someone called K-Optional Software with a broken project in hand, eager for a do-over.

The Impact of Budget and Talent on Bespoke Software Quality

This class of landmines especially threatens those without engineering backgrounds. A non-techie can certainly tap a great team. But one’s ability to vet technical talent correlates with their own. Having thought about this pickle a lot, I’ve concluded that the best antidotes are diligence and trust vectors.

Regarding diligence, read on: articulating your thoughts clearly and exhaustively will help shield you from disappointment.

As for trust vectors, talk to a team’s former customers. I’m surprised at how seldom prospective clients do this! Staring at someone’s portfolio might overstate their involvement, and probably only attests to their best work.

If you’re not technical and trying to get a feel for the landscape, you’re in the right place.

Budgetary explosions

What is it about “development” and brazenly neglected budgets? Why can’t quotes be held sacred? A few ideas come to mind.

For one thing, this industry lacks transparency: few can relate to translating ideas into ones and zeroes. Therefore, the layman will have a hard time maintaining alignment. For the sake of comparison, take a car mechanic: customers often have an idea of what parts do and maybe even their own diagnosis. And they have a uniform objective, which is a working vehicle. Contrast that with the vast landscape of goals in the bespoke software world.

Developer and client might find themselves “clarifying” (rewriting) a hazy script on the fly. Thus the goalposts move.

Owing to the relative infrequency of transaction, bespoke software vendors might also elude economic forces, namely trust. Getting away with a few bad projects could mean going a year without a solid delivery.

I believe all of these to be a talent problem as well an ethics problem. Unworthy dev-shops fail in three regards, forcing them to flaunt promises and budgets:

They don’t understand how to protect against scope creep. Firms think in code (which has to be rewritten) instead of blueprints and diagrams.
Inexperience leads to lack of consideration of minor details which swell in the later stages of a project.
Poor communication patterns only worsen the rift between expectations and reality.

Though I’ve personally heard some horror stories, I think that Michael Lynch wrote the best case study for this type of project failure. Lynch, a successful product engineer, fell prey to a shattered budget. He ascribes the point-of-failure to be bad management and poor communication rather than ill-intention. In any event, the design firm acted irresponsibly if not negligently in my opinion.

Avoiding budget excess

Be actively involved. Don’t be penny-rich and pound-foolish

Budget creep occurs in the white space of a statement of work (SOW). If something’s not specified, it’s prone to incurring additional expense later. Though a talented development group will suss out your unstated expectations, you serve yourself by minimizing them.

Specificity and precision go hand in hand: a well-described, granular feature won’t cause budget issues but a vague one might.

So to guard against budget creep, be exhaustive. Dictate exactly what you want in the product. Don’t cut corners before actual development starts! Diligence while planning pays dividends 100% of the time; push for roadmaps and blueprints prior to funding development.

You should strive to conclude that a company’s proposal absolutely encompasses your vision. And ideally that the company knows what they’re doing….

Poor craftsmanship

You might otherwise hire for a build-out and feel disappointed with the result.

This class obscures two modes of failure:

Subpar development talent
A budgetary failure in disguise

Weak developers will produce something uniformly lousy, but a budget-strapped team will deteriorate as resources dwindle; think running out of space on a birthday card.

Bad Developers

Depending on the detail of your vision, you might provide user interface / user experience (UI / UX) documentation. That could entail explicit mockups, a formal style guide, or simply a verbal summary of interface preferences. Conversely, you might just dictate your expectations on how the system should work and defer to development on these decisions.

If you provide formal UI guidance, bad developers will fail to match those expectations. Spacing will be off, varying devices will break layouts, and user input will glitch.

In the absence of documentation, bad developers will build interfaces that leave users scratching their head. Aside from a lacking aesthetic, you’ll find interaction counter-intuitive. It’s worth noting that without adequate information, even a strong development team can create something that doesn’t match what you picture, so you always help yourself by communicating your thoughts. But a strong development team will strive for products that are useful and functional.

UI / UX is of course just the tip of the iceberg. Beneath the surface we sometimes find unintelligible business logic built with gum and paper clips.

Case study

CJ Gustafson’s business postmortem depicts several points of failure. Of course, the “chop shop” development group stood out the most to us (lesson #4). I suspect this group combined budget mismanagement with apathy and poor craftsmanship, collecting $126,000 in revenue and leaving Gustafson feeling helpless.

Preventing Software Release Catastrophes

Production catastrophes comprise another class of failures in bespoke software. In this case, projects tank under the pressure of release. A few red flags will foreshadow such a meltdown, but they often go unnoticed.

A portrait of a production catastrophe

An acquaintance built a reputation management business. That is, she helped local companies maximize reviews from their customers. With great traction, she invested in a bespoke software solution: customers could sign up, subscribe, and use various integrations to track reviews.

She went off-shore to find the team which proved to be a mistake. Many find the nominal discount of an off-shore team appealing. Indeed, this path can make a lot of sense, usually as an optimization strategy. Maybe this sounds self-serving, but I really wouldn’t recommend adding more barriers— distance, timezone, language— early in the already opaque development cycle.

Exorbitance comes in two forms: rate and time. In this case, a mountain of hours outweighed a measly hourly rate, and the endeavor proved more expensive than the domestic alternative. To make matters worse, she had relayed reported timelines to her own clients. Back against the wall, she prematurely onboarded her users into the new system, cautioning them to avoid certain “beta” features.

If I remember correctly, she had 116 paying customers in the system at one point. When some started cancelling after wrestling with the glitchy interface, she hired K-Optional to audit the system. We discovered many mortal sins of software development— n+1 queries, egregious code duplication, and database connections vulnerable to prompt injection. She lost connection with the team at some point and had to start over.

The system was increasingly unusable with each new user. For example, the sign-up process resulted in a database inconsistency, which in turn crashed the site for other users. I found this story especially tragic since this business had overcome the obstacle of landing paying users, the undoing of many.

Avoiding meltdowns

When vetting developers discuss the points below. Even if it’s Greek to you, the conversation will reveal your bespoke software team’s priorities and strategy.

Quality assurance processes

What process does this team use to ensure that new code is production ready? How does this team try to simulate the strain of heavy, random usage?

Automated testing

Can you be sure that a subset of functionality hasn’t broken as the codebase grows? Is this team even thinking in terms of what should and should not be happening?

Warranty

Does your development team have skin in the game? Does their business model depend on smooth launches?

Onboarding strategies

What will it look like to get one person enrolled in the system? How about ten? Will things scale?

Staging / development environments

How will you preview and test features prior to releasing to active users?

Support processes

What sort of response time can you expect? What should you tell a user who reports an issue?

Understanding the Bespoke Software Development Landscape

In the face of all these landmines, we see wonderful opportunities. Our partners and clients have created tremendous value and sometimes sold their businesses. We think the road need not be that treacherous.

Are you looking for bespoke software development services? In order of importance, seek the following and you’ll be in good hands.

Trust & reputation: have reliable sources affirmed this group’s skills and commitment to excellence? Have they incorporated concrete incentives that ensure great craftsmanship?
Technical experience: can this group relate other projects? Have they launched successful products? Did they scale?
Detail: does this group make an unceasing effort to understand what you envision? Do they preemptively try to clarify ambiguities?
Accessibility and communication: do they have a process for sending you frequent updates? Will you feel like you’re knowing what’s going on at all times?